Re: Portable retrieval of resource bundles across module path and class path

Hi Gunnar, I skimmed your post briefly and will read it in detail later -- though I wonder whether my over 4 years old SO question is answered as a side-effect by your findings. https://stackoverflow.com/questions/44167502/how-to-configure-resourcebundle-no-fallback-control-in-java-9 Cheers,

Re: Difference of module jdk.xml.dom and module jdk.zipfs

/commit/940bf900c448177cc5cc5410ff604bad8197b59c On Thu, Mar 25, 2021 at 4:17 PM Alan Bateman wrote: > On 25/03/2021 14:59, Christian Stein wrote: > > Hi, > > > > Besides their names, contents and purposes. (-: > > > > So, what's the difference of module jdk

Difference of module jdk.xml.dom and module jdk.zipfs

Hi, Besides their names, contents and purposes. (-: So, what's the difference of module jdk.xml.dom and module jdk.zipfs in respect to their visibility(?) at compile and run-time? Suppose, there's a module test.base declared as: module test.base { requires jdk.xml.dom; requires

Re: Add information of which automatic module doesn't the

On Wed, Mar 3, 2021 at 10:10 AM Alan Bateman wrote: > [...] > Thanks, it should include the file path to the JAR file in the message > to make it easy to find the JAR file that can't be used as an automatic > module. I'll create an issue to track that. > Did you create an issue, Alan? If not,

Re: New candidate JEP: 403: Strongly Encapsulate JDK Internals

On Thu, Mar 25, 2021 at 12:26 PM Alan Bateman wrote: > [...] > > More generally, tests for modules, say white box tests that exercise > package private methods, can continue to be compiled and run "as if" > they are part of the module. The Maven/other plugins for testing will > use

Re: Re[2]: How to do “--add-modules” with dynamically created layer in JPMS?

Hi Alex, Perhaps a deeper look how Layrry works under the hood does help: https://github.com/moditect/layrry If I'm not mistaken, your use-case seems very similar to those Layrry tries to cope with. Cheers, Christian On Mon, Nov 16, 2020 at 10:17 AM Alex Orlov wrote: > > Hello Alan, > >

Re: javac --module option and stale classes

On Wed, Jul 29, 2020 at 6:41 PM Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote: > > On 7/29/20 5:49 AM, Christian Stein wrote: > > I wonder whether the logic at [1] is a) the sole place that > > controls this feature and b) whether it can be enhanced > > to

javac --module option and stale classes

Hi, when using the --module option of javac, the Java source files of a module are automatically added to the list of to be compiled files, checking timestamps. This works as expected as long as existing source files are changed and/or new source files are added. If a Java source file is deleted

Fwd: Force JPMS to add module to boot layer

On Sun, Jun 21, 2020 at 8:55 PM 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. > [...]

Re: jlink 14.0.1 with 100 modules fail

On Sun, May 31, 2020 at 8:52 AM Alan Bateman wrote: > > > On 30/05/2020 17:40, Christian Stein wrote: > > Hi, > > > > the modular [bach-demo-99] I generated to check my build tool > > against, failed to create a custom runtime image using jlink > > via it

Re: jlink 14.0.1 with 100 modules fail

Thanks for the quick response. On Sat, May 30, 2020 at 7:05 PM Remi Forax wrote: > > > Shall I open an issue at JBS? > > yes ! > > Done: https://bugs.openjdk.java.net/browse/JDK-8246197

jlink 14.0.1 with 100 modules fail

Hi, the modular [bach-demo-99] I generated to check my build tool against, failed to create a custom runtime image using jlink via itsToolProvider-based service entry-point. The project consists of 100 module descriptors. No other Java source files (for classes and interfaces) are part of that

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

On Tue, Feb 18, 2020 at 6:42 PM Alex Buckley wrote: > > Good description of how the main module > [...] > etc. Then, the build tool can enrich the main module by passing > --add-modules, --add-reads, and --add-opens to javac/java while in a > test scope. No need for --patch-module-descriptor in

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

I extended the example project with some potential use-cases for the `--patch-module-descriptor` option at [0]. Those use-cases show which command line option usages can be replaced and therefore simplified (as this RFE thread was coined) in the form of the following example: Today:

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

On Fri, Feb 14, 2020 at 10:31 PM Alex Buckley wrote: > On 2/14/2020 11:29 AM, Christian Stein wrote: > >> A different way to address those use cases would be to ship the > >> logic just described for `--patch-module-descriptor` in a launcher > >> offere

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

Hi Alex, On Fri, Feb 14, 2020 at 7:06 PM Alex Buckley wrote: > [...] Now, I am not "proposing" `--patch-module-descriptor` for a future JDK. > I am recognizing that certain use cases involve changing a module's > dependences and encapsulation in a tightly scoped way. I can clearly envision

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

that suggestion, though. I'll send this answer anyway -- to round-up and effectively close this sub-thread. On Mon, Feb 10, 2020 at 11:03 PM Alex Buckley wrote: > Hi Christian, > > On 2/7/2020 4:41 AM, Christian Stein wrote: > > This time, I created a project at [0] with a detailed des

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

On Thu, Feb 6, 2020 at 8:35 AM Christian Stein wrote: > I agree with you, that the user (the build tool in most of the cases) > should > stay in control which module descriptor is in effect for every module. > > As my domain is testing, and I guess the majority of uses-

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

I agree with you, that the user (the build tool in most of the cases) should stay in control which module descriptor is in effect for every module. As my domain is testing, and I guess the majority of uses-cases is within the realm of intra-module (white-box) testing, I'll expound on the topic

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

On Wed, Feb 5, 2020 at 4:47 AM Christian Stein wrote: > // Hope this email will be technically associated as a reply for the > // "RFE simplify usage of patched module" thread. > > I agree with Robert that a user-friendly and (build) tool-agnostic way > to express add

Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

// Hope this email will be technically associated as a reply for the // "RFE simplify usage of patched module" thread. I agree with Robert that a user-friendly and (build) tool-agnostic way to express additional module directives and modifiers for testing purposes only is ... a good thing to

RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

Hi, I took the freedom moving this thread to "jigsaw-dev", as suggested by David Holmes, in order to reply to it in a follow-up mail. I hope, Robert doesn't mind that I copy his text from "jdk-dev" below to start with the same context. Robert Scholte wrote in

javac/jdeps and requires with version

Hi, given an empty module declaration: module foo{} Compile it with javac using various valid "--release r" variants yields different module descriptors in addition to the generated class file version. For JDK N, javac seems to include the version of a required module only if you omit the

Re: Add "source of module name" to ModuleDescriptor API

On Tue, Jul 2, 2019 at 1:14 PM Alan Bateman wrote: > On 02/07/2019 09:47, Christian Stein wrote: > > Hi, > > > > at the moment, class `java.lang.module.ModuleDescriptor` only > > provides an `isAutomatic()` getter -- which doesn't allow to > > determine from wh

Add "source of module name" to ModuleDescriptor API

Hi, at the moment, class `java.lang.module.ModuleDescriptor` only provides an `isAutomatic()` getter -- which doesn't allow to determine from where the module name actually came from. Program `PresentModule.java` [1] creates a `JarFile` instance to determine the source of an automatic module.

Re: Why doesn’t jdk.internal.loader.Loader implement AutoCloseable?

On Sun, May 26, 2019 at 10:31 AM Alan Bateman wrote: > That said, it might be time to change the Windows sharing mode that > JarFile/ZipFile uses to open JAR files. I'll create an issue for that. > > -Alan > Is this the related issue? https://bugs.openjdk.java.net/browse/JDK-8224794

Re: Nashorn on the module-path

nk it’s possible to reduce the problem further, ideally to a > plain java class? > > > Hannes > > > > Am 27.05.2019 um 11:40 schrieb Christian Stein : > > > > On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan < > > sundararajan.athijegannat.

Re: Nashorn on the module-path

On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan < sundararajan.athijegannat...@oracle.com> wrote: > How can this be reproduced at out end? I compiled a small example project at [1] that describes and demonstrates the issue. Please view the README.md file for details. You may

Re: Nashorn on the module-path

2019 at 10:35 AM Alan Bateman wrote: > On 16/05/2019 15:02, Christian Stein wrote: > > : > > It didn't emit any new line. Is there another debug switch I can enable? > > Have you brought this up on nashorn-dev as this might require digging into > the dynalink linker and how method handles are used. > > -Alan >

Re: Why doesn’t jdk.internal.loader.Loader implement AutoCloseable?

On Sun, May 26, 2019 at 10:31 AM Alan Bateman wrote: > On 26/05/2019 06:45, Christian Stein wrote: > > Hi, > > > > following the documentation of ModulLayer [1] to create a > > temporary layer for testing, results in a FileSystemException > > when trying to

Why doesn’t jdk.internal.loader.Loader implement AutoCloseable?

Hi, following the documentation of ModulLayer [1] to create a temporary layer for testing, results in a FileSystemException when trying to delete the modular jar file after tests are finished. On Windows, at least. Find more details and a minimal working example here: [2] An implementation of a

Re: Nashorn on the module-path

On Thu, May 16, 2019 at 3:23 PM Alan Bateman wrote: > Can you run with -Dsun.reflect.debugModuleAccessChecks and see if > anything is printed? This can be useful to locate exception swallowing. > Given that Nashorn is using method handles it might not help but would > be useful to try. > It

Re: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH

On Thu, Apr 11, 2019 at 8:30 PM Alex Buckley wrote: > [...] In advance > of that, can you share some detailed invocations of javac using > --patch-module in single-module and multi-module mode? > I'm not sure if this helps in any regards -- here [1] is a draft PR that adds explicit module

jar --describe-module shows lower-case service impl name

Hi, just saw running on JDK 11-ea+13 that: jar --describe-module --file [1] shows: provides org.junit.platform.engine.TestEngine with ice.cream.machine [2] The FQCN service implementation name is: ice.cream.Machine Is this a known and perhaps intended behavior? Cheers, Christian [1]

Re: OpenJDK 10 and Oracle JDK10 doesn't have the same default modules

alan.bate...@oracle.com> wrote: > On 04/02/2018 12:45, Christian Stein wrote: > > : > > It's an automatic module. And it does run "as-is" on Oracle JDK, > using ALL-MODULE-PATH. > > Here is the actual command: > > java > --module-path > bin/bach/

Re: OpenJDK 10 and Oracle JDK10 doesn't have the same default modules

On Sun, Feb 4, 2018 at 2:39 PM, Alan Bateman wrote: > [...] > I suspect this issue is nothing to do with `--add-modules > ALL-MODULE-PATH`. Instead it's probably one of the JavaFX modules that > `requires java.scripting`. You should be able to diagnose this quickly by >

Re: OpenJDK 10 and Oracle JDK10 doesn't have the same default modules

On Sun, Feb 4, 2018 at 1:38 PM, Alan Bateman wrote: > On 04/02/2018 11:30, Remi Forax wrote: > >> Hi all, >> it seems that the OpenJDK 10 and OracleJDK 10 doest not declare the same >> set of default modules, so java --add-modules ALL-DEFAULT do not behave the >> same

Re: Scanning modules?

Hi Greg, short disclaimer: I'm learning and testing the "--scan-module" magic at the moment to implement a similar feature in JUnit 5. See [1] for details. If I'm talking non-sense, please correct me jigsaw-devs. To scan the contents of a module you'll need a ModuleReference[2] instance. You may

Re: ServiceLoader usage in automatic module fails

On Mon, Sep 11, 2017 at 2:21 PM, Alan Bateman wrote: > [...] > > You can also use `--show-module-resolution` to get traces at startup and > satisfied yourself that it working correctly. Using the symbolic constant `--add-modules ALL-MODULE-PATH` works even better when

Re: ServiceLoader usage in automatic module fails

On Mon, Sep 11, 2017 at 1:17 PM, Alan Bateman wrote: [...] > > Also can you run with `--add-modules demo` as I assume the scenario you is > that "demo" is not resolved (because no modules `requires demo` and no > module declares that it uses the service type that demo

Re: ServiceLoader usage in automatic module fails

d module. [5] https://github.com/sormuras/sawdust/blob/master/module-discoverer/demo/src/module-info.java [6] https://github.com/sormuras/sawdust/blob/master/module-discoverer/build.jsh#L82 On Mon, Sep 11, 2017 at 12:52 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > On 11/

ServiceLoader usage in automatic module fails

Hi jigsaw team, I discovered an issue with the ServiceLoader trying to load services on the module-path, when the actual ServiceLoader.load() call resides in an automatic module. I compiled a small demo at [1] and it's console output is visible at [2]. If you want to re-run the demo, just call