+1 also from my side: stick with 8, ensure it builds with later versions. Am 06.03.2018 21:30 schrieb "Aaron Coburn" <[email protected]>:
> Just to be clear, I am not suggesting the addition of any Java 9 or 10 > features to Tamaya. I suspect that it makes much more sense for the source > code to continue to target Java 8. I am just interested in making the > source code *buildable* on the newer JDKs. > > > On Mar 6, 2018, at 3:07 PM, Werner Keil <[email protected]> wrote: > > > > Actually a Multi-Release JAR if we found that useful (with a new JDK > every 6 months it seems tempting or even inevitable) is not built with Java > 9 or 10, the plugin states it should be with Java 8, but thanks to the > Multi-release feature and META-INF it’ll work with different versions. > > > > I am not sure, how it deals with e.g. a class that relies on entirely > new language Features of Java 10 or 11 like „var“ etc. that someone has to > find out. I tried to build JARs with a module-info under JDK9 and it would > no longer run on a JVM before Java 9. > > Correct. If the source code itself targets Java 9 (e.g. with the > module-info.java file), then it becomes runnable only on Java 9+, unless > you make use of a Multi-Release JAR. And the Maven tooling for > Multi-Release JARs is still catching up (at least it was when I last > checked into this). > > > I don’t think we want to be trapped in a Java „Version-Hell“ so at least > Java 8 should still work for some time as the Minimum Version. > > Yes, exactly. Quite a few Apache projects are staying on Java 8 at least > until there is another LTS version available (i.e. Java 11), and from the > perspective of making Tamaya easy to adopt in other projects, there are > good arguments for remaining on Java 8 for now. > > Regards, > Aaron > > > > > > From: Aaron Coburn > > Sent: Tuesday, March 6, 2018 21:01 > > To: [email protected] > > Subject: Re: Java 9 & 10 > > > > Hi, > > > > Travis-CI currently supports Java 9 builds, which would be simple to add > to the current .travis.yml configuration. It is possible to test Java 10 on > Travis but it requires some acrobatics (find the latest EA version by > parsing some HTML, download the JDK artifact and then install it). > Including CI support for JDK 10 is most likely not worth the effort in the > context of Travis. > > > > For the Apache Jenkins infrastructure, it seems that Java 9 and 10 are > both available: https://cwiki.apache.org/confluence/display/INFRA/JDK+ > Installation+Matrix <https://cwiki.apache.org/ > confluence/display/INFRA/JDK+Installation+Matrix> > > > > Regards, > > Aaron > > > >> On Mar 6, 2018, at 2:17 PM, Oliver B. Fischer <[email protected]> > wrote: > >> > >> Hi Aaron, > >> > >> as far I know we don't have any CI job for Java 9 or 10. So it would be > difficult to maintain such changes without breaking it. > >> > >> I could check Apache's Jenkins if both JDK versions available on > Jenkins. > >> > >> Best, > >> Oliver > >> > >> Am 05.03.18 um 15:53 schrieb Aaron Coburn: > >>> Hi, > >>> I am a bit new to Tamaya, so apologies if this has already been > discussed. It is clear that the codebase targets Java 8. It is also > entirely _usable_ on newer (jdk9 & jdk10) platforms. However, it is not > currently possible to build Tamaya on jdk9 or jdk10. My first question is: > should it be possible to build Tamaya on the latest JDK? > >>> In fact, the only impediment to building on jdk9 is the > karaf-maven-plugin. In particular, some Java EE libraries are no longer on > the classpath by default: javax.xml.bind and javax.activation. With jdk10, > these libraries will no longer be included in the Java SE at all. Adding > those dependencies directly to the plugin configuration or upgrading to the > latest (milestone) Karaf release makes it possible to build on jdk9. > >>> Building on jdk10 has the additional problem of the javadoc plugin not > being able to parse the JVM version string with commons-lang 3.5 release. > Forcing the use of commons-lang 3.7 for the plugin solves that. > >>> Is this something you all would like to support? I can provide a pull > request for that. > >>> The other, related, issue has to do with the Java 9 module system > (JSR-376). Even while targeting JDK 1.8 for the Tamaya codebase, there is a > fairly simple thing that can be done to make the Tamaya codebase easier to > use with the Java 9 module system. Basically, it involves adding a > "Automatic-Module-Name: <module-name>" entry in the MANIFEST.MF file. > Practically, this means adjusting the various bnd.bnd files in the > codebase. For instance, the tamaya-core JAR would likely have a module name > of: org.apache.tamaya.core (typically, this would align with the existing > OSGi Export-Package). The tamaya-api JAR currently exports two packages > (o.a.t and o.a.t.spi), so perhaps the module name would simply be > org.apache.tamaya? I suspect that the various extensions would make use of > the current OSGi export naming convention for this, as with tamaya-core. If > this is something you'd like to have for the 0.4 release, I can also supply > a pull request for that. > >>> Also, I am happy to open JIRA issues for either or both of these > items, though I wasn't sure if you'd like to discuss either of these first. > >>> Thanks, > >>> Aaron Coburn > > > > > >
