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
>
IMHO This is because we are importing all system modules. Maybe importing
only java.se.ee would cover most of the cases.
I did not notice the warning on test I have run today
Enrico
> 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.
> >> > 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-unsubscr...@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
