From ooo_saturn7 at mail.ru  Thu Jun  4 12:34:08 2020
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBPcmxvdg==?=)
Date: Thu, 04 Jun 2020 15:34:08 +0300
Subject: =?UTF-8?B?SXMgaXQgcG9zc2libGUgdG8gYWRkIGNsYXNzZXMgdG8gSlBNUyBtb2R1bGUg?=
 =?UTF-8?B?ZHluYW1pY2FsbHk/?=
Message-ID: <1591274048.582366623@f179.i.mail.ru>


Hi all,
?
Let's suppose we have a JPMS module  moduleA with the following  module-info :
module moduleA {
    exports modulea.generated;
}
Now, using javassist/byte-buddy we generate new  modulea.generated.Foo class. Could anyone say if we can add this class to  moduleA dynamically (at runtime) so as JPMS work with it as it works with module existing classes?
?
?
--
Alex Orlov

From forax at univ-mlv.fr  Thu Jun  4 12:46:56 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 4 Jun 2020 14:46:56 +0200 (CEST)
Subject: Is it possible to add classes to JPMS module dynamically?
In-Reply-To: <1591274048.582366623@f179.i.mail.ru>
References: <1591274048.582366623@f179.i.mail.ru>
Message-ID: <613884660.353426.1591274816933.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Alex Sviridov" <ooo_saturn7 at mail.ru>
> ?: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoy?: Jeudi 4 Juin 2020 14:34:08
> Objet: Is it possible to add classes to JPMS module dynamically?

> Hi all,

Hi Alex,

>?
> Let's suppose we have a JPMS module  moduleA with the following  module-info :
> module moduleA {
>    exports modulea.generated;
> }
> Now, using javassist/byte-buddy we generate new  modulea.generated.Foo class.
> Could anyone say if we can add this class to  moduleA dynamically (at runtime)
> so as JPMS work with it as it works with module existing classes ?

It will be added automatically, a module only contains packages (exported or not) so any classes in those packages (generated at runtime or not) are part of the module automatically.

>?
>?
> --
> Alex Orlov

cheers,
R?mi

From Alan.Bateman at oracle.com  Thu Jun  4 13:01:01 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 4 Jun 2020 14:01:01 +0100
Subject: Is it possible to add classes to JPMS module dynamically?
In-Reply-To: <1591274048.582366623@f179.i.mail.ru>
References: <1591274048.582366623@f179.i.mail.ru>
Message-ID: <07b5bb7e-391f-3623-7433-b52186eabaf0@oracle.com>

On 04/06/2020 13:34, Alex Orlov wrote:
> Hi all,
>   
> Let's suppose we have a JPMS module  moduleA with the following  module-info :
> module moduleA {
>      exports modulea.generated;
> }
> Now, using javassist/byte-buddy we generate new  modulea.generated.Foo class. Could anyone say if we can add this class to  moduleA dynamically (at runtime) so as JPMS work with it as it works with module existing classes?
Yes, if you use Lookup.defineClass or some other means to define a class 
into one of moduleA's run-time packages then it be in moduleA.

-Alan.

From gunnar at hibernate.org  Fri Jun  5 20:33:15 2020
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 5 Jun 2020 22:33:15 +0200
Subject: ModuleMainClass attribute via module-info.java
In-Reply-To: <87r1v02epn.fsf@mid.deneb.enyo.de>
References: <87r1v02epn.fsf@mid.deneb.enyo.de>
Message-ID: <CADGJaX-wrp_3rOa=_t0XC_+RynsTaqaCQdUG+6A8cGk+F-PiPQ@mail.gmail.com>

Hey Florian,

not javac, but ModiTect allows you to specify the main class when
defining module descriptors:

    https://github.com/moditect/moditect#adding-a-module-descriptor-to-the-project-jar

--Gunnar

Am So., 31. Mai 2020 um 19:32 Uhr schrieb Florian Weimer <fw at deneb.enyo.de>:
>
> Is it possible to instruct javac to generate a ModuleMainClass
> attribute via a module declaration?  I can't find the appropriate
> syntax in the JLS.  If there is no way to get javac to generate the
> attribute, what is the reason for that?

From jendrik at gradle.com  Mon Jun  8 09:02:01 2020
From: jendrik at gradle.com (Jendrik Johannes)
Date: Mon, 8 Jun 2020 11:02:01 +0200
Subject: ModuleMainClass attribute via module-info.java
In-Reply-To: <CADGJaX-wrp_3rOa=_t0XC_+RynsTaqaCQdUG+6A8cGk+F-PiPQ@mail.gmail.com>
References: <87r1v02epn.fsf@mid.deneb.enyo.de>
 <CADGJaX-wrp_3rOa=_t0XC_+RynsTaqaCQdUG+6A8cGk+F-PiPQ@mail.gmail.com>
Message-ID: <CAM0sT--Z299v4sE27M1ZyD=8X08mH8sHHSY4QyRiAz8ho1e10g@mail.gmail.com>

Hi,

Just wanted to mention for anyone ending up here as it is related:
In Gradle's Java Module support (since Gradle 6.5) we faced the same issue
as it fits the input/output model of Gradle tasks better if the
*compileJava* task does all the class file creation/modification. So in
Gradle it is possible to set the ModuleMainClass attribute on the
compileJava task. It is implemented by rewriting the module-info.class with
ASM right after it was created by the Java compiler.

https://docs.gradle.org/current/userguide/application_plugin.html#sec:application_modular

Cheers
Jendrik

On Fri, Jun 5, 2020 at 10:33 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hey Florian,
>
> not javac, but ModiTect allows you to specify the main class when
> defining module descriptors:
>
>
> https://github.com/moditect/moditect#adding-a-module-descriptor-to-the-project-jar
>
> --Gunnar
>
> Am So., 31. Mai 2020 um 19:32 Uhr schrieb Florian Weimer <fw at deneb.enyo.de
> >:
> >
> > Is it possible to instruct javac to generate a ModuleMainClass
> > attribute via a module declaration?  I can't find the appropriate
> > syntax in the JLS.  If there is no way to get javac to generate the
> > attribute, what is the reason for that?
>


-- 

[image: Email-Signature at 2x.png]

Jendrik Johannes

Senior Software Engineer

Gradle

W. gradle.com

From simeon.danailov.andreev at gmail.com  Mon Jun  8 13:40:52 2020
From: simeon.danailov.andreev at gmail.com (S A)
Date: Mon, 8 Jun 2020 16:40:52 +0300
Subject: Illegal reflection access denial in which future release
Message-ID: <CACcnpz1Wp_MoDnU55_gTib3FvQOf=4r-5S7L1c2oY8FcDAgZHQ@mail.gmail.com>

Hi all,

TL;DR is a future JDK release known, when illegal reflection access is no
longer possible? If not, are there estimations / discussions / FAQs /
documentation?

The product I work on (Eclipse+xtext IDE + backend) has nearly completed
the move to OpenJDK 11 (from OpenJDK 8) and we are working on supposedly
not pressing issues. One of those issues is illegal access via reflection.

We would obviously like to be prepared and so are estimating effort and
time constraints of fixing illegal reflection access. As this includes
multiple libraries, knowing *when* we need to finish our efforts is quite
important.

Sorry if this has been asked before (I imagine yes), but searching for the
topic yields lots of how to work around or fix the issue. Thank you in
advance.

Best regards,
Simeon

From claes.redestad at oracle.com  Mon Jun  8 14:09:28 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 8 Jun 2020 16:09:28 +0200
Subject: Illegal reflection access denial in which future release
In-Reply-To: <CACcnpz1Wp_MoDnU55_gTib3FvQOf=4r-5S7L1c2oY8FcDAgZHQ@mail.gmail.com>
References: <CACcnpz1Wp_MoDnU55_gTib3FvQOf=4r-5S7L1c2oY8FcDAgZHQ@mail.gmail.com>
Message-ID: <ca419d62-a7fd-e534-bb05-cc79394ec4c6@oracle.com>

Hi Simeon,

it's not documented or discussed much anywhere because it's as-of-yet
undecided.

*Expectation* is that there'll be a JEP proposed to make
--illegal-access=deny the *default* in JDK 16. I expect the ability to
explicitly permit illegal accesses with --illegal-access=permit will
stick around for a good while longer, though.

Best regards
/Claes

On 2020-06-08 15:40, S A wrote:
> Hi all,
> 
> TL;DR is a future JDK release known, when illegal reflection access is no
> longer possible? If not, are there estimations / discussions / FAQs /
> documentation?
> 
> The product I work on (Eclipse+xtext IDE + backend) has nearly completed
> the move to OpenJDK 11 (from OpenJDK 8) and we are working on supposedly
> not pressing issues. One of those issues is illegal access via reflection.
> 
> We would obviously like to be prepared and so are estimating effort and
> time constraints of fixing illegal reflection access. As this includes
> multiple libraries, knowing *when* we need to finish our efforts is quite
> important.
> 
> Sorry if this has been asked before (I imagine yes), but searching for the
> topic yields lots of how to work around or fix the issue. Thank you in
> advance.
> 
> Best regards,
> Simeon
> 

From forax at univ-mlv.fr  Mon Jun  8 14:30:59 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 8 Jun 2020 16:30:59 +0200 (CEST)
Subject: Illegal reflection access denial in which future release
In-Reply-To: <ca419d62-a7fd-e534-bb05-cc79394ec4c6@oracle.com>
References: <CACcnpz1Wp_MoDnU55_gTib3FvQOf=4r-5S7L1c2oY8FcDAgZHQ@mail.gmail.com>
 <ca419d62-a7fd-e534-bb05-cc79394ec4c6@oracle.com>
Message-ID: <1318771338.560483.1591626659710.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Claes Redestad" <claes.redestad at oracle.com>
> ?: "S A" <simeon.danailov.andreev at gmail.com>, "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Cc: "Andrey Loskutov" <loskutov at gmx.de>
> Envoy?: Lundi 8 Juin 2020 16:09:28
> Objet: Re: Illegal reflection access denial in which future release

> Hi Simeon,
> 
> it's not documented or discussed much anywhere because it's as-of-yet
> undecided.
> 
> *Expectation* is that there'll be a JEP proposed to make
> --illegal-access=deny the *default* in JDK 16. I expect the ability to
> explicitly permit illegal accesses with --illegal-access=permit will
> stick around for a good while longer, though.

As a member of the expert group on JPMS, i think we should move to deny by default for 16.
A lot of people are now migrating their applications to 11, i think it's cheaper to do the migration to a world with --illegal-access=deny than to do first a migration to 11 and then a migration to 17.

> 
> Best regards
> /Claes

regards,
R?mi

> 
> On 2020-06-08 15:40, S A wrote:
>> Hi all,
>> 
>> TL;DR is a future JDK release known, when illegal reflection access is no
>> longer possible? If not, are there estimations / discussions / FAQs /
>> documentation?
>> 
>> The product I work on (Eclipse+xtext IDE + backend) has nearly completed
>> the move to OpenJDK 11 (from OpenJDK 8) and we are working on supposedly
>> not pressing issues. One of those issues is illegal access via reflection.
>> 
>> We would obviously like to be prepared and so are estimating effort and
>> time constraints of fixing illegal reflection access. As this includes
>> multiple libraries, knowing *when* we need to finish our efforts is quite
>> important.
>> 
>> Sorry if this has been asked before (I imagine yes), but searching for the
>> topic yields lots of how to work around or fix the issue. Thank you in
>> advance.
>> 
>> Best regards,
>> Simeon

From Alan.Bateman at oracle.com  Wed Jun 10 19:51:38 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 10 Jun 2020 20:51:38 +0100
Subject: 8241770: Module xxxAnnotation() methods throw NCDFE if
 module-info.class found as resource in unnamed module
Message-ID: <eabc6f2f-2757-a50b-bfc1-33d91e1d82ec@oracle.com>


This is a bug in Module.getXXXAnnotation implementation where it 
accidentally locates a module-info.class on the class path (say if 
someone deploys a modular JAR on the class path). An oversight in the 
original implementation. Simple fix to override loadClass to do the 
right thing. I've kept the changes as minimal as possible as this is a 
change that may need to be back-ported. The webrev with the change and 
updated test is here:

http://cr.openjdk.java.net/~alanb/8241770/webrev/

Thanks,
Alan


From mandy.chung at oracle.com  Wed Jun 10 21:22:13 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 10 Jun 2020 14:22:13 -0700
Subject: 8241770: Module xxxAnnotation() methods throw NCDFE if
 module-info.class found as resource in unnamed module
In-Reply-To: <eabc6f2f-2757-a50b-bfc1-33d91e1d82ec@oracle.com>
References: <eabc6f2f-2757-a50b-bfc1-33d91e1d82ec@oracle.com>
Message-ID: <7a74e500-5aa9-c1ec-ed65-4162ecd18d77@oracle.com>



On 6/10/20 12:51 PM, Alan Bateman wrote:
>
> This is a bug in Module.getXXXAnnotation implementation where it 
> accidentally locates a module-info.class on the class path (say if 
> someone deploys a modular JAR on the class path). An oversight in the 
> original implementation. Simple fix to override loadClass to do the 
> right thing. I've kept the changes as minimal as possible as this is a 
> change that may need to be back-ported. The webrev with the change and 
> updated test is here:
>
> http://cr.openjdk.java.net/~alanb/8241770/webrev/
>

Looks good.

Nit: A typo in the test s/reflectingly/reflectively/

102 * Test reflectingly reading annotations on a named module where the 
module Mandy


From Alan.Bateman at oracle.com  Thu Jun 11 06:31:12 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Jun 2020 07:31:12 +0100
Subject: 8241770: Module xxxAnnotation() methods throw NCDFE if
 module-info.class found as resource in unnamed module
In-Reply-To: <7a74e500-5aa9-c1ec-ed65-4162ecd18d77@oracle.com>
References: <eabc6f2f-2757-a50b-bfc1-33d91e1d82ec@oracle.com>
 <7a74e500-5aa9-c1ec-ed65-4162ecd18d77@oracle.com>
Message-ID: <f7230632-5261-948d-cb91-6b00faa3637d@oracle.com>



On 10/06/2020 22:22, Mandy Chung wrote:
>
> Nit: A typo in the test s/reflectingly/reflectively/
>
> 102 * Test reflectingly reading annotations on a named module where 
> the module
That typo was in two places and I only spotted one of them when creating 
the webrev. I'll fix the second one before pushing. Thanks!

-Alan

From ooo_saturn7 at mail.ru  Sun Jun 21 18:52:04 2020
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBPcmxvdg==?=)
Date: Sun, 21 Jun 2020 21:52:04 +0300
Subject: =?UTF-8?B?Rm9yY2UgSlBNUyB0byBhZGQgbW9kdWxlIHRvIGJvb3QgbGF5ZXI=?=
Message-ID: <1592765524.358193569@f451.i.mail.ru>


Hi all,
?
New version of maven-failsafe-plugin (3.0.0-M5) has been released and now it is possible to have two module-info in one
project ? one in src/main/java and one in src/test/java? and to test modules on module -path.
Trying to use it I found the following.
?
Failsafe detects right module list using poms and adds it. The problem is that there are jars with module-info, with
Automatic-Module-Name and jars without anything. And if any module doesn?t show explicit dependency,
module is not added to boot layer by JPMS. For example, I have many hours story with hibernate and fasterxml.
In module path I saw:
/home/alex/.m2/repository/org/hibernate/hibernate-core/5.4.14.Final/hibernate-core-5.4.14.Final.jar
/home/alex/.m2/repository/com/fasterxml/classmate/1.5.1/classmate-1.5.1.jar
However, I got java.lang.NoClassDefFoundError: com/fasterxml/classmate/TypeResolver
Only later, I noticed that on boot layer I had only hibernate (without module-info) but
fasterxml (with module-info) was ignored by our lovely JPMS.
?
So, it is necessary to add missed modules via test module-info to boot layer what is a very silly work:
1) you add to you pom dependencies that you don?t use
2) failsafe detects right dependencies using pom files and does it very well.
?
So, could anyone answer two my questions:
1) Is it possible to force JPMS to add modules even if it think that they won?t be used
(by the way ? nobody asks it).
2) As I understand this problem doesn?t appear when we create child layer and add any jars to it.
In this case JPMS doesn?t ignore any modules. Is this statement right?
?
?
--
Alex Orlov

From Alan.Bateman at oracle.com  Mon Jun 22 15:35:10 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Jun 2020 16:35:10 +0100
Subject: Force JPMS to add module to boot layer
In-Reply-To: <1592765524.358193569@f451.i.mail.ru>
References: <1592765524.358193569@f451.i.mail.ru>
Message-ID: <082f719d-808e-8337-6052-1294848f69b6@oracle.com>

On 21/06/2020 19:52, Alex Orlov wrote:
> Hi all,
>   
> New version of maven-failsafe-plugin (3.0.0-M5) has been released and now it is possible to have two module-info in one
> project ? one in src/main/java and one in src/test/java? and to test modules on module -path.
> Trying to use it I found the following.
>   
> Failsafe detects right module list using poms and adds it. The problem is that there are jars with module-info, with
> Automatic-Module-Name and jars without anything. And if any module doesn?t show explicit dependency,
> module is not added to boot layer by JPMS. For example, I have many hours story with hibernate and fasterxml.
> In module path I saw:
> /home/alex/.m2/repository/org/hibernate/hibernate-core/5.4.14.Final/hibernate-core-5.4.14.Final.jar
> /home/alex/.m2/repository/com/fasterxml/classmate/1.5.1/classmate-1.5.1.jar
> However, I got java.lang.NoClassDefFoundError: com/fasterxml/classmate/TypeResolver
> Only later, I noticed that on boot layer I had only hibernate (without module-info) but
> fasterxml (with module-info) was ignored by our lovely JPMS.
If hibernate is an automatic module, and if is indeed resolved, then 
every observable automatic module will also be resolved. Is there any 
way to get maven-failsafe-plugin to reveal the command line that it is 
using? Alternatively, is there any way to inject the 
"--show-module-resolution" option into the command line that it uses? 
That will help to discovered if hibernate is actually resolved.
>   
> So, it is necessary to add missed modules via test module-info to boot layer what is a very silly work:
> 1) you add to you pom dependencies that you don?t use
> 2) failsafe detects right dependencies using pom files and does it very well.
>   
> So, could anyone answer two my questions:
> 1) Is it possible to force JPMS to add modules even if it think that they won?t be used
> (by the way ? nobody asks it).
> 2) As I understand this problem doesn?t appear when we create child layer and add any jars to it.
> In this case JPMS doesn?t ignore any modules. Is this statement right?
>   
If you are add "--add-modules" to the command line then it will allow 
you to make sure that jackson is in the boot layer. That said, it may 
mask some other issue so finding a bit more on what 
maven-failsafe-plugin is doing will help the discussion here.

-Alan

From ooo_saturn7 at mail.ru  Mon Jun 22 17:15:37 2020
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBPcmxvdg==?=)
Date: Mon, 22 Jun 2020 20:15:37 +0300
Subject: =?UTF-8?B?UmVbMl06IEZvcmNlIEpQTVMgdG8gYWRkIG1vZHVsZSB0byBib290IGxheWVy?=
In-Reply-To: <082f719d-808e-8337-6052-1294848f69b6@oracle.com>
References: <1592765524.358193569@f451.i.mail.ru>
 <082f719d-808e-8337-6052-1294848f69b6@oracle.com>
Message-ID: <1592846137.508952101@f118.i.mail.ru>


Hi Alan,
?
Thank you very much for your answer. In order to be concrete a test project was created
and it is here  https://github.com/PashaTurok/hibernate-h2-test4
?
Besides, if it is not very difficult for you, could you answer separately to
each questions (# 1 and #2). So, I repeat them again:
?
1) Is it possible to force JPMS to add modules even if it think that they won?t be used
(by the way ? nobody asks it).
2) As I understand this problem doesn?t appear when we create child layer and add any jars to it.
In this case JPMS doesn?t ignore any modules. Is this statement right?
?
Best regards,
?
?
?

? 
>???????????, 22 ???? 2020, 18:35 +03:00 ?? Alan Bateman <alan.bateman at oracle.com>:
>?
>On 21/06/2020 19:52, Alex Orlov wrote:
>> Hi all,
>>
>> New version of maven-failsafe-plugin (3.0.0-M5) has been released and now it is possible to have two module-info in one
>> project ? one in src/main/java and one in src/test/java? and to test modules on module -path.
>> Trying to use it I found the following.
>>
>> Failsafe detects right module list using poms and adds it. The problem is that there are jars with module-info, with
>> Automatic-Module-Name and jars without anything. And if any module doesn?t show explicit dependency,
>> module is not added to boot layer by JPMS. For example, I have many hours story with hibernate and fasterxml.
>> In module path I saw:
>> /home/alex/.m2/repository/org/hibernate/hibernate-core/5.4.14.Final/hibernate-core-5.4.14.Final.jar
>> /home/alex/.m2/repository/com/fasterxml/classmate/1.5.1/classmate-1.5.1.jar
>> However, I got java.lang.NoClassDefFoundError: com/fasterxml/classmate/TypeResolver
>> Only later, I noticed that on boot layer I had only hibernate (without module-info) but
>> fasterxml (with module-info) was ignored by our lovely JPMS.
>If hibernate is an automatic module, and if is indeed resolved, then
>every observable automatic module will also be resolved. Is there any
>way to get maven-failsafe-plugin to reveal the command line that it is
>using? Alternatively, is there any way to inject the
>"--show-module-resolution" option into the command line that it uses?
>That will help to discovered if hibernate is actually resolved.
>>
>> So, it is necessary to add missed modules via test module-info to boot layer what is a very silly work:
>> 1) you add to you pom dependencies that you don?t use
>> 2) failsafe detects right dependencies using pom files and does it very well.
>>
>> So, could anyone answer two my questions:
>> 1) Is it possible to force JPMS to add modules even if it think that they won?t be used
>> (by the way ? nobody asks it).
>> 2) As I understand this problem doesn?t appear when we create child layer and add any jars to it.
>> In this case JPMS doesn?t ignore any modules. Is this statement right?
>>
>If you are add "--add-modules" to the command line then it will allow
>you to make sure that jackson is in the boot layer. That said, it may
>mask some other issue so finding a bit more on what
>maven-failsafe-plugin is doing will help the discussion here.
>
>-Alan 
?
?
--
Alex Orlov
?

From Alan.Bateman at oracle.com  Tue Jun 23 16:01:49 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 23 Jun 2020 17:01:49 +0100
Subject: Force JPMS to add module to boot layer
In-Reply-To: <1592846137.508952101@f118.i.mail.ru>
References: <1592765524.358193569@f451.i.mail.ru>
 <082f719d-808e-8337-6052-1294848f69b6@oracle.com>
 <1592846137.508952101@f118.i.mail.ru>
Message-ID: <0297897a-37b9-4bd5-08fb-4f10cd8ccbd3@oracle.com>

On 22/06/2020 18:15, Alex Orlov wrote:
> Hi Alan,
> Thank you very much for your answer. In order to be concrete a test 
> project was created
> and it is here https://github.com/PashaTurok/hibernate-h2-test4
> Besides, if it is not very difficult for you, could you answer 
> separately to
> each questions (# 1 and #2). So, I repeat them again:
> 1) Is it possible to force JPMS to add modules even if it think that 
> they won?t be used
> (by the way ? nobody asks it).
> 2) As I understand this problem doesn?t appear when we create child 
> layer and add any jars to it.
> In this case JPMS doesn?t ignore any modules. Is this statement right?
>
java.lang.NoClassDefFoundError: 
net/bytebuddy/NamingStrategy$SuffixingRandom$BaseNameResolver
 ??? at 
org.hibernate.cfg.Environment.buildBytecodeProvider(Environment.java:345) 
~[hibernate-core-5.4.15.Final.jar:?]
 ??? at 
org.hibernate.cfg.Environment.buildBytecodeProvider(Environment.java:337) 
~[hibernate-core-5.4.15.Final.jar:?]
 ??? at org.hibernate.cfg.Environment.<clinit>(Environment.java:230) 
~[hibernate-core-5.4.15.Final.jar:?]

 From what I can establish, org.hibernate.orm.core is an automatic 
module so it doesn't have any way to `requires net.bytebuddy` (an 
explicit module). You'll have to help out by adding `--add-modules 
net.bytebuddy` to the command line that surefire or failsafe uses.

I can't explain why you don't see issues when you use module layers. It 
is possible that you've specified "net.bytebuddy" in the list of root 
modules that you specify to the resolve method?

-Alan

From ooo_saturn7 at mail.ru  Tue Jun 23 16:31:59 2020
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBPcmxvdg==?=)
Date: Tue, 23 Jun 2020 19:31:59 +0300
Subject: =?UTF-8?B?UmVbMl06IEZvcmNlIEpQTVMgdG8gYWRkIG1vZHVsZSB0byBib290IGxheWVy?=
In-Reply-To: <0297897a-37b9-4bd5-08fb-4f10cd8ccbd3@oracle.com>
References: <1592765524.358193569@f451.i.mail.ru>
 <1592846137.508952101@f118.i.mail.ru>
 <0297897a-37b9-4bd5-08fb-4f10cd8ccbd3@oracle.com>
Message-ID: <1592929919.379606064@f456.i.mail.ru>


?
>net/bytebuddy/NamingStrategy$SuffixingRandom$BaseNameResolver
>???? at
>org.hibernate.cfg.Environment.buildBytecodeProvider(Environment.java:345)
>~[hibernate-core-5.4.15.Final.jar:?]
>???? at
>org.hibernate.cfg.Environment.buildBytecodeProvider(Environment.java:337)
>~[hibernate-core-5.4.15.Final.jar:?]
>???? at org.hibernate.cfg.Environment.<clinit>(Environment.java:230)
>~[hibernate-core-5.4.15.Final.jar:?]
>
>?From what I can establish, org.hibernate.orm.core is an automatic
>module so it doesn't have any way to `requires net.bytebuddy` (an
>explicit module). You'll have to help out by adding `--add-modules
>net.bytebuddy` to the command line that surefire or failsafe uses.
?
Yes, and this is the work that I say is very silly. We add modules to module
path, but JPMS IGNORES THEM. It is obvious that it was a wrong solution
to let JPMS solve what modules it should add to layer and what modules shouldn?t.
?
AND I AM SURE EVERYONE WILL AGREE WITH ME.
?
Again ? if any?automatization is implemented there must be a possibility
to switch it off. Just imagine a plane with autopilot that can?t be disabled.
We have the same here. Someone implemented feature that we must
be able to turn off.
?
So, if I open a feature request to add flag to disable JPMS ignoring not
used modules, will you support it? By others words should I spend
my time on it?
?
Before answering, just imagine, how many developers in the world will
do this silly work when they add modules to module path, but JPMS will
ignore them.
?
Best regards,
?
?
>I can't explain why you don't see issues when you use module layers. It
>is possible that you've specified "net.bytebuddy" in the list of root
>modules that you specify to the resolve method?
>
>-Alan 
?
?
--
Alex Orlov
?

From alex.buckley at oracle.com  Tue Jun 23 17:52:58 2020
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 23 Jun 2020 10:52:58 -0700
Subject: Force JPMS to add module to boot layer
In-Reply-To: <1592929919.379606064@f456.i.mail.ru>
References: <1592765524.358193569@f451.i.mail.ru>
 <1592846137.508952101@f118.i.mail.ru>
 <0297897a-37b9-4bd5-08fb-4f10cd8ccbd3@oracle.com>
 <1592929919.379606064@f456.i.mail.ru>
Message-ID: <898f1a7b-984a-9a9b-8a12-a921c497c1a8@oracle.com>

On 6/23/2020 9:31 AM, Alex Orlov wrote:
>> From what I can establish, org.hibernate.orm.core is an automatic
>> module so it doesn't have any way to `requires net.bytebuddy` (an
>> explicit module). You'll have to help out by adding `--add-modules
>> net.bytebuddy` to the command line that surefire or failsafe uses.
>   
> Yes, and this is the work that I say is very silly. We add modules to module
> path, but JPMS IGNORES THEM. It is obvious that it was a wrong solution
> to let JPMS solve what modules it should add to layer and what modules shouldn?t.

The module path is not like the class path. The class path is chaos; the 
module path is order. Think of the module path as a repository that 
contains tens, hundreds, thousands of modules, all of which sit silently 
until one is required by some module, or resolved due to `--add-modules`.

You're asking the JDK team how to use the ORM core of Hibernate as an 
automatic module. What did the Hibernate team say what you asked them?

Alex

From sormuras at gmail.com  Tue Jun 23 17:56:18 2020
From: sormuras at gmail.com (Christian Stein)
Date: Tue, 23 Jun 2020 19:56:18 +0200
Subject: Fwd: Force JPMS to add module to boot layer
In-Reply-To: <CAJi8+g67dZMOqDWfo-xLiauj4M2vqrdfbLV+vUDO5hJ+Lg-zaA@mail.gmail.com>
References: <1592765524.358193569@f451.i.mail.ru>
 <CAJi8+g67dZMOqDWfo-xLiauj4M2vqrdfbLV+vUDO5hJ+Lg-zaA@mail.gmail.com>
Message-ID: <CAJi8+g7pZ2WH-BUxdACzxafFTVXHD_TNksa7MHoe-5FG1-jm9A@mail.gmail.com>

On Sun, Jun 21, 2020 at 8:55 PM Alex Orlov <ooo_saturn7 at mail.ru> wrote:

>
> Hi all,
>
> New version of maven-failsafe-plugin (3.0.0-M5) has been released and now
> it is possible to have two module-info in one
> project ? one in src/main/java and one in src/test/java  and to test
> modules on module -path.
> [...]


Support for the Java module system was included in Maven
Surefire/Failsafe (SF/FS) recently. As you noted, in version 3.0.0-M5.
There are for sure some short-comings, missing features,
and also plain bugs in the implementation of SF/FS. See this
recent discussion as an example: [1733] You're very welcome
to test-drive and propose fixes for SF/FS.

Java modules are declared by developers ? no build tool can 100%
correctly guess what should be included (exported, opened, ...)
in a Java module. This goes for modules at (Maven) tests alike.
And it surely goes for setting up the module-path and the class-path
at test runtime. I invite you to read [1] and look at this sample
Maven project that show-cases most combinations of "intra-module"
and "extra-modular" testing [2].

 AND I AM SURE EVERYONE WILL AGREE WITH ME.


No.

Cheers,
Christian

PS: Just a blind guess, did you already try to pass

 --add-modules=ALL-MODULE-PATH

to the SF/FS runtime?

1733:
https://issues.apache.org/jira/browse/SUREFIRE-1733?focusedCommentId=17142664&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17142664
1: https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world
<https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html>
2: https://github.com/micromata/sawdust