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

        Hide
        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
        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
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: