BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News QCon New York 2017: Migrating Speedment to Java 9

QCon New York 2017: Migrating Speedment to Java 9

Dan Lawesson, CSO at Speedment, presented Migrating Speedment to Java 9 at this year’s QCon New York 2017 Conference. His presentation covered:

  • A brief overview of Speedment
  • A brief overview of Jigsaw
  • Migrating Speedment to Java 9

Speedment

Lawesson introduced Speedment, an object-relational mapping (ORM) tool for creating database applications. He demonstrated how to connect to an existing database using their compile-time code generation tool and build queries using Java 8 streams.

Lawesson explained that the traditional ORM approach to building database applications uses a two-step imperative approach, that is, explicit SQL statements and Java streams. On the other hand, Speedment is fully declarative such that Java streams express both database and JVM operations where the runtime determines the work split.

Speedment is available in both open source and enterprise editions. New to Speedment since the release of version 3.0 is Initializer, a utility that generates a Maven project based on user input.

Jigsaw

Lawesson discussed the significance of reliable configuration built into the Java Platform Module System (JPMS), also known as Project Jigsaw and JSR 376. Reliable configuration means that a package must be confined to a single module. As shown in the diagram below, packages may not be split across modules.

Lawesson also discussed how automatic modules allow for a smooth transition from Java 8 to Java 9, but also give rise to split packages due to the module path depending on the class path. Jigsaw is fundamentally different from OSGi, stated Lawesson, explaining that OSGi allows for lazy loading, dynamically adding packages, and package splitting.

“Jigsawing” Speedment

Speedment is currently migrating their own codebase to Java 9. For Speedment Open Source, the migration process is relatively straightforward because Speedment does not rely on third-party libraries or the unsupported API, sun.misc.Unsafe. He detailed their scripting process for migration:

  • Create a separate directory containing all of the modules
  • Move each source code package to its respective module
  • Add an empty module-info.java file
  • Then perform the usual sdlc loop:
    • Compile
    • Parse and fix
    • git add
    • git commit

While the migration of Speedment Open Source is relatively straightforward, Speedment Enterprise is a challenge due to the use of third-party libraries and sun.misc.Unsafe.

Lawesson spoke to InfoQ about Speedment and how they are addressing the challenges of migrating Speedment to Java 9.

InfoQ: What makes Speedment unique over other Java ORM frameworks?

Dan Lawesson: Mainly two things: the fully declarative Streams API and the acceleration of queries that can take place in the framework without any alteration to the user application. Speedment uses a pure Java Streams API which allows for declarative application code that expresses what it intends to do with the data in the database, while it is up to the Speedment framework to figure out the how. Since an application leveraging Speedment therefore does not contain any query language, the Speedment framework may transparently accelerate queries by means of an off-heap memory data store.

InfoQ: How do you plan to address the issues of migrating Speedment Enterprise to Java 9?

Lawesson: The issues we ran into are reasonably straightforward to solve. We are laying them out on the road map but since we are currently heavily involved in customer projects as well as developing new core features, the full migration to a Jigsaw modularized Speedment platform may have to wait a few months.

InfoQ: In your presentation, you stated, “Maven does not currently coexist well with OSGi bundling and Jigsaw.” Almost a year ago, InfoQ published a two-part series discussing the potential interoperability between OSGi and Jigsaw. What are your thoughts on the interoperability between OSGi and Jigsaw?

Lawesson: My remark was meant as a way to share a practical experience rather than a conceptual analysis, and was spurred by the fact that we had to disable OSGi bundling in our Maven projects to be able to compile. As mentioned in the talk, having limited time on our hands we decided not to spend too much time trying to work around issues that will surely be solved by others in due time. The Maven plugin for OSGi bundling not working properly with Java 9 at the time we tested it is clearly one of those things.

On a more general note, there are no conceptual problems in having both OSGi and Jigsaw in the same project. However, some of the benefits from the strict Jigsaw straightjacket are lost if keeping OSGi, simply because OSGi is dynamic by nature. For example, a fully reliable configuration of a Jigsaw system in a single class loader cannot be achieved in a dynamic OSGi setting with bundles isolated in separate class loaders, simply because OSGi bundles and Jigsaw modules are different things that solve different kinds problems.

The Speedment platform does not have many dependencies and leads itself well to strict Jigsaw modularization, much in the same was as the JDK itself does. However, the reason for us supporting OSGi has always been more as a service to our users rather than for our internal code structure. Judging from the widespread concerns about Jigsaw, some of them highlighted in the articles you mentioned, that consideration is likely to remain relevant for a long time.

InfoQ: How would Speedment have voted on the original JSR 376 ballot in early May?

Lawesson: My personal opinion is that that community consensus on a fundamental disruptive change such as Jigsaw is vital to avoid future fragmentation of the user base. Therefore, a NO vote (clearly in the sense "no, not yet" rather than "no we do not want it") in early May was the right way to go.

InfoQ: What’s on the horizon for Speedment?

Lawesson: We are currently working on implementing new transactions support and more efficient aggregations. Improving integration with Eureka and Ribbon to allow for cluster solutions is also a feature under ongoing development. Full Jigsaw modularisation of the code base is on the road map but nothing we can spend time on right now.

InfoQ: How long have you been with Speedment and what are your current responsibilities?

Lawesson: I have been with Speedment for a year and I am the chief science officer, working with development, architecture, tech writing and sales support.

Rate this Article

Adoption
Style

BT