Provide artifacts without JDK naming scheme

[ThomasReinhardt]

Sorry if that was discussed before. But the naming scheme makes upgrading painful. For example: we are currently depending on the -jdk15on artifacts as that is what our dependencies depend on (we are using maven, btw). So without manual work we are stuck at 1.70 as that was the last version with that naming scheme. Later releases use -jdk18on as is documented on the homepage.

Without that naming scheme we could just update the managed version and our transitive dependencies would also pull the updated artifact. Easy and also the standard maven way of managing complex dependencies.
But today if we want to upgrade we have to exclude the -jdk15on dependencies (from all our dependencies, there is no way to do that globally!) and introduce -jdk18on dependencies at the appropriate places of our build. At the time of writing our main product consists of nearly 300 artifacts and each of those has to be checked. Of course we are using tools like the maven-enforcer-plugin but that is still a big overhead to manage.

And in a couple of years when BC moves to e.g. jdk-11 as a base we have to review everything again.

As BC is security critical that is especially annoying as just using an older version is clearly not an option.

So I propose to create additional artifacts without a JDK version suffix. Those would always be the latest JDK base (so bcprov-1.78.jar would be identical to bcprov-jdk18on-1.78.jar today).

Also, I am not sure if artifacts with JDK specific names have any advantages at all. Because at build time there will be a compile error anyway - either because the artifact does not exist (as today) or because there is a bytecode version mismatch. And swapping binaries in installed programs would also just give a class loading error.

[dghgit]

This has never come up, probably because previously it was such a rare event, but I'll admit I see your point. One of the issues with jdk15on to jdk18on was we couldn't use the maven redirect as it did depend on what people were doing as to whether jdk18on was the right choice of jdk15to18on was.

If anyone else feels like weighing in feel free, for the moment I'll ponder it.

[mpretzer]

IMHO this is a major annoyance and I'm surprised it hasn't come up before.

There's probably a gazillion projects out there still using old versions and even duplicate jars due to some libraries using jdk15on and others jdk18on.

So yes, I'm all in favor of eliminating this problem.

[dghgit]

They're not duplicates though - there's a still a lot of environments where using a jdk18on jar will not work due to the multi-release classes, but a jdk15to18 will (even when the environment is running Java 8...). That's the reason for the names, so people have some idea what they'll wind up running.

That said, the idea of having something which just signifies "latest" isn't a bad one - it's just it will go with more than a touch of caveat emptor.

[mpretzer]

Sorry, bad wording. What I meant was that projects are having both jars on the classpath, which is even more of a problem when they are not duplicates. Often, projects will end up with different versions if they don't carefully manage their dependencies (which, of course one should, but...).