JRuby

[ruboto] unsupported Java version: 0.9

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.6.2
  • Fix Version/s: JRuby 1.7.0.pre1
  • Component/s: Core Classes/Modules
  • Labels:
    None
  • Environment:
    Android 30 api level 11
  • Number of attachments :
    0

Description

When starting an android application with jruby-jars from master 2011-05-05 the following exception is thrown:

W/dalvikvm( 1939): Exception Ljava/lang/RuntimeException; thrown while initializing Lorg/jruby/RubyInstanceConfig;
W/dalvikvm( 1939): threadid=10: thread exiting with uncaught exception (group=0x40014760)
E/AndroidRuntime( 1939): FATAL EXCEPTION: Thread-11
E/AndroidRuntime( 1939): java.lang.ExceptionInInitializerError
E/AndroidRuntime( 1939): 	at org.ruboto.Script.setUpJRuby(Script.java:63)
E/AndroidRuntime( 1939): 	at org.ruboto.Script.setUpJRuby(Script.java:57)
E/AndroidRuntime( 1939): 	at org.ruboto.RubotoActivity.getRuby(RubotoActivity.java:79)
E/AndroidRuntime( 1939): 	at org.ruboto.RubotoActivity.backgroundCreate(RubotoActivity.java:155)
E/AndroidRuntime( 1939): 	at org.ruboto.RubotoActivity.access$000(RubotoActivity.java:13)
E/AndroidRuntime( 1939): 	at org.ruboto.RubotoActivity$1.run(RubotoActivity.java:140)
E/AndroidRuntime( 1939): Caused by: java.lang.RuntimeException: unsupported Java version: 0.9
E/AndroidRuntime( 1939): 	at org.jruby.RubyInstanceConfig.<clinit>(RubyInstanceConfig.java:367)
E/AndroidRuntime( 1939): 	... 6 more
W/ActivityManager(   65):   Force finishing activity no.datek.nettbuss.operator/.StartupActivity

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Uwe Kubosch added a comment -

I think this was against the master branch, so not so relevant. I'll resolve this, and reopen if it happens on the 1.6 branch or on a release.

Show
Uwe Kubosch added a comment - I think this was against the master branch, so not so relevant. I'll resolve this, and reopen if it happens on the 1.6 branch or on a release.
Hide
Permalink
Uwe Kubosch added a comment - - edited

Reopened for master. I am unable to change the affected version for this issue. Affected version should be 1.7.0.dev

Show
Uwe Kubosch added a comment - - edited Reopened for master. I am unable to change the affected version for this issue. Affected version should be 1.7.0.dev
Hide
Permalink
Uwe Kubosch added a comment -

I see in src/org/jruby/RubyInstanceConfig.java that java.specification.version is used to determine java version and choose which opcodes to use. Shouldn't java.class.version be used instead? That will answer "46.0" on a current dalvik vm.

Show
Uwe Kubosch added a comment - I see in src/org/jruby/RubyInstanceConfig.java that java.specification.version is used to determine java version and choose which opcodes to use. Shouldn't java.class.version be used instead? That will answer "46.0" on a current dalvik vm.
Hide
Permalink
Uwe Kubosch added a comment -

Fixed this on the Ruboto side by calling

System.setProperty("jruby.bytecode.version", "1.5");
Show
Uwe Kubosch added a comment - Fixed this on the Ruboto side by calling System.setProperty("jruby.bytecode.version", "1.5");
Hide
Permalink
Charles Oliver Nutter added a comment -

Yeah, I might have marked this as WONTFIX, since it seems completely wrong for them to report what I assume is a Dalvik-related version number rather than a Java version number. I'm still open to a patch if the specification version on Android is meaningful...specifically, if it tells us something we could use to pick better APIs, as we do with Java 6 in some cases. If it's only useful as an internal Android/Dalvik version number, then it's pretty useless for us to add custom code to handle it.

A simple fix might be to only warn, not fail, when the version reported by this property is not within the expected range.

Show
Charles Oliver Nutter added a comment - Yeah, I might have marked this as WONTFIX, since it seems completely wrong for them to report what I assume is a Dalvik-related version number rather than a Java version number. I'm still open to a patch if the specification version on Android is meaningful ...specifically, if it tells us something we could use to pick better APIs, as we do with Java 6 in some cases. If it's only useful as an internal Android/Dalvik version number, then it's pretty useless for us to add custom code to handle it. A simple fix might be to only warn, not fail, when the version reported by this property is not within the expected range.

People

  • Assignee:
    Unassigned
    Reporter:
    Uwe Kubosch
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: