Mantis Bugtracker
Startseite | Übersicht | Probleme anzeigen | Änderungsprotokoll | Roadmap | Dokumentation | Konto
  

Einfache Problemansicht anzeigen [ Zu Notizen wechseln ] [ erweiterte Anzeige ] [ Problem-Historie ] [ Drucken ]
ID Kategorie Auswirkung Reproduzierbar Meldungsdatum Letzte Aktualisierung
0000039 [Barista] general Feature-Wunsch immer 2009-05-23 20:18 2009-06-29 21:35
Reporter sufrin Anzeigestatus öffentlich  
Bearbeitung durch xclerc
Priorität normal Lösung erledigt  
Status erledigt   Produktversion
Zusammenfassung 0000039: Class files apparently not compatible with Java 1.5 -- but no control over target ...
Beschreibung Standard build generates code that is not compatible with the OS/X (Tiger)
or Solaris Java 1.5 builds (class version error). Code is compatible with Java 1.6 builds on Linux and Solaris.

It may be that this is deliberate, but since Apple is always way behind on its VM versions it's a bit inconvenient not to be able to control the class versions from the barista api.

[Thank you for an otherwise-wonderful library!]


Compiled and ran the Hello world program from the documentation (code sample 2) to generate Hello.class. [[ASIDE: I think the INVOKEVIRTUAL instruction in that sample is incorrect and should be:

Instruction.INVOKEVIRTUAL
( `Class_or_interface (utf8_for_class "java.io.PrintStream"),
  (utf8_for_method "println"),
  ([(`Class (utf8_for_class "java.lang.String"))], `Void)
);

END-ASIDE]]

No 1.5 JVM I have available will run the Hello code; all 1.6 JVM I have available will.
Zusätzliche Information # Solaris java 1.5 running
610$ ssh eclectic java -version
java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing)

611 $ ssh eclectic java Hello
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        ...

# Linux java 1.6
616$ ssh laborious java -version
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_01-b06, mixed mode)

617$ ssh laborious java Hello
hello.

# OS/X Java 1.5
617 $ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-275)
Java HotSpot(TM) Client VM (build 1.5.0_16-132, mixed mode, sharing)

618 $ java Hello
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        ...

# OS/X java 1.4
619 $ /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Commands/java Hello
Exception in thread "main" java.lang.UnsupportedClassVersionError: Hello (Unsupported major.minor version 50.0)
        at java.lang.ClassLoader.defineClass0(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
Tags Keine Tags zugeordnet.
Angehängte Dateien

- Problem-Beziehungen

-  Notiz
(0000179)
sufrin (Reporter)
2009-05-23 20:47

 I see now that this is indeed a feature and that therefore the additional information I have supplied is redundant/pointless. My aside about the INVOKEVIRTUAL instruction remains valid.

It would still be good to be able to control (to a small extent) the class file format number. The difference between 5.0 (49) and 6.0 (50) seems to be the
StackMapTable attribute in the latter (which is ignored, it seems, by 5.0 JVMs)
(0000180)
xclerc (Administrator)
2009-05-24 15:08

 You are right about both points.

Regarding versions, the current (1.2) version writes '.class' files that are
compatible with Java 1.6 only. It can load any '.class' file with Java versions
from 1.0 to 1.6 (thanks to backward compatibility of the Java class file format).
I do agree that this would be a good thing to:
  - be able to produce '.class' files of a given version (hence verifying that
     the data contains only elements compatible with this version) ;
  - verify at loading that the version of the '.class' file is actually coherent
    with its contents.
I thus record "version handling" as a feature request to be implemented
in the next (1.3) version of Barista.

Regarding the documentation, you are clearly right. I failed to keep the
pdf synchronized with the code base. This will also be fixed in the next
version.


Thanks for reporting, and for your interest.
(0000185)
xclerc (Administrator)
2009-06-29 21:35

 Support for class file format versions has been committed to darcs repository.
A 'Version' module has been introduced, defining the various Java versions.
Moreover, the 'ClassDefinition.encode' function now takes an optional parameter
allowing to specify a Java version (defaulting to '1.6'). Before encoding, a check is
made to ensure that the class definition contains no element incompatible with
the passed version.

Of course, the assembler has been updated accodingly: a '-target' command-line
switch allows to specify the Java version.

- Problem-Historie
Änderungsdatum Benutzername Feld Änderung
2009-05-23 20:18 sufrin Neues Problem
2009-05-23 20:47 sufrin Problemnotiz hinzugefügt: 0000179
2009-05-24 15:08 xclerc Problemnotiz hinzugefügt: 0000180
2009-05-24 15:08 xclerc Bearbeitung durch => xclerc
2009-05-24 15:08 xclerc Status neu => anerkannt
2009-06-29 21:35 xclerc Problemnotiz hinzugefügt: 0000185
2009-06-29 21:35 xclerc Status anerkannt => erledigt
2009-06-29 21:35 xclerc Behoben in Version => 1.3
2009-06-29 21:35 xclerc Lösung offen => erledigt

Mantis 1.1.7[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker