[OpenJDK 2D-Dev] <i18n dev> [9] RFR: 8038092: Re-examine Bidi reflective dependency on java.awt.font

[Phil Race]

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.