This took some getting my head around.
First I had to find the first set of changes that broke the static
dependency :-
This in JDK 7 :-
http://mail.openjdk.java.net/pipermail/i18n-dev/2009-November/000154.html
changeset: 1869:eb8b08775b82
user: alanb
date: Thu Nov 12 11:20:51 2009 +0000
summary: 6898124: Bidi should not require AWT to be present
and this in JDK 8 :-
http://mail.openjdk.java.net/pipermail/i18n-dev/2011-March/000343.html
changeset: 3889:646047d77db9
parent: 3884:19567f9d6962
user: alanb
date: Wed Mar 30 00:59:07 2011 +0100
summary: 7026507: Bidi initialization fails if AWT not present
The premise of the 'faking' there seems to be that unless you have the
client
java.awt.font package present, you can't have passed in these attributes to
begin with, so failing to 'match' them is all that is needed to do the
right thing.
I am not sure that from here :-
http://cr.openjdk.java.net/~alanb/7026507/webrev/src/share/classes/sun/text/bidi/BidiBase.java.sdiff.html
static final Boolean RUN_DIRECTION_LTR = (clazz == null) ?
3469 Boolean.FALSE : (Boolean)getStaticField(clazz,
"RUN_DIRECTION_LTR"
is really what you'd want - ie default to RTL text if you can't find the class
per the code here
paraLvl = (runDirection.equals(TextAttributeConstants.RUN_DIRECTION_LTR)) ?
2700 (byte)Bidi.DIRECTION_LEFT_TO_RIGHT :
(byte)Bidi.DIRECTION_RIGH
although it doesn't matter since runDirection will always be null.
Still line 3469 should be re-examined.
As for the current change it has the same effect as far as I can tell, and
I am supposing it is needed since even public classes in the client
module are not available to the core module, even by reflection
but the trick of having the client code 'install' the accessors in
the core module gets around this ..
-phil.
On 7/2/2014 9:32 AM, Naoto Sato wrote:
Sending this to 2d-dev list as well, seeking for reviews for changes
in the java.awt.font package.
Naoto
On 7/1/14, 5:42 PM, Naoto Sato wrote:
I further modified the fix:
- Made sure the SharedSecret is lazily evaluated.
- Added the missing JavaAWTFontAccessImpl file
- Added a test case
http://cr.openjdk.java.net/~naoto/8038092/webrev.2/
Please review.
Naoto
On 7/1/14, 1:09 PM, Naoto Sato wrote:
Thanks, Alan. Here is the revised webrev based on your suggestions:
http://cr.openjdk.java.net/~naoto/8038092/webrev.1/
Please review.
Naoto
On 7/1/14, 6:58 AM, Alan Bateman wrote:
On 30/06/2014 18:35, Naoto Sato wrote:
Hello,
Please review the fix for the subject bug:
https://bugs.openjdk.java.net/browse/JDK-8038092
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/8038092/webrev.0/
Thanks for looking at this issue.
One part that doesn't look right is where Bidi is used before
TextAttribute or NumericShaper are initialized and then used later
with
one of these as an attribute. Normally with SharedSecrets then
ensureClassInitialized is to used to initialize a class that is
known to
register the secret but in this case then you can't do that because it
would create a dependency on java.awt. The simplest thing might be to
keep the Class.forName in both TextAttribtueConstants and
NumericShapings as that will ensure that those classes are initialized
(if they are present).
A minor comment is that there are probably a bunch of imports that can
be removed once the bulk of the core reflection usage goes away.
-Alan.
