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.
>> > 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
