harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Yu <junjie0...@gmail.com>
Subject Re: [classlib][jdwp] Use java 6 branch JDWP in java 5 builds?
Date Wed, 29 Jul 2009 12:23:51 GMT
It sounds good to me. Since Java 6 JDWP can be simply treated as Java 5
JDWP++, it can certainly work on Java 5 VM if new features of Java 6 are not
In my mind, there is only one difference. If we send a Java 6 JDWP command
from the debugger to a real Java 5 JDWP, it will report that the command is
not implemented. If we do the same thing on a Java 6 JDWP+ Java 5 VM, it
will report that the underlying  Java 6 JVMTI method can't be supported.

2009/7/29 Gregory Shimansky <gshimansky@apache.org>

> 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
> --
> Gregory

Best Regards,
Jim, Jun Jie Yu

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message