SA and JDK ( was Re: JDK8 Preliminary Repository Layout)

[Jim Holmlund]

On 3/10/2011 6:54 PM, David Holmes wrote:
> Andrew,
>
> Just picking up on your SA comments and adding in the servicability folk and bcc'ing the build 
> folk ...
>
> Dr Andrew John Hughes said the following on 03/11/11 10:46:
>> Well HotSpot is one thing I think works well as a separate repository.
>> It allows us to have a stable branch for OpenJDK6 for example.  The only
>> real thing that stops it being independent is the servicability agent,
>> which, IME, would be better held in the JDK.  That would also mean that
>> the existing rules for building java classes could be used, rather than
>> reinventing it all in the HotSpot makefiles as at present.
>
> The SA is part of Hotspot because the SA is a Java interface to the Hotspot internals. Hence the 
> SA Java files have to be updated when the hotspot source files are, hence they must be in the same 
> repo or we'd have huge coordination problems. These files reside in sa-jdi.jar
>
> The SA classes are dependent on the com.sun.jdi interfaces/classes, so yes changes to JDI might 
> require changes to the SA. But the SA is just a JDI client in that regard.
>
See also CR
           6599669:   SA-JDI:  Fix to work with HotSpot Express.
It points out:
> The HotSpot workspace includes the Serviceability Agent .java files.
> These files must be kept in sync with HotSpot changes.
>
> The HotSpot workspace also includes an (read-only) implementation of JDI
> using SA called SA-JDI.  These files must implement new features
> as they are added to JDI in new feature releases.  So, what happens
> to these new features when SA-JDI is built/used in an update release
> as part of HotSpot Express?

- jjh

>> I've already run across one place where this is true.  HotSpot builds
>> the servicability agent with -source 1.4 -target 1.4.  Why? Because
>> of incompatibilies between its implementation and the com.sun.jdi
>> interfaces which require Comparable<T> not Comparable.
>
> My understanding is that the SA classes define their own Enum type which conflicts with the 
> java.lang.Enum added in 1.5. To avoid all the warnings this would generate, plus the raw type 
> warnings as the SA is not generified, it is compiled with -source 1.4.
>
> David