Egor Pasko wrote:
On the 0x349 day of Apache Harmony Gregory Shimansky wrote:
Yuri Dolgov wrote:
Looking at the Sun's list of enhancements for Java6 [1] I found non
features specific to VM except for a small change in reflection API [2].
So it seems to me that VM in Java5 and Java6 can be the same.
Yes, that's fine. But why don't we just put this in Java 6 branch? I
understand
that our VM works fine with Java 6 classes, but what about classlib and JIT?
I think that throwing UnsupportedClassVersionError is just a tool
which
help to avoid unpredictable results.
Well, because there isn't a Java6 branch for VM. And I don't think
that a change in 1 line deserves to create one.
+1
alternatively: if it is one liner, we can make make it an option in the build.
After the patch that I've committed at 572698 the class version is
controlled by a single constant CLASSFILE_MAJOR_MAX in Class.h. Yes I
think we can make this constant definable by the build.
On 9/6/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Yuri Dolgov wrote:
Hello Gregory,
I'm not sure what is the reason to support classes with version 50 if
don't
support
Java 6 features? Maybe it worth to make this changes in separate Java 6
branch to
prevent confisions?
Looking at the Sun's list of enhancements for Java6 [1] I found non
features specific to VM except for a small change in reflection API [2].
So it seems to me that VM in Java5 and Java6 can be the same.
[1] http://java.sun.com/javase/6/webnotes/features.html
[2]
http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
On 9/5/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Stepan Mishura wrote:
On 9/4/07, Gregory Shimansky wrote:
Hello
As of revision 572698 DRLVM should not throw UnsupportedClassVersion
when it sees a class file compiled with Java6 compiler (or with
-target
1.6 by ECJ 3.3). These class files should work with no problems with
DRLVM.
Sould we create a java6 branch for DRL VM (as we did for classlib) and
move your update to the branch?
I don't think this deserves a real branch. The fact that VM accepts
classes of version 50 doesn't mean it is Java6 compliant. It also
doesn't make it non-Java5 VM in any way.
On the other hand, if we make changes like in [1] it may break
compatibility with older Java5 code, and in such case we'll maybe want
to create a separate branch.
[1]
http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
For testing I used classlib (trunk) compiled with ECJ 3.3 with
-source
1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
from JDK 6.0.
--
Gregory
--
Gregory
--
Gregory
--
Gregory
--
Gregory
