Re: Fwd: JMOD, native libraries and the packaging of JavaFX

Hi, Thanks for your interest! I'm always trying to do all that I can, but I'm pretty much just one guy working on this part-time... Besides, this is the kind of thing that should be standardized in the JDK, and Oracle isn't exactly low in resources ($9 billion net income last year, wow), so

Re: RFR: 8202810: Remove class-for-name test

Mandy, Jim, thanks for the quick reviews. Pushed. /Claes On 2018-05-08 22:56, James Laskey wrote: +1 Sent from my iPhone On May 8, 2018, at 5:45 PM, Claes Redestad wrote: Hi, please review the removal of this test that explicitly attempts to run the now

Re: RFR: 8202810: Remove class-for-name test

+1 Sent from my iPhone > On May 8, 2018, at 5:45 PM, Claes Redestad wrote: > > Hi, > > please review the removal of this test that explicitly attempts to run the > now removed jlink --class-for-name plugin: > > diff -r 7f05a1e6a02a

Re: RFR: 8202810: Remove class-for-name test

+1 I checked and this is the only test needed update. Mandy On 5/8/18 1:45 PM, Claes Redestad wrote: Hi, please review the removal of this test that explicitly attempts to run the now removed jlink --class-for-name plugin: diff -r 7f05a1e6a02a test/jdk/tools/jlink/JLinkPluginsTest.java

RFR: 8202810: Remove class-for-name test

Hi, please review the removal of this test that explicitly attempts to run the now removed jlink --class-for-name plugin: diff -r 7f05a1e6a02a test/jdk/tools/jlink/JLinkPluginsTest.java --- a/test/jdk/tools/jlink/JLinkPluginsTest.java    Tue May 08 15:42:19 2018 +0200 +++

Re: Cyclic dependencies during multi-module compilation

I still consider this to be a non-bug. The cycle check has absolutely no useful purpose other than "scratching an itch". On Tue, May 8, 2018 at 3:01 AM, Nicolai Parlog wrote: > Hi! > > In early access builds, multi-module compilation would fail if there was > a dependency

Re: Fwd: JMOD, native libraries and the packaging of JavaFX

Thanks Samuel! I wasn't familiar with JavaCPP before, that sounds like a great project. You are right that there's a lot of overlap here with other efforts, and that standardising some basic things like JAR locations is the right place to begin. I suspect a JEP requires actual changes to OpenJDK

Re: Cyclic dependencies during multi-module compilation

On 08/05/2018 11:16, Nicolai Parlog wrote: Here it is: https://github.com/CodeFX-org/demo-jpms-monitor/blob/break-cyclic-dependency-compile-time/monitor.statistics/src/main/java/module-info.java#L3 Maybe you looked at the master branch? Would it be possible to package this up and

Re: Cyclic dependencies during multi-module compilation

Sorry. I switched to the branch and now I see the issue. Looks like a bug for me. 2018-05-08 17:16 GMT+07:00 Nicolai Parlog : > Here it is: > > https://github.com/CodeFX-org/demo-jpms-monitor/blob/break- > cyclic-dependency-compile-time/monitor.statistics/src/ >

Re: Cyclic dependencies during multi-module compilation

Here it is: https://github.com/CodeFX-org/demo-jpms-monitor/blob/break-cyclic-dependency-compile-time/monitor.statistics/src/main/java/module-info.java#L3 Maybe you looked at the master branch? On 08.05.2018 12:11, Zheka Kozlov wrote: > Are you sure that you have a cycle between

Re: Self-attach using attach API

The Attach API is maintained on the serviceability-dev list. That would the best place to discuss improving the exception message. The AttachNotSupportedException is intended to be thrown when there isn't an attach provider deployed that is compatible with the target VM. I don't know anything

Re: Cyclic dependencies during multi-module compilation

Are you sure that you have a cycle between modules? You state that "monitor.statistics depends on monitor.persistence", however I do not see this in module-info.java: module monitor.statistics { requires monitor.observer; exports monitor.statistics; } 2018-05-08 16:34 GMT+07:00 Nicolai Parlog

Re: Cyclic dependencies during multi-module compilation

Hi Zheka, this branch demonstrates what I describe: https://github.com/CodeFX-org/demo-jpms-monitor/tree/break-cyclic-dependency-compile-time Run `multi-compile.sh && run.sh` and you will see the compiler happily creating the modules whereas the runtime complains about the cyclic

Self-attach using attach API

I have read through previous discussions about self-attach using the attach API. With JDK 10 I see the following exception on self-attach: java.io.IOException: Can not attach to current VM at jdk.attach/sun.tools.attach.HotSpotVirtualMachine.(HotSpotVirtualMachine.java:75) at

Re: Cyclic dependencies during multi-module compilation

On 08/05/2018 09:01, Nicolai Parlog wrote: Hi! In early access builds, multi-module compilation would fail if there was a dependency cycle between the involved modules. I just realized that that is no longer the case in 9.0.1 and later (up to Java 11). This sounds like a bug and I would

Re: Cyclic dependencies during multi-module compilation

Hi Nicolai. I cannot reproduce what you said. I'm using JDK 10.0.1. I created two modules moduleA and moduleB which require each other. When I tried to compile, javac failed with an error: cyclic dependence involving module. Do you observer a different behavior? 2018-05-08 15:01 GMT+07:00

Cyclic dependencies during multi-module compilation

Hi! In early access builds, multi-module compilation would fail if there was a dependency cycle between the involved modules. I just realized that that is no longer the case in 9.0.1 and later (up to Java 11). I'm interested to learn the background for that decision? I considered that check A