harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [classlib][jdwp] Use java 6 branch JDWP in java 5 builds?
Date Wed, 29 Jul 2009 13:13:49 GMT

In message <4A7031F1.3020209@apache.org>, Gregory Shimansky writes:
> Oliver Deakin said the following on 29.07.2009 15:20:
> > Hi all,
> > 
> > After determining the cause of HARMONY-6246 [1] I discovered that it has 
> > already been fixed in the Java 6 branch, where I recently applied the 
> > contribution in HARMONY-6187 [2]. This got me thinking - there have been 
> > a number of bug fixes, performance improvements and portability changes 
> > made which were applied in that contribution and it is likely we will 
> > hit some of the same issues again in the Java 5 branch which have 
> > already been fixed in Java 6.
> > 
> > Is it possible for us just to use the updated Java 6 branch JDWP in our 
> > Java 5 builds as well? Not only would we benefit from the code 
> > improvements made there, we would have one unified code base for JDWP 
> > (and possibly the whole of jdktools?).
> > 
> > Any comments on this idea?
> If JDWP agent with Java6 update doesn't demand that VM support new 
> features of JVMTI (that is it can work with Java5 VM), I think it is a 
> good idea. Backporting all of the bugfixes may be quite difficult since 
> it is necessary to separate pure bugfixes from Java6 enhancements in [2].
> > [1] https://issues.apache.org/jira/browse/HARMONY-6246
> > [2] https://issues.apache.org/jira/browse/HARMONY-6187

Does the current combination of DRLVM and java6 branch JDWP work
consistently?  That is, do all of hardcoded (?) capabilities[0] that
JDWP claims are supported work with DRLVM as expected?

Does any of the Java 5 JDWP functionality require 6.0 JVMTI calls?

Assuming the answers to the above are yes, yes and no, then I see no
problem.  If anyone needs a JDWP for a Java 5 VM then we'd just need
to #ifdef the reporting of the capabilities to stop 6.0 calls being


[0] particularly java 6 ones such as canGetInstanceInfo,
    canRequestMonitorEvents, canGetMonitorFrameInfo,
   canUseSourceNameFilters, canGetConstantPool, and canForceEarlyReturn

View raw message