Using Ebean v12 with Java 11

[mindas]

https://ebean.io/docs/getting-started/ says Java 11 is required for Ebean v13 or later.

Is there any piece of documentation which suggests whether Java 11 can be used with Ebean v12?

To avoid XY problem. We're using Playframework v2.8.17 on Java 11.0.17.
https://github.com/playframework/play-ebean suggests that the newest supported version of Ebean is 12.16.1 which is what we use. And if you look at the official Playframework documentation they say Java 11 is supported.

That said, I've noticed odd bugs, such as:

Caused by: java.lang.IndexOutOfBoundsException: The size must be at least 1
	at io.ebeaninternal.server.deploy.id.IdBinderSimple.getIdInValueExpr(IdBinderSimple.java:135)
	at io.ebeaninternal.server.deploy.BeanDescriptor.parentIdInExpr(BeanDescriptor.java:1636)
	at io.ebeaninternal.server.deploy.BeanPropertyAssocManySqlHelp.addWhereParentIdIn(BeanPropertyAssocManySqlHelp.java:121)
	at io.ebeaninternal.server.deploy.BeanPropertyAssocMany.addWhereParentIdIn(BeanPropertyAssocMany.java:340)
	at io.ebeaninternal.api.LoadManyRequest.createQuery(LoadManyRequest.java:89)
	at io.ebeaninternal.server.core.DefaultBeanLoader.loadMany(DefaultBeanLoader.java:37)
	at io.ebeaninternal.server.core.DefaultServer.loadMany(DefaultServer.java:529)
	at io.ebeaninternal.server.loadcontext.DLoadManyContext$LoadBuffer.loadMany(DLoadManyContext.java:222)
	at io.ebean.common.AbstractBeanCollection.lazyLoadCollection(AbstractBeanCollection.java:101)
	at io.ebean.common.BeanList.init(BeanList.java:139)
	at io.ebean.common.BeanList.iterator(BeanList.java:334)
	at java.base/java.util.Spliterators$IteratorSpliterator.estimateSize(Spliterators.java:1821)
	at java.base/java.util.Spliterator.getExactSizeIfKnown(Spliterator.java:408)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
	at MyPojo.getFoo(MyPojo.java:123)

Here what happens in MyPojo.java:122 is that we're calling

   foos.stream()
      .sorted(comparing(Foo::getBar))
      .collect(toList());

foos in the above example is a managed list of entities. Exception seems to happen when this list is empty.
There are other scenarios too, e.g. new ArrayList<>(managedListOfEntities) and so on.

Should I be reporting individual bugs for such cases or ebean v12 doesn't work with Java 11 by definition? Many thanks.

[rob-bygrave]

Java 11 is required for Ebean v13 or later.

Java 11 OR HIGHER ...

The CI builds for Ebean run against 11, 17 GA and EA. Currently GA is 20 and EA is 21 Early Access and this moves automatically as the GA and EA versions increase, say when 21 comes out then GA will be 21 and EA will be the 22 Early Access. Just to say this is enabled by Oracle providing the EA, GA GitHub actions.

So in this way, people should be pretty comfortable using Ebean 13.x with any JDK that is 11 or higher (heck, that even includes the Early Access release which today is Java 21 EA).

ebean-agent

The main note about using later versions of JDK is that the Bytecode version increases. The ebean-agent uses the ASM library (it repackages it and includes it in ebean-agent) and this allows the ebean-agent to support the latest Bytecode and also older Bytecode.

The ebean-agent actually supports Java 8 and higher [and it must continue to support Java 8].

The latest version of ebean-agent (say 13.17.4 today) is expected to support Java 8+ and can be used with Ebean v11.x, Ebean v12.x and Ebean v13.x. For example, we should be able to use ebean-agent 13.17.4 with ebean 12.x (and people using the latest version of the IntelliJ plugin will indeed be doing this, this is all expected and good).

So we also expect to be able to use Java 20 with ebean-agent 13.17.4 + ebean 12.x.

Supporting latest Java version

Ebean supporting the latest Java version really translates into:

• ebean-agent being up to date with the latest ASM library (and the ASM project is very well maintained, pretty awesome imo)
• Using this latest version of the ebean-agent with Ebean 11.x, Ebean 12.x or Ebean 13.x
• Ebean internally not using anything in JDK 11 that is now illegal in a later JDK (due to the tightening restrictions that later JDKs have etc). We've also migrated away from using things that are deprecated in later JDKs and migrated to things that support Loom / Virtual Threads. Right now I feel we are nicely on top of this, there is nothing outstanding here for ebean to do at the moment.

Is there any piece of documentation which suggests whether Java 11 can be used with Ebean v12?

There are probably not docs for this no.

Yes, Ebean v12.x should be able to be used with Java 11. I know of no reason why it would not work.

Moreover, Ebean v12.x should also with Java 20 AS LONG AS we use ebean-agent 13.17.1+ to do the Bytecode enhancement. I know of no reason why that would not work.

reporting individual bugs for such cases or ebean v12 doesn't work with Java 11 by definition?

Yes, log bugs. Note that the first thing someone needs to do is confirm that the bug still exists in the latest version of ebean.

So yes create a test case, then bump to ebean latest and confirm if the issue still exists. Then log it with the results of that. I feel it is extremely unlikely that an issue in Ebean 12.x will be related to the Java version.

Cheers, Rob.

[mindas]

Many thanks for such a detailed answer!

The additional detail I was able to find was the fact that the entire code block is being called from a Java stream using .parallel(). Something like this:

      var pagedList = DB.byName("...").find(SomeClass.class)
        .where()
        // some query condition
        .setMaxRows(...)
        .findPagedList();

      pagedList.getList().stream()
          .parallel()         // <-- I believe this was the culprit
            .map(c -> ...)   // ...few layers down there was  MyPojo.getFoo mentioned in my above post
            .collect(...);

As soon as I removed the speculative .parallel() call the exception went away. Maybe this will be useful to someone who comes across this.

I've tried to reproduce this in an isolated environment without much success, sorry about that.