Re: Maven Artifact JDK Suffix
От | Mark Rotteveel |
---|---|
Тема | Re: Maven Artifact JDK Suffix |
Дата | |
Msg-id | 4822999055c271ac624490a5e9f18625@imap.procolix.com обсуждение исходный текст |
Ответ на | Re: Maven Artifact JDK Suffix (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: Maven Artifact JDK Suffix
|
Список | pgsql-jdbc |
On Fri, 15 Jan 2016 06:56:54 -0500, Dave Cramer <pg@fastcrypt.com> wrote: > On 15 January 2016 at 06:51, Mark Rotteveel <mark@lawinegevaar.nl> wrote: > >> On Fri, 15 Jan 2016 06:24:21 -0500, Dave Cramer <davecramer@gmail.com> >> wrote: >> > I would have to agree with this. I think people will be surprised (not >> in a >> > good way) if we upgrade to java 9 and all of a sudden maven pulls down >> JDBC >> > for java 9 >> >> As far as I know, starting with Java 9 this problem could be solved with >> multi-release JARs (JEP-238, http://openjdk.java.net/jeps/238). The main >> content could then be Java 8, and the Java 9 versions of classes could go >> into META-INF/versions/9 (assuming that is the final way JEP-238 will be >> realised, I am not sure if it is already in). For efficiency it would be >> best to only put in a Java 9 version of classes that really need a Java 9 >> version. >> >> Yes, but in my example the customer would still be running Java 8. Does > Java 8 know how to read this jar Yes it would, because Java 8 doesn't know about META-INF/versions/... so it will just read the (Java 8) classes in the root. The idea behind JEP-238 is that Java versions that don't understand it will use the classes in the root as they would normally do, and that Java versions that do understand it will first read a class in their version folder (if it exists), and fall back to the classes in the root if no version-specific class is found. At least, that is the theory as I understand it. Mark
В списке pgsql-jdbc по дате отправления: