SA and JDK ( was Re: JDK8 Preliminary Repository Layout)
Daniel D. Daugherty
daniel.daugherty at oracle.com
Mon Mar 21 14:59:37 PDT 2011
Another relevant bug ID is:
7010849 5/5 Extraneous javac source/target options when building sa-jdi
On 3/11/2011 12:29 PM, Jim Holmlund wrote:
> On 3/10/2011 6:54 PM, David Holmes wrote:
>> 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
>>> 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.
More information about the serviceability-dev