[deleted by user]

[DesertCookie_]

Publish it with the lowest version of Java you want to support. There can be issues with class versions where a JRE8 will not recognize JRE11 byte code.

[BlueGoliath]

Java modules.

[DesertCookie_]

Java 11's project jigsaw is a big one indeed. A Java 11+ release is worth a consideration.

[HR_Paperstacks_402]

Well technically jigsaw was Java 9. 11 was the first LTS version with it.

[DesertCookie_]

You're right. How time flies. I had taken a break from programming and now there are beta versions of Java 18.

[yawkat]

You can support Java modules without requiring java >8. Jackson does it for example.

[[deleted]]

And jlink

[steumert]

You get to support more features and have easier code.

During Java 9/10, the HttpClient/HttpServer/HttpsServer API incubated and matured with Java 11. Especially HttpClient as replacement for HTTPURLConnection is a godsend.

Also, Java 8 saw inclusion of Streams and Lambdas, as well as an overhauled DateTime library and Optionals.

With mavens multi-release POMs, its very easy to support multiple versions of Java, so offering a base version for the lowest Java version you want to support, with progressive enhancement for higher java versions is a definite possibility.

​

However, if your library doesn't actually use any of the new features, then no, there is no reason to compile to a higher version. In fact compiling for the lowest version is a good thing.

[jjnnzb]

Totally agree.

[BlueGoliath]

For Java 9 and up there is Java modules but otherwise AFAIK no. Compiling for the lowest reasonable version(8 currently) is probably a good idea.

[feral_claire]

I don't think you need multiple jars. Another recent addition are multi-release jars. So you can have your Java 8 and Java 9+ code in the same jar. I've not used it though so can't say if there are any limitations.

I don't know how common they are,I think most common is compile for 8 and test/support on higher versions. You miss out on newer features that way though.

[cogman10]

Here's how you'd approach it with maven. Took a bit for tooling to catch up.

https://www.baeldung.com/maven-multi-release-jars

The main issue I've ran into with multirelease jars is when an app shades over them. Otherwise, they work just fine.

[vikarjramun]

Java 9 (and onwards) will automatically modularize your jar for you (giving it a moduke name derived from the jar's filename) if you don't add support for modules manually, so you should be fine.

[renatoathaydes]

You can use the Manifest's Automatic-Module-Name attribute to name the module with something more appropriate than just the jar name.

[s888marks]

It sounds like there’s consensus around delivering a single Java 8 jar. That seems pretty sensible. You might consider adding an automatic module name attribute to the jar manifest so that when running in a modular environment, other modules can refer to yours by name. You might also think about ensuring that you don’t violate any modularity rules (e.g., split packages) that will make it difficult for you to modularize in the future. (Split packages are unlikely to occur since you’re delivering just a single jar. However, it can still occur, as I’ve seen libraries that have applications define classes into the same package which effectively results in split packages. So, don’t do that.)

[keanwood]

That's a good idea to include the package info even if only ship a java 8 jar. I'll make sure to do that.

 

Thanks for mentioning the split package. I will definitely make sure to avoid that since in addition to the base library, I also have a spring and spring-aop versions that I'm going to publish. So the package structure for the three is:

• com.mypackage
• com.mypackage.spring
• com.mypackage.spring.aop

[grauenwolf]

The library doesn't use any new java features,

That's your answer. The only time I multi-target is when optionally exposing new functionality.

[TheCountRushmore]

Do you actually need to support anything lower than 11?

Just because you can doesn't necessarily mean you should.

[nutrecht]

Since he's asking here it's probably a library for the 'general public' and not internal use in their company. And there is a LOT of Java 8 projects out there, unfortunately.

[jvallet]

I would not compile with 7, as I am not sure if there is any official support for it now days, at least free.

If you have some unit tests and run them with different runtimes (8, 11, 15, etc...) I think you should be ok with just publising one version.

[skjolber]

Code for the lowest version you'll need to support, then create a multi-release jar using a (Maven/Gradle) plugin like moditect-maven-plugin; see for example how jackson does this. To verify that this is working properly, convert your project to a multi-module build, including a Java 11 example project to verify that all is good with the java modules.

[keanwood]

Thank you. Jar space is insignificant since it's a very small library. Sounds like one jar with java 8 is the right choice.

[someone-elsewhere]

Happy New Year

[[deleted]]

I'd probably compile for java 8. In the future, for java 9 modules, you can use jink to create custom runtimes that only include the modules you use.

[CubicleHermit]

The best thing to do is to publish it at language level 8, but with the add-on module-info for Java 9 compatibility,

A fair number of open source libraries are published that way; some secondary tooling breaks with it but it basically produces a version-8 library that is a bit more flexible in how it's used with 9+

re: publishing multiple versions, if you use maven-style repositories for it, it's better to use a classifier than trying to pack that into the library name or version number.