We are preparing for the upcoming Jigsaw integration [1] and I wanted to
give a brief heads-up concerning the steps leading up to this.
* As an interim step we will start building FX with a pre-Jigsaw version
of JDK 9 (likely build 109) [2]
* I will send out a webrev soon with the changes
Chien,
Please review the following change to workaround a JDK 9 javac bug when
generating our javadocs"
https://bugs.openjdk.java.net/browse/JDK-8151565
http://cr.openjdk.java.net/~kcr/8151565/webrev.00/
-- Kevin
Hi Johan,
That sounds like the fix then.
Note that there is another optimization issue here that could be
addressed in a follow-on - basically when a larger physical size is
allocated, then we could expand the content dimensions to match what was
allocated. We would possibly need a new
Phil,
could you review:
JobSettingsTest.testPaper fails with small paper sizes
Simple fix, make the margins that don't fit 10% of the page dimension
https://bugs.openjdk.java.net/browse/JDK-8149756
http://cr.openjdk.java.net/~ddhill/8149756/
--
David Hill
Java
Yes, please. Just get Jim to code review it and you can push it to 9-dev
yourself, since you are a committer.
For JDK 8, you need to request approval to backport. If approved by me,
then you can push it to 8u-dev.
-- Kevin
Johan Vos wrote:
Hi Jim,
Passing the contentWidth to the update()
When I tried to load a wav file from my OSGi bundle's resources JavaFX
reported that it could not load the file because the protocol "bundle"
is unsupported. I checked the code and indeed, it is not supported.
However I wondered why the Locator doesn't use the same mechanism as the
font
Hi Jim,
Passing the contentWidth to the update() fixes the problem as well, and if
the excessive memory is not needed (as in my proposal), this is of course
much better.
Can I create an issue and suggest the following patch (this is for 8, but I
can do a similar for 9)?
- Johan
---