You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.com> on 2018/08/11 11:35:07 UTC

Objection to require JDK 9+ for building (not running) SIS?

Hello all

Is there any objection to require Java 9 or 10 for *building* (not
necessarily running) Apache SIS? The project would continue to target
Java 8 at runtime for now, since SIS is not yet modularized. More
specifically, we would use the "javac -release" option, new in Java 9,
for targeting the older release.

The reason is that starting with Java 9, the programmatic use (from Java
code) of tools like javadoc is much easier. I also hope that a long
standing bug cause javadoc generation to fail on master will be fixed by
upgrading those tools.

The modularization of Apache SIS is a separated topic (not part of the
request in this email).

    Martin



Re: Objection to require JDK 9+ for building (not running) SIS?

Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 11/08/2018 à 19:28, Werner Keil a écrit :

> If it's built like JSR 385 or 354 API there should be no problem
> combining e.g. Jigsaw with Java 8 backward compatibility.
>
Thanks. But our difficulty at this time is to apply "jigsaw modules" in
a project having many Maven modules. For example Maven aggregated
Javadoc does not yet work if the modules are jigsaw modules. The problem
is that Jigsaw and Maven expect different conventions in the way to
organize modules (Jigsaw wants source code in a directory named after
the module name), and I have not yet found how to make Maven
jigsaw-friendly in a multi-modules project.

    Martin



Re: Objection to require JDK 9+ for building (not running) SIS?

Posted by Werner Keil <we...@gmail.com>.
If it's built like JSR 385 or 354 API there should be no problem combining
e.g. Jigsaw with Java 8 backward compatibility.

Werner

Martin Desruisseaux <ma...@geomatys.com> schrieb am Sa., 11.
Aug. 2018, 18:10:

> Thanks, I have pushed on the geoapi-4.0 branch (not yet on master); it
> is still possible to rollback if anyone object.
>
>     Martin
>
>
> Le 11/08/2018 à 13:38, Bruno P. Kinoshita a écrit :
>
> > +1 it shouldn't cause any trouble to end users, and release votes can
> still be validated against Java 8 (plus we can possibly make sure Travis CI
> and/or Jenkins are testing against both).
>
>

Re: Objection to require JDK 9+ for building (not running) SIS?

Posted by Martin Desruisseaux <ma...@geomatys.com>.
Thanks, I have pushed on the geoapi-4.0 branch (not yet on master); it
is still possible to rollback if anyone object.

    Martin


Le 11/08/2018 à 13:38, Bruno P. Kinoshita a écrit :

> +1 it shouldn't cause any trouble to end users, and release votes can still be validated against Java 8 (plus we can possibly make sure Travis CI and/or Jenkins are testing against both).


Re: Objection to require JDK 9+ for building (not running) SIS?

Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
+1 it shouldn't cause any trouble to end users, and release votes can still be validated against Java 8 (plus we can possibly make sure Travis CI and/or Jenkins are testing against both).

Cheers
Bruno




________________________________
From: Martin Desruisseaux <ma...@geomatys.com>
To: Apache SIS <de...@sis.apache.org> 
Sent: Saturday, 11 August 2018 11:35 PM
Subject: Objection to require JDK 9+ for building (not running) SIS?



Hello all


Is there any objection to require Java 9 or 10 for *building* (not

necessarily running) Apache SIS? The project would continue to target

Java 8 at runtime for now, since SIS is not yet modularized. More

specifically, we would use the "javac -release" option, new in Java 9,

for targeting the older release.


The reason is that starting with Java 9, the programmatic use (from Java

code) of tools like javadoc is much easier. I also hope that a long

standing bug cause javadoc generation to fail on master will be fixed by

upgrading those tools.


The modularization of Apache SIS is a separated topic (not part of the

request in this email).


    Martin