Tim Ellison wrote:
Yuri Dolgov wrote:
we can make this constant definable by the build.
That's a great idea. I agree.
Would it be too expensive as a runtime check? i.e ask the classlib at
start-up if the VM should behave like Java 5 or Java 6, then we don't
even have to produce separate VM builds.
I don't think it would be expensive in any way. This constant
CLASSFILE_MAJOR_MAX is currently used only in 2 places, to check that
class file version is supported by VM, and to define java.class.version
property value on startup.
This property could be defined by classlib code, and VM would use its
value in class loader instead of hardcoded class version.
On 9/6/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
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
--
Gregory
