Derby
  1. Derby
  2. DERBY-5419

Make Derby run on Oracle Java ME Embedded Client

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.8.2.2
    • Fix Version/s: 10.8.2.2, 10.9.1.0
    • Component/s: Services
    • Labels:
      None

      Description

      I tried running Derby on Oracle Java ME Embedded Client 1.0, and booting the engine failed:

      Caused by: java.lang.NoClassDefFoundError: java.nio.channels.OverlappingFileLockException
      at org.apache.derby.impl.io.DirStorageFactory4.newPersistentFile(DirStorageFactory4.java:57)
      at org.apache.derby.impl.io.DirStorageFactory.newStorageFile(DirStorageFactory.java:58)
      at org.apache.derby.impl.services.monitor.StorageFactoryService$1.run(StorageFactoryService.java:96)
      at java.security.AccessController.doPrivileged(Compiled Method)(AccessController.java:351)
      at java.security.AccessController.doPrivileged(AccessController.java:320)
      at org.apache.derby.impl.services.monitor.StorageFactoryService.<init>(StorageFactoryService.java:86)
      at org.apache.derby.impl.services.monitor.BaseMonitor.getPersistentService(BaseMonitor.java:1630)
      at org.apache.derby.impl.services.monitor.BaseMonitor.access$100(BaseMonitor.java:99)
      at org.apache.derby.impl.services.monitor.BaseMonitor$ProviderEnumeration.getNextStorageFactory(BaseMonitor.java:2146)
      at org.apache.derby.impl.services.monitor.BaseMonitor$ProviderEnumeration.hasMoreElements(BaseMonitor.java:2159)
      at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1516)
      at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:979)
      at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550)
      at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2697)
      at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:385)

      This seems to happen because Derby recognizes it as a Java 1.4 platform, whereas it's actually a CDC/FP 1.1.2 platform.

      1. d5419-1a-check-for-cdc.diff
        0.6 kB
        Knut Anders Hatlen

        Activity

        Hide
        Knut Anders Hatlen added a comment -

        Derby tries to find out if the JVM is a Java ME variant in the JVMInfo class. It uses the java.specification.name property to determine that. Currently, it checks if the property value starts with "J2ME", in which case it's recognized as IBM WCTME, or if it contains the two words "Profile" and "Specification", in which case it's recognized as phoneME.

        The property has this value on Oracle Java ME Embedded Client 1.0, which isn't recognized by either of the two checks:

        CDC 1.1.2 (JSR218)- FP 1.1.2 (JSR219) (SecOp 1.0)- PBP 1.1.2 (JSR217)- (RMI JSR66)- (JDBC JSR169)- (WebServices JSR172)- (Specification

        The attached patch makes JVMInfo also check if the value starts with CDC. With that change, the engine doesn't try to load modules that require Java SE on this platform, and I'm able to run some smaller tests. (I haven't managed to run suites.All yet, as it fails with an OOME after a while.)

        Show
        Knut Anders Hatlen added a comment - Derby tries to find out if the JVM is a Java ME variant in the JVMInfo class. It uses the java.specification.name property to determine that. Currently, it checks if the property value starts with "J2ME", in which case it's recognized as IBM WCTME, or if it contains the two words "Profile" and "Specification", in which case it's recognized as phoneME. The property has this value on Oracle Java ME Embedded Client 1.0, which isn't recognized by either of the two checks: CDC 1.1.2 (JSR218)- FP 1.1.2 (JSR219) (SecOp 1.0)- PBP 1.1.2 (JSR217)- (RMI JSR66)- (JDBC JSR169)- (WebServices JSR172)- (Specification The attached patch makes JVMInfo also check if the value starts with CDC. With that change, the engine doesn't try to load modules that require Java SE on this platform, and I'm able to run some smaller tests. (I haven't managed to run suites.All yet, as it fails with an OOME after a while.)
        Hide
        Knut Anders Hatlen added a comment -

        I only wish there were a more robust way to detect that we're running on Java ME. The CLDC spec defines a system property called microedition.platform, which has the value "j2me" on both phoneME and OJEC (don't know about weme and others). Unfortunately, the property value is defined to be implementation-dependent, so it might not be more reliable after all.

        In any case, I've now checked in the patch that improves the current logic so that it recognizes Oracle Java ME Embedded Client too.

        Committed to trunk, revision 1174646.
        Merged to 10.8 and committed revision 1174649.

        Show
        Knut Anders Hatlen added a comment - I only wish there were a more robust way to detect that we're running on Java ME. The CLDC spec defines a system property called microedition.platform, which has the value "j2me" on both phoneME and OJEC (don't know about weme and others). Unfortunately, the property value is defined to be implementation-dependent, so it might not be more reliable after all. In any case, I've now checked in the patch that improves the current logic so that it recognizes Oracle Java ME Embedded Client too. Committed to trunk, revision 1174646. Merged to 10.8 and committed revision 1174649.
        Hide
        Myrna van Lunteren added a comment -

        For what it's worth, weme (6.2) doesn't set this system property 'microedition.platform' at all.
        It does set the following which hint at j2ME or CDC Foundation information:
        java.specification.name: J2ME Foundation Specification
        java.specification.version: 1.1
        java.vm.specification.version: 1.0
        java.version: WECE J2ME Foundation Specification v1.1

        Show
        Myrna van Lunteren added a comment - For what it's worth, weme (6.2) doesn't set this system property 'microedition.platform' at all. It does set the following which hint at j2ME or CDC Foundation information: java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 java.vm.specification.version: 1.0 java.version: WECE J2ME Foundation Specification v1.1
        Hide
        Knut Anders Hatlen added a comment -

        Thanks, Myrna. Sounds like there's not many more robust options when it comes to properties, then. Maybe checking for the lack of the DriverManager class would work.

        Show
        Knut Anders Hatlen added a comment - Thanks, Myrna. Sounds like there's not many more robust options when it comes to properties, then. Maybe checking for the lack of the DriverManager class would work.
        Hide
        Knut Anders Hatlen added a comment -

        I just tried again with Oracle Java ME Embedded Client 1.1, and there the value of the java.specification.name property has changed to "Foundation Profile Specification", which is the same as phoneME reports. This means OJEC 1.1 is recognized by all the Derby versions that recognize phoneME, not only the versions that contain the fix for this issue.

        Show
        Knut Anders Hatlen added a comment - I just tried again with Oracle Java ME Embedded Client 1.1, and there the value of the java.specification.name property has changed to "Foundation Profile Specification", which is the same as phoneME reports. This means OJEC 1.1 is recognized by all the Derby versions that recognize phoneME, not only the versions that contain the fix for this issue.

          People

          • Assignee:
            Knut Anders Hatlen
            Reporter:
            Knut Anders Hatlen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development