In message <[email protected]>, 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
invoked.
Regards,
Mark.
[0] particularly java 6 ones such as canGetInstanceInfo,
canRequestMonitorEvents, canGetMonitorFrameInfo,
canUseSourceNameFilters, canGetConstantPool, and canForceEarlyReturn
