Security fixes are back; other fixes can go in. Time for build 18?

[Joe Darcy]

Andrew John Hughes wrote:
> 2010/1/7 Joseph D. Darcy <Joe.Darcy at sun.com>:
>   
>> Andrew John Hughes wrote:
>>     
>>> 2009/12/25 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>
>>>       
>>>> 2009/12/24 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>>
>>>>         
>>>>> Andrew John Hughes wrote:
>>>>>
>>>>>           
>> [big snip]
>>     
>>>>> The com.sun.java.swing package in OpenJDK should have the same effective
>>>>> compile-time visibility as in Sun JDK.
>>>>>
>>>>>
>>>>>           
>>>> I don't know what that is; does this mean
>>>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6?  I
>>>> don't mind either way, it just seems that the other plaf packages are
>>>> visible.
>>>>
>>>>
>>>>         
>>>>> I'm going to start taking my vacation in earnest now so we can finish
>>>>> working through this issue early in 2010.
>>>>>
>>>>> Happy holidays,
>>>>>
>>>>>
>>>>>           
>>> Happy new year!  Any more thoughts on the above?
>>>
>>>
>>>       
>> Yes, easing back from vacation and donning my fedora and bullwhip, I've dug
>> into what is going on here.
>>
>> In brief, make/common/Release.gmk has a list of packages to exclude from the
>> ct.sym warning (6476749: "Exclude Swing plaf classes from Sun Proprietary
>> warning"); from
>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk
>>
>> # The compiler should not issue a "Sun Propietary" warning when compiling
>> # classes in the com.sun.java.swing.plaf packages, since we've always
>> # allowed, and even advocated, extending them (see bug 6476749).
>> #
>> # This approach is NOT to be used as a general purpose way to avoid such
>> # compiler warnings for non-core packages. The correct way is to document
>> # the packages in NON_CORE_PKGS.gmk, and include them in the NON_CORE_PKGS
>> # definition.
>> #
>> # Swing has taken this approach only as a temporary measure to avoid
>> # the compiler warnings until we can properly document these packages.
>> # This is covered under 6491853.
>> EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf          \
>>                       com.sun.java.swing.plaf.windows  \
>>                       com.sun.java.swing.plaf.motif    \
>>                       com.sun.java.swing.plaf.gtk
>>
>> In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included on that
>> package list.  Therefore, the test file in question compiles without warning
>> using Sun's 6 update release.  The corresponding addition to this list has
>> *not* been made in JDK 7, which is probably just an oversight.
>>
>>     
>
> In 7, it's now a standard API javax.swing.plaf.nimbus.  So you'll find
> it listed in make/docs/CORE_PKGS.gmk instead:
>   

Yes, for JDK 7 javax.swing.plaf.nimbus is a core package.

>   javax.swing.plaf.basic                         \
>   javax.swing.plaf.metal                         \
>   javax.swing.plaf.multi                         \
>   javax.swing.plaf.nimbus                        \
>   javax.swing.plaf.synth                         \
>   

However, javax.swing.plaf.nimbus being a core package in JDK 7 has no 
direct bearing how com.sun.java.swing.plaf.nimbus should be regarding in 
either OpenJDK 6 or the 6 update release.

Generally, the "exported external" APIs in the JDK are in the java.* and 
javax.* namespaces.  These are the APIs that everyone is supposed to 
call, etc.  Nearly all of the sun.* and com.sun.* API are not in this 
category; rather they are only intended to be used by a restricted set 
of parties, such as the JDK implementation.  The Swing packages listed 
in EXCLUDE_PROPWARN_PKGS are an exception to this rule.

The ct.sym feature is a compile-time proto module system to add an 
enforcement mechanism to this long-standing API policy.

>> I'd support com.sun.java.swing.plaf.nimbus being included in this list in
>> OpenJDK 6 as long as
>>
>> * The API of the package is the same as in Sun's 6 update release
>>     
>
> We have no way of verifying what's in the 6 update release as it is
> proprietary software.

After hacking together a small annotation processor, I will send the 
source for the processor and a list of the signatures of the methods and 
constructors of the types in the Nimbus package in the 6 update train.

>   The Nimbus code in OpenJDK6 is a backport of
> what's in 7, moved back to the com.sun.java.swing.plaf.nimbus
> namespace wihich I believe was used in the proprietary 6 update train.
>
> Remember that this is an open-source project; regardless of whether
> arbitrary bits of code are made invisible or not in a unpatched build
> of OpenJDK6, anyone can easily read the code and even rip the ct.sym
> hack right back out again.

Just because something is technically feasible does not mean it is 
advisable.  Many technically possible changes are not done so that 
various other goals can be met, such as following the Java SE 6 
specification, etc.

If one takes steps to circumvent ct.sym or other enforcement mechanism, 
it is clear who should be responsible for any adverse consequences.  For 
example, if someone circumvents ct.sym and then a type being accessed is 
changed in a subsequent release, that is a "close not a bug" situation.

>  Additionally, not doing this would make
> OpenJDK6 different from the proprietary release -- as you mention
> above, it doesn't mask this package.
>   

Because the proprietary release does not unmask this package, if OpenJDK 
6 also unmasks this package, IMO it is important that the OpenJDK 6 API 
match the API exposed in the proprietary release.

-Joe