Il mar 15 ago 2017, 17:51 Gary Gregory <garydgreg...@gmail.com> ha
scritto:
> You will need the same tricks at runtime for the command line that
Maven
> might hide at build time... :-( I guess hacks like --add-modules
ALL-SYSTEM
> will become part of our daily grind...
>
Gary, I think you are right, scripts to launch applications will be
hacked
in the same way, at least during the transition.
New j9 applications which do not use the classpath will not suffer from
this problem. Anyway in order to launch a jigsaw enabled application you
have to change the arguments passed to the jvm and so to fully
migrate to
the new j9 style a lot of work is to be done.
For many developers most of the work life is bound to running maven
goals.
When I just wanted to try j9 I got into a lot of blocker issues. Now
we are
going to make the life easier to develop and test java8 applications and
gradually switch to java9
Cheers
Enrico
> Gary
>
> On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli <eolive...@gmail.com>
> wrote:
>
> > Il mar 15 ago 2017, 00:03 Tibor Digana <tibor.dig...@googlemail.com>
ha
> > scritto:
> >
> > > I do not want to be too pessimistic but the inheritance of
modules is
> > > crucial for all the world.
> > >
> > > The common sense tells me that I should not release Java 9 on
> September,
> > > 2017 unless Java EE application servers work properly.
> > >
> > > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS
and
> > > maybe we will find out new issues which regarding for module
> java.se.ee.
> > >
> > > Without waiting for JEE9 this release would be too fast.
> > > Oracle had an ambition to align JSE9 release with JEE9 however
JEE8
has
> > not
> > > yet been released even if the ambition was to develop JEE9 in
parallel
> > with
> > > JEE8.
> > >
> > > Isn't this too fast for the release of JSE9?
> > >
> >
> > We are all waiting java9 and all the new features, apart from
jigsaw.
> > I think that the strong encapsulation work will make development
of the
> jdk
> > more simple and new java releases will follow a faster pace.
> > I am really worried about the lack of interest in defining exacly at
> least
> > the behaviour of most used frameworks, first of all the wrb
> > applications/servlet world
> >
> > I am happy that the maven world will make it easy to switch from
java8
to
> > java9 ad far as we can. Maybe most of developers which are using
maven
> will
> > not see all the tricks under the hood
> >
> > Thank you
> >
> >
> > Enrico
> >
> >
> > > I understand that development parties of application servers and
> > libraries
> > > suppliers are slow but this still would not guarantee that
there is
no
> > risk
> > > that Jigsaw project made some mistake which (if happens) cannot be
> taken
> > > back after the final release of JSE9.
> > >
> > >
> > >
> > > On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli <
eolive...@gmail.com
> >
> > > wrote:
> > >
> > > > Il lun 14 ago 2017, 11:46 Tibor Digana <
tibor.dig...@googlemail.com>
> > ha
> > > > scritto:
> > > >
> > > > > Hello Enrico,
> > > > >
> > > > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > > > I need an approval for the Jira SUREFIRE-1403 for you and
Robert.
> Thx
> > > in
> > > > > advance.
> > > > >
> > > >
> > > > I will check as soon as I wil be back from vacation. Thank
you very
> > much.
> > > > For me it is very important
> > > >
> > > > >
> > > > > I have added integration tests for Failsafe plugin, added
> > > documentation "
> > > > > java9.md" and removed JAXB which is located in module
> > > > *javax.xml.binding*.
> > > > >
> > > > > *Here is a clarification on why I was unhappy with Java status
and
> > why
> > > > > Surefire project could not run with Java 9 and how it was
fixed:*
> > > > >
> > > > > Because of I used *javax.xml.binding*, plugin Failsafe did not
run
> in
> > > > > Java9.
> > > > > Reason is that module *javax.xml.binding* is however in
Java API
> but
> > > not
> > > > > propagated on classpath when running Maven process (different
> > situation
> > > > in
> > > > > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > > > > This is strange and will be strange for most people, for
instance
> in
> > > our
> > > > > *Java
> > > > > EE project using REST* the WildFly server has to use
> *"--add-modules
> > > > > ALL-SYSTEM"* in *jboss.sh* to make our applications working
again.
> > > > > As a solution in Surefire project I removed JAXB which was
simple
> XML
> > > in
> > > > my
> > > > > case but not simple in general.
> > > > >
> > > >
> > > > I will have to do it for several projects, or at leastleast
to add
> > > > java.se.ee, in fact many programs need JDBCTO and it is excluded
by
> > > > default, that is weird to me
> > > >
> > > > >
> > > > > Someone may say that "do not use Java 9 if you do not use
Jigsaw
> > > > > modularity".
> > > > > But there are reasons where you will use it.
> > > > > For instance new API in Java or Java EE 9 in the future.
> > > > >
> > > >
> > > > The main reason for migration is to keep up to date, java8 will
soon
> > > reach
> > > > EOL.
> > > > Java9 comes with many improvements that just upgrading will
speed
up
> > most
> > > > applications, just think about nee compat strings. New API are
great
> > and
> > > > were expected from long time ago, like the new Process API....
> > > >
> > > >
> > > > > I do not think that using *"--add-modules ALL-SYSTEM"* is good
> > > principle.
> > > > >
> > > >
> > > > Yep, new applications will be more fine tuned, the problem
here is
> only
> > > for
> > > > the migration
> > > >
> > > > As a workaround to this in Maven would be to develop *smart
> > > > > maven-compiler-plugin* which automatically generates
> > > *module-info.class*
> > > > > upon import sections in Java classes and Maven dependencies.
> > > > > Not easy I guess.
> > > > >
> > > >
> > > > I think this will be not feasible in general and very
dangerous and
> > > maybe I
> > > > hope maven will never do such things
> > > >
> > > > Cheers
> > > > Enrico
> > > >
> > > > >
> > > > >
> > > > > On Mon, Aug 14, 2017 at 10:57 AM, Enrico Olivelli <
> > eolive...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Il dom 13 ago 2017, 17:31 Tibor Digana <
> > tibor.dig...@googlemail.com>
> > > > ha
> > > > > > scritto:
> > > > > >
> > > > > > > I found an issue. JDK printed this on std/out:
> > > > > > > WARNING: Using incubator modules: jdk.incubator.httpclient
> > > > > > >
> > > > > > > It hapens after my test:
> > > > > > >
> > > > > > > import org.junit.Test;
> > > > > > >
> > > > > > > public class J9Test
> > > > > > > {
> > > > > > > @Test
> > > > > > > public void testMiscellaneousAPI() throws
> > java.sql.SQLException
> > > > > > > {
> > > > > > > System.out.println( "loaded class " +
> > > > > > > java.sql.SQLException.class.getName() );
> > > > > > > System.out.println( "loaded class " +
> > > > > > > javax.xml.ws.Holder.class.getName() );
> > > > > > > System.out.println( "loaded class " +
> > > > > > > javax.xml.bind.JAXBException.class.getName() );
> > > > > > > System.out.println( "loaded class " +
> > > > > > > org.omg.CORBA.BAD_INV_ORDER.class.getName() );
> > > > > > > System.out.println( "loaded class " +
> > > > > > > javax.xml.xpath.XPath.class.getName() );
> > > > > > > System.out.println(
"java.specification.version=" +
> > > > > > > System.getProperty( "java.specification.version" ) );
> > > > > > > }
> > > > > > >
> > > > > > > @Test
> > > > > > > public void test_corba_mod() throws
> > org.omg.CORBA.BAD_INV_ORDER
> > > > > > > {
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <
> > > > > > tibor.dig...@googlemail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > But why to add it? It's a hack. I do not use
module-info.java
> > and
> > > > so
> > > > > > > there
> > > > > > > > is no reason to break the backwards compatibility.
> > > > > > > >
> > > > > > > > This is no more about Maven. It is about entire Java
world.
> > > > > > > > If we in Maven do it then everybody has to.
> > > > > > > > And I am sure that the voices says that Kotlin is better
and
> > > Scala
> > > > is
> > > > > > > > better would make sense. Why to help these attempts to
> happen?
> > No
> > > > > > reason!
> > > > > > > >
> > > > > > > > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory <
> > > > > garydgreg...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Is there a Maven way to add ALL-SYSTEM to everything?
Using
> > > plugin
> > > > > > > >> specific
> > > > > > > >> tags like below is going to be painful.
> > > > > > > >>
> > > > > > > >> Gary
> > > > > > > >>
> > > > > > > >> On Aug 13, 2017 07:30, "Tibor Digana" <
> tibordig...@apache.org
> > >
> > > > > wrote:
> > > > > > > >>
> > > > > > > >> > Hi @Enrico,
> > > > > > > >> >
> > > > > > > >> > I am very unhappy with Java 9 status and very afraid.
> > > > > > >
> > > > > >
> > > > > > Tibor, thank you very much for your time and your effort.
> > > > > > I think that we should have chimed in long time before the
> approval
> > > of
> > > > > > those decisions on the jre. Now the game is over, we can
only
> > decide
> > > > how
> > > > > > maven users will deal with running classpath based
applications
> on
> > > > java9.
> > > > > > I see two approaches:
> > > > > > 1) add a lot of tricks in every base maven plugin and
make it
> very
> > > easy
> > > > > to
> > > > > > transition
> > > > > > 2) leave the complexity to developers who will add a lot of
> > profiles
> > > > and
> > > > > > hacks to detect java9
> > > > > >
> > > > > > My personal feeling is that I am very disappointed by the
fact
> the
> > > few
> > > > > > developers diffs not report this issues to the maven
community
> long
> > > > time
> > > > > > ago. I think that the java9 adoption has not been taken into
> > account
> > > by
> > > > > > most developers and this will be an huge pain for the java
> > community.
> > > > > > I hope that Maven will help the java world to go on and
to step
> > over
> > > > this
> > > > > > painful transition
> > > > > >
> > > > > > I will test your patch as soon as I can
> > > > > > Cheers
> > > > > > Enrico
> > > > > >
> > > > > > >> > I do not like the style how Oracle has changed Java to
Java
> 9
> > > and
> > > > > > > forced
> > > > > > > >> > all the world to use additional effort to adapt to
Oracle
> > > > > > activities.
> > > > > > > >> >
> > > > > > > >> > I am facing more unhappy Java development teams with
Java
> 9
> > in
> > > > the
> > > > > > > >> future.
> > > > > > > >> > For instance as I have tried to implement users
wish in
> > Maven
> > > > > > Surefire
> > > > > > > >> > project and invested my personal time and effort to
adapt
> to
> > > > > Oracle
> > > > > > > >> > requirements, this still does not convince me to say
that
> > > Java 9
> > > > > is
> > > > > > > >> ready
> > > > > > > >> > to go.
> > > > > > > >> >
> > > > > > > >> > This is my comment from Jira:
> > > > > > > >> >
> > > > > > > >> > "This is not nice on Java 9 that they broke backwards
> > > > > compatibility
> > > > > > > and
> > > > > > > >> > force the world to use the switch to use
--add-modules
> > > > ALL-SYSTEM
> > > > > > > >> instead
> > > > > > > >> > of providing all modules installed in JRE. For
instance,
> > small
> > > > JRE
> > > > > > > >> having
> > > > > > > >> > {{java.base}} has advantage on embedded systems
and the
> only
> > > > > should
> > > > > > be
> > > > > > > >> > propagated. Big scope JRE should propagate all
installed
> > > > modules.
> > > > > > > >> > But for me it does not make security sense and common
> sense
> > to
> > > > > force
> > > > > > > >> JRE to
> > > > > > > >> > provide modules. It should be opposite and the
> admin/Jenkins
> > > > > should
> > > > > > > >> > configure big scope JRE with selected modules
propagated
> to
> > > Java
> > > > > > > runtime
> > > > > > > >> > applications.
> > > > > > > >> > If this admin does not do that then all modules
should
be
> > > > > available
> > > > > > by
> > > > > > > >> > default which is backwards compatibility for me
and we
do
> > not
> > > > have
> > > > > > to
> > > > > > > to
> > > > > > > >> > implement these stupid tricks."
> > > > > > > >> >
> > > > > > > >> > As far as we remember Java Security, the policies
can be
> > > > > configured.
> > > > > > > >> > I can imaging same paradigm in Jigsaw/Java 9 and then
the
> > > admin
> > > > > who
> > > > > > > has
> > > > > > > >> > installed JDK or JRE would "switch off" some modules.
But
> > > > > opposite,
> > > > > > > that
> > > > > > > >> > means the script which starts Java app currently
enables
> > "all"
> > > > > > modules
> > > > > > > >> is
> > > > > > > >> > against security and against the principle of modular
> system
> > > > > because
> > > > > > > the
> > > > > > > >> > modules do not make sense then.
> > > > > > > >> >
> > > > > > > >> > What makes sense to me is to enable "all java/javax"
> modules
> > > > > except
> > > > > > > for
> > > > > > > >> the
> > > > > > > >> > "com.sun" proprietary ones by default.
> > > > > > > >> > So yes enable them by default and please release
specific
> > JRE
> > > > > > > >> installations
> > > > > > > >> > with specific bunch of Java modules for specific use
> cases.
> > > > > > > >> > This means those modules in that particular
release are
> all
> > > > > enabled
> > > > > > by
> > > > > > > >> > default if not configured otherwise by admin, e.g.
> Jenkins,
> > > > > > operation
> > > > > > > >> > staff, etc. (do NOT mean Sun packages - never
visible).
> > > > > > > >> >
> > > > > > > >> > Here it comes. The idea that we can install small
5MB/JRE
> on
> > > > small
> > > > > > > Linux
> > > > > > > >> > device would be possible because Oracle would release
such
> > > tiny
> > > > > JRE
> > > > > > > >> using
> > > > > > > >> > only "java.lang" and then another JRE installation
using
> > > > java.lang
> > > > > > and
> > > > > > > >> > java.utils, and later NIO and later
"java.desktop", etc.
> > > > > > > >> >
> > > > > > > >> > Then vendors of web browsers and Linux dist would be
happy
> > to
> > > > > > > integrate
> > > > > > > >> > small JRE into and use JavaFX.
> > > > > > > >> >
> > > > > > > >> > But now it is not possible because the modules are
> basically
> > > > > three:
> > > > > > > >> >
> > > > > > > >> > java.base == 37MB
> > > > > > > >> > java.desktop == 36MB
> > > > > > > >> > java.xml ==20MB
> > > > > > > >> >
> > > > > > > >> > All the other modules are pretty small but these
three
> seen
> > in
> > > > > > > "src.zip"
> > > > > > > >> > make the modular system unbalanced in size and nobody
> would
> > > ever
> > > > > > wish
> > > > > > > to
> > > > > > > >> > integrate them because they are still big. That means
the
> > > > problem
> > > > > > that
> > > > > > > >> > Oracle has with NIO implementation in com.sun package
> > > propagated
> > > > > to
> > > > > > > >> > "java.util", nobody in the world care and nobody
should
> see
> > > as a
> > > > > > > >> problem to
> > > > > > > >> > split "java.base" much more.
> > > > > > > >> >
> > > > > > > >> > If splitting "java.base" happened then not certified
JVMs
> > > > > developed
> > > > > > at
> > > > > > > >> > Universities would for instance implement only
"java.lang"
> > and
> > > > > embed
> > > > > > > it
> > > > > > > >> in
> > > > > > > >> > to JVM and develop a new programming language on
the top
> of
> > > > Java.
> > > > > > But
> > > > > > > >> > implementing 10 packages in java.base is an effort
again.
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > One more thing is regarding the size of the modules.
> > > > > > > >> > You really did not help embedded systems and
installations
> > of
> > > > > > > browsers.
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > On Thu, May 18, 2017 at 8:51 AM, Enrico Olivelli <
> > > > > > eolive...@gmail.com
> > > > > > > >
> > > > > > > >> > wrote:
> > > > > > > >> >
> > > > > > > >> > > I would like to share my current pom configuration
which
> > > lets
> > > > me
> > > > > > to
> > > > > > > >> > > build and test java8 apps on latest and greatest
jdk9
> > > > > > > >> > >
> > > > > > > >> > > This profile is activated when using jdk9.
> > > > > > > >> > >
> > > > > > > >> > > This is based on a suggestion of Robert, its
suggestion
> > for
> > > > the
> > > > > > > >> > > javadoc plugin is working great with surefire too
> > > > > > > >> > >
> > > > > > > >> > > <profile>
> > > > > > > >> > > <id>jdk9</id>
> > > > > > > >> > > <activation>
> > > > > > > >> > > <jdk>[9,)</jdk>
> > > > > > > >> > > </activation>
> > > > > > > >> > > <build>
> > > > > > > >> > > <plugins>
> > > > > > > >> > > <plugin>
> > > > > > > >> > > <groupId>org.apache.maven.
> > > > > > plugins</groupId>
> > > > > > > >> > >
> > > > > > > <artifactId>maven-javadoc-plugin</artifactId>
> > > > > > > >> > > <configuration>
> > > > > > > >> > >
> <additionalparam>--add-modules
> > > > > > > >> > > ALL-SYSTEM</additionalparam>
> > > > > > > >> > > </configuration>
> > > > > > > >> > > </plugin>
> > > > > > > >> > > <plugin>
> > > > > > > >> > > <groupId>org.apache.maven.
> > > > > > plugins</groupId>
> > > > > > > >> > >
<artifactId>maven-surefire-pl
> > > > > > > >> ugin</artifactId>
> > > > > > > >> > > <version>2.20</version>
> > > > > > > >> > > <configuration>
> > > > > > > >> > > <argLine>--add-modules
> > > > > > > >> ALL-SYSTEM</argLine>
> > > > > > > >> > > </configuration>
> > > > > > > >> > > </plugin>
> > > > > > > >> > > </plugins>
> > > > > > > >> > > </build>
> > > > > > > >> > > </profile>
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > -- Enrico
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <
> > > > > khmarba...@gmx.de
> > > > > > >:
> > > > > > > >> > > > Hi,
> > > > > > > >> > > >
> > > > > > > >> > > > yes I will do within this week...
> > > > > > > >> > > >
> > > > > > > >> > > > Kind regards
> > > > > > > >> > > > Karl Heinz Marbaise
> > > > > > > >> > > > On 23/04/17 21:37, Enrico Olivelli wrote:
> > > > > > > >> > > >>
> > > > > > > >> > > >> Thank you Robert,
> > > > > > > >> > > >> I saw that you have merged my patch.
> > > > > > > >> > > >>
> > > > > > > >> > > >> Is there any plan to release the new version
of the
> war
> > > > > plugin?
> > > > > > > >> > > >>
> > > > > > > >> > > >> Enrico
> > > > > > > >> > > >>
> > > > > > > >> > > >>
> > > > > > > >> > > >> Il gio 13 apr 2017, 12:21 Paul Hammant <
> > p...@hammant.org
> > > >
> > > > ha
> > > > > > > >> scritto:
> > > > > > > >> > > >>
> > > > > > > >> > > >>>>
> > > > > > > >> > > >>>>
> > > > > > > >> > > >>>>> I don't see any activity either, so my
idea is
to
> > > > replace
> > > > > > > >> XStream,
> > > > > > > >> > > see
> > > > > > > >> > > >>>>
> > > > > > > >> > > >>>> MWAR-397[1]
> > > > > > > >> > > >>>>
> > > > > > > >> > > >>>
> > > > > > > >> > > >>> Just for the record, Jörg is working through
the
> Java9
> > > > > issues
> > > > > > > for
> > > > > > > >> > > XStream
> > > > > > > >> > > >>> presently - https://github.com/x-stream/
> > > > > > xstream/commits/master
> > > > > > > >> > > >>>
> > > > > > > >> > > >>> - Paul
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > ------------------------------
> > > > ------------------------------
> > > > > > > >> ---------
> > > > > > > >> > > > To unsubscribe, e-mail:
dev-unsubscribe@maven.apache.
> > org
> > > > > > > >> > > > For additional commands, e-mail:
> > > dev-h...@maven.apache.org
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > >
------------------------------------------------------------
> > > > ---------
> > > > > > > >> > > To unsubscribe, e-mail:
> dev-unsubscr...@maven.apache.org
> > > > > > > >> > > For additional commands, e-mail:
> > dev-h...@maven.apache.org
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Cheers
> > > > > > > > Tibor
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers
> > > > > > > Tibor
> > > > > > >
> > > > > > --
> > > > > >
> > > > > >
> > > > > > -- Enrico Olivelli
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > > Tibor
> > > > >
> > > > --
> > > >
> > > >
> > > > -- Enrico Olivelli
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > > Tibor
> > >
> > --
> >
> >
> > -- Enrico Olivelli
> >
>
--
