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

[Daniel D. Daugherty]

Another relevant bug ID is:

7010849 5/5 Extraneous javac source/target options when building sa-jdi

Dan


On 3/11/2011 12:29 PM, Jim Holmlund wrote:
>
>
> 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