Java 9 support

Hi, 

is ObjectDB supporting Java 9 already ?
If not when can we expect the support for it ?

It will hopefully be supported soon. We will know more after the formal release of Java 9.

Java 9 has been formally released today, so we will be glad to be notified once ObjectDB will support it.

Thx!

Initial support of Java 9 is available now in version 2.7.2.

No Java 9 module yet (we may have to wait with that to JPA 2.2) but you should be able to use ObjectDB 2.7.2 as a jar now with Java 9.

Any feedback will be welcome.

You asked for feedback ...

With the help of a tool I wrote, and some manual manipulation, I have successfully created a 100% modular JAR Java 9 version of my application (no --class-path, no unnamed module, no automatic modules, no --add-reads/opens/exports, etc.)  This included ObjectDB 2.7.2_05 modular JAR (I repackaged it to make it a true module).

I can confirm, for my use case of ObjectDB, that ObjectDB 2.7.2_05 runs just fine with Java 9.  (Yea!)

Is the switch to Java 9 worth it?  Yes.  Although it took about 6 weeks to migrate everything, significant benefits resulted.  (Roughly speaking, installer shrunk about 50%, load time about 25% faster, updates about 50% smaller and one update shrunk from 75 MB to 1 MB!)

Thank you to ObjectDB for providing early support for Java so this migration was possible.  Thanks to ObjectDB for making reliable code that allowed such a migration to execute without issues too, including using previously existing customer databases.

P.S.  With the new self-created modular JAR of ObjectDB, I no longer require a second objectdb.jar to make the call to Enhancer as described in issue (ObjectDB Enhancer Tool in Java 9).

Great news. Thank you for the update.

If you can provide more details, including sharing the ObjectDB 2.7.2_05 modular JAR that you have created, we may be able to integrate it into our build process.

Attachments uploaded.  The ObjectDB modular JAR (and supporting JARs) I created, and the notes that go with them.

Looks excellent. Thanks.

Some questions regarding the ObjectDB module:

• How did you set the directives (requires, exports, opens, uses, provide, Module packages)? e.g. do we need requires transitive?  do we need to export all these packages?  why do we need opens com.objectdb.image? and these 5 uses directives?
• What are the expected implications of an empty org.springframework.orm.jpa.vendor.AbstractJpaVendorAdapter class? Could it cause a conflict with the real class?
• you have suggestions for further improvement on ObjectDB side, e.g. breaking com.objectdb to com.objectdb, com.objectdb.jpa and com.objectdb.jdo? com.objectdb.spring? removing some dependencies, e.g. on java.desktop? etc.

Use the documentation found here: http://openjdk.java.net/projects/jigsaw/ (and the items it references).  For example, in (http://openjdk.java.net/projects/jigsaw/spec/sotms/#automatic-modules) the discussion about Automatic Modules states,

"There is no practical way to tell, in advance, which other modules an automatic module might depend upon.  After a module graph is resolved, therefore, an automatic module is made to read every other named module, whether automatic or explicit:".

So kind of taking that approach with unknown modules and their unknown dependent modules and how they all work and access each other and ... yikes! So my tool takes the approach of trying to detect what is offered by a package and "well, I better make it accessible because I don't really know which is and is not supposed to be accessible, but if every module can access it, then at least it will work, until I can get the real module from the actual author with true Java 9 implemented knowledge."

My tool uses jdeps (https://docs.oracle.com/javase/9/tools/tools-and-command-reference.htm#JSWOR596) to figure out the dependencies and then makes things wide open (my application is, after all, the only one that uses these packages, so my security is "safe", which would be different if I were packaging a module for use by third parties.)  This implies why I use "requires transitive" (used to be called "requires public" in the documentation) in my tool to make sure that inter-module dependencies are allowed without me having to know what is really required by what.

You can see that my tool and approach is designed for "just me" to get true Java 9 without having to wait on third parties but at the sacrifice of having everything exposed (which is fine because I am the only one using my modules).  But, for ObjectDB, which is to be giving to the world to use, more accurate use and packaging is required.

That is the background information bases.  Let me see if I can now answer some of your questions based on that (and the implied knowledge one has from looking at that documentation.)

My tool uses the jdeps tool to get knowledge and then acts upon that with the qualifies from issues stated above.  When jdeps indicates that a package is "not found", "requires" is added by my tool, but always as "requires transitive" to make sure other modules that need this will automatically be allowed access.  "exports" is given for *any* packages found in the module my tool is packaging.  (Assume they are all desired to be accessible by other modules so make them accessible.)

Imaging that a class uses getResource() to load an .pdf.  Java 9 will require that an "opens" statement gives access to that package to let someone else "open" that resource.  Again, assume that all resource are required by everyone so all accesses work, so "opens com.objectdb.image" was given because a non .class file was detected in that packaged by my tool.  (All .class files are automatically considered "opened", so we only need to add "opens" for other files.)  Hence my tool created "opens com.objectdb.image", but those are images used only by ObjectDB tools, so an ObjectDB module created by ObjectDB would not include such a directive.  (But ObjectDB might include an opens directive qualified to allow the image package to be opened by the ObjectDB Explorer package.)

Still referencing that Java referenced documentation, one can figure out the "uses" and "provides" directives.  ("uses" is issued by my tool when ".spi" packages are encountered.  (Service Provider Interfaces, so services can access implementations of those services).  "META-INF/services" is scanned by my tool to see the other side and issue a "provides" statement.)

So, an ObjectDB modular JAR likely would not need "transitive", would not "export" all the packages that my version did, not use "opens com.objectdb.image" (at least not for the "world" to see), etc.  Since "org.springframework.orm.jpa vendor.AbstractJpaVendorAdapter" is a requirement by ObjectDB because of a package dependency, but I don't use that dependency or activate any ObjectDB code in my usage module that would then activate that AbstractJpaVendorAdapter, I an safely "stub" out that build time dependency with a no-op.  >> I << have no conflict with the real class therefore since the real class isn't even in my list of packaged modules).  ObjectDB would likely either remove that dependency, or provide some correct module dependency directives and require their customers to include some org.springframework module when using ObjectDB.

That leads to the last question you asked.  My off the cuff (I didn't think about it much and I would rather think about it a lot before giving REAL suggestions) response is the ObjectDB would probably benefit in their going-to-java-9 migration by trying to separate out all third party modules and removing all dependencies as possible from other modules so ObjectDB can be as independent at possible and just use the required dependent modules from either Java 9 or third parties that provide a true Java 9 compliant stand alone module.

I have run out of time for right now.  I can answer followup questions later today.

I'm back for a few hours.  A follow up summary.

For >my needs< I took the provided ObjectDB JAR and wanted a Java 9 module while guaranteeing compatibility with existing code and customer databases.  How best to do that?  Use the third party items from inside ObjectDB instead of taking the risk of getting some updated third party module (for example, javax.jdo) that might cause some unforeseen incompatibility and cause some database corruption.

So I created my own javax.jdo Java 9 module for ObjectDB to use, and I >know< it will be compatible because it is the same class files for javax.jdo that ObjectDB was using.

My goal of Java-9-right-now is achieved yet with 100% compatibility.  Now I just wait for third parties (like ObjectDB) to provide a fully designed and tested Java 9 module that is known to work with specified third party modules (like javax.jdo released by its owner).  Then I just swap out my self made modules with their new ones.  (Sounds good in theory, anyway.  We shall see if it works.  ;)  )

In the meantime, I am reaping the Java 9 benefits without having to wait for all third parties (my dependencies) to become 100% Java 9 released updated.

I hope all this information helps ObjectDB get to that Java 9 release faster, and helps forum users get their applications to Java 9 quicker using some of the thoughts described in this thread.  Good luck to us all.

Thank you for the detailed answers. Your approach is clear and very logical.

As a result of your initiative we hope to be able to release Java 9 modules earlier. As soon as this is ready your feedback, as a user that is using Java 9 modules with ObjectDB,  would be very important.

I just ran a performance test of our product ("MoxyDox") using ObjectDB and Java 9.  Here are the results.

Using the slowest server provided by Amazon Web Services (a "t2.nano", which has only a single slow CPU and only 0.5 GiB of RAM) and the incredible abilities of ObjectDB ultra fast database technology, MoxyDox is able to, on average, perform a fully encrypted client-to-server-to-database-to-server-to-client round trip write operation of about 31 MB per second!  (10 MB in 320 ms.)  Reads are about 43 MB per second!  Using ObjectDB on faster servers with more resources, MoxyDox can achieve even faster rates.

Great news. Thank you for reporting!

Hi there,

It's been some time since Boyd managed to construct his own module of ObjectDB for Java 9, so I'd like to ask what's the state of the official Java 9 module for ObjectDB ?

I just got a warning from Oracle about ending support for Java 8, so it seems to me, that after January 2019 we will have to switch to Java 9 (at least).

https://www.oracle.com/technetwork/java/eol-135779.html

So I would like to know if there will be an official Java 9 module or I will have to do it on my own like Boyd did.

Thanks!

Note that ObjectDB can be used with Java 9 already, exactly as with Java 8, so the end of life of Java 8 should not be a real problem.

Only Java 9 modules are not ready yet as with many other libraries and tools for Java that can be used with Java 9 but with no support of the new Java 9 modules yet (including JPA and JDO that ObjectDB is based on).

Support of Java 9 modules for ObjectDB will be released when ready.