It would be very nice if derby could be updated

[steinarb]

It would be nice if derby could be updated from the now 6 year old 10.14.2.0.

I did a quick search through the closed issues and found this (JDK 8 compatibility keeps derby at 10.: #351 (comment)

And I had already guessed from the release notes that JDK 8 was the reason for staying with ths version

But the derby version is 6 years old now. Maybe it is time to let JDK 8 compatibility go? Are there many people requesting and requiring it?

My problem: I use pax jdbc-config to provide me with a Datasource from config and has used this to run my applications with PostgreSQL as the production database, and using in-memory derby with dummy data for testing in local karaf and in pax exam integraion tests.

However, with a liquibase upgrade a while back my pax exam tests started breaking: liquibase/liquibase#5357

Funnily enough using derby in real karaf (rather than pax exam karaf) worked fine, so it wasn't possible to debug this. I suspect a race condition somewhere.

A fix was introduced in liquibase and the above issue was closed, but the fix wasn't consistent (testing with liquibase 4.26.0 it worked one time out of 5 tries, I think...?) and with 4.27.0 the problem has starting breaking the pax exam tests not just of the liquibase karaf feature, but of my web applications using liquibase as well.

My workaround for the liquibase karaf feature pax exam test was to throw out derby and replace it with h2 (at least for the pax exam test).

[grgrzybek]

Thanks for the report and some nice arguments.

Actually we should be able to preserve JDK8 compatibility where possible and simply highlight that some Karaf features (and JDBC drivers) require newer JDK. maven-compiler-plugin can stay at JDK8 (because we have no reason to upgrade Java source code to newer features), but drivers should be upgraded. No need to stay at ancient Derby version...

Please give me some time to think and prepare an update.

[steinarb]

A note on using derby Use derby 10.16.1.1 (which is the current version for Java 17): it has a completely broken OSGi support

1. Compared to 10.14.2.0 the 10.16.1.1 has been split up into multiple jar files
2. artifactId derby is an OSGi bundle with an Activator, but what that Actvator does I'm unsure about (looks like it registers a Driver with some static class, but that won't work in OSGi unless that class is part of the JRE...), no DataSource or DataSourceFactory in this class
3. The DataSourceFactory for embedded derby resides in the jar file with artifactId derbytools, this jar file isn't a bundle so if you want something from here you will need to slurp the class files into the bundle
4. The embedded DataSourceFactory relies on stuff from package org.apache.derby.client
5. The org.apache.derby.client package resides in the jar file with artifactId derbyclient, however the derbyclient is a bundle, but one that doesn't export the packages it contains (it exports package org.apache.derby.jdbc, which it does not contain)

So in conclusion: derby has OSGi support that is thoroughly broken.

Only way to fix it is to pull everything into the jar creating the DataSourceFactory, or rebundle the derby jars (or create an issue with derby and provide a fix for OSGi bundling everything).

But the problem with providing a fix was that I couldn't make heads or tails of the build system of derby. There was an and build and there was a maven build in a completely separate place to the source code

Oh well!

[grgrzybek]

But the problem with providing a fix was that I couldn't make heads or tails of the build system of derby.

Still ANT-based? :)

[steinarb]

>>>> Grzegorz Grzybek ***@***.***>: Still ANT-based? :)

There is both ANT build files and a maven build. I don't know which one is used by the derby team and/or in releases? The maven build tree is in a separate directory tree from the code (which probably makes for a lot of config in the pom files?). Also derby is still using subversion which makes it harder to provide a patch (I haven't used subversion (much) since 2010 or thereabouts). So the barrier to provide an OSGi fix for derby feels high! :-)