Re: java -jar should run in module mode if the jar is a mdular jar
- Mail original - > De: "mark reinhold" > À: "Thomas Watson" > Cc: jigsaw-dev@openjdk.java.net > Envoyé: Lundi 5 Décembre 2016 18:04:43 > Objet: Re: java -jar should run in module mode if the jar is a mdular jar > 2016/12/5 6:15:48 -0800, tjwat...@us.ibm.com: >> This makes sense to me, > > I agree that it makes sense, though it does take away the ability to run > a modular JAR easily as an unnamed module -- I don't know how important > that is to anyone. There are two main classes. The one specified in module-info.class and the one specified in the Manifest. And, jar --main-class set the two values at the same times. So currently if you run the application with java ... -m modulename it runs the code in 'module mode' while if you run the application with java -jar, the code run inside the unnamed module. I think it's better to have -jar that run its main in a module instead of in the unnamed module. Other solution slike adding a -mjar command will not work because you want to be able to run a fat jar by double-clicking on it. > >> but then I wonder if the main class is specified >> in the module-info.class as some type of service or if you continue to >> specify that in the jar manifest. > > If we do implement this then the logical approach would be to interpret > the `MainClass` attribute of the `module-info.class` file. > yes > - Mark Rémi
Defining open modules and packages
Hi,
I heard a lot about jigsaw at Devoxx Belgium this year and got curious what is
in the new module system for us. I downloaded ea build 146 and started to
experiment. So far it was mostly straight forward. But now I'm struggeling to
get open modules (and packages) to work. I tried the syntax described here:
http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html
This is also what was presented in various talks at Devoxx. However when trying
to compile the module-info file I get this error:
Compiling... src/moduleopen/module-info.java:1: error: class, interface, or
enum expected
open module moduleopen {
^
1 error
Unfortunately I wasn't able to find any documentation on a change in syntax. I
only found this:
http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html
which seems to be a different version of the above. But I wasn't able to match
what might be the right alternative for open here. Perhaps someone can clarify
this and perhaps even help with some link to documentation on this.
Regards
Christian Frommeyer
--
Senior Software Engineer 2, PD
GetGo Germany GmbH | Alter Schlachthof 51, 76131 Karlsruhe, Germany
christian.fromme...@citrix.com
Geschäftsführer: Brian Shytle, Caoimhe C. Ní Ghiosáin, Michael DiFilippo, Sitz:
Karlsruhe, Amtsgericht Mannheim HRB713721
This e-mail message and all documents that accompany it may contain privileged
or confidential information, and are intended only for the use of the
individual or entity to which addressed. Any unauthorized disclosure or
distribution of this e-mail message is prohibited. If you have received this
e-mail message in error, please notify me immediately. Thank you.
Re: Defining open modules and packages
Hi Christian,
could it be that you've downloaded the regular EA build 146 rather than
the jigsaw EA build 146[1]?
The changes enabling the new "open" keyword is set to appear in the
regular EA builds starting from build 148 (from there on out I hope
there'll be less difference between the regular EA builds and the jigsaw
ones).
Thanks!
/Claes
[1] https://jdk9.java.net/jigsaw/
On 2016-12-06 12:34, Christian Frommeyer wrote:
Hi,
I heard a lot about jigsaw at Devoxx Belgium this year and got curious what is
in the new module system for us. I downloaded ea build 146 and started to
experiment. So far it was mostly straight forward. But now I'm struggeling to
get open modules (and packages) to work. I tried the syntax described here:
http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html
This is also what was presented in various talks at Devoxx. However when trying
to compile the module-info file I get this error:
Compiling... src/moduleopen/module-info.java:1: error: class, interface, or
enum expected
open module moduleopen {
^
1 error
Unfortunately I wasn't able to find any documentation on a change in syntax. I
only found this:
http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html
which seems to be a different version of the above. But I wasn't able to match
what might be the right alternative for open here. Perhaps someone can clarify
this and perhaps even help with some link to documentation on this.
Regards
Christian Frommeyer
Fwd: RFR [9] 8166568 & 8169492 jmod extract and bug fix
[ forwarding to a more appropriate list to review this change ] > Begin forwarded message: > > From: Chris Hegarty > Subject: RFR [9] 8166568 & 8169492 jmod extract and bug fix > Date: 6 December 2016 at 10:46:08 GMT > To: core-libs-dev > > This change adds a basic option to the jmod tool to extract all its contents > to > the current working directory, 8166568 [1]. Additionally, there is a bug fix > for > a public mutable static, 8169492 [2]. > > http://cr.openjdk.java.net/~chegar/8166568_8169492.00/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8166568 > [2] https://bugs.openjdk.java.net/browse/JDK-8169492
RE: Defining open modules and packages
Hi Claes,
That's it. I just didn't realize there where different ea builds. Works now for
me.
Thanks for pointing me to the solution.
Regards Christian
-Original Message-
From: Claes Redestad [mailto:claes.redes...@oracle.com]
Sent: Dienstag, 6. Dezember 2016 12:41
To: Christian Frommeyer ;
jigsaw-dev@openjdk.java.net
Subject: Re: Defining open modules and packages
Hi Christian,
could it be that you've downloaded the regular EA build 146 rather than the
jigsaw EA build 146[1]?
The changes enabling the new "open" keyword is set to appear in the regular EA
builds starting from build 148 (from there on out I hope there'll be less
difference between the regular EA builds and the jigsaw ones).
Thanks!
/Claes
[1] https://jdk9.java.net/jigsaw/
On 2016-12-06 12:34, Christian Frommeyer wrote:
> Hi,
>
> I heard a lot about jigsaw at Devoxx Belgium this year and got curious what
> is in the new module system for us. I downloaded ea build 146 and started to
> experiment. So far it was mostly straight forward. But now I'm struggeling to
> get open modules (and packages) to work. I tried the syntax described here:
>
> http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html
>
> This is also what was presented in various talks at Devoxx. However when
> trying to compile the module-info file I get this error:
>
> Compiling... src/moduleopen/module-info.java:1: error: class,
> interface, or enum expected open module moduleopen { ^
> 1 error
>
> Unfortunately I wasn't able to find any documentation on a change in syntax.
> I only found this:
>
> http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html
>
> which seems to be a different version of the above. But I wasn't able to
> match what might be the right alternative for open here. Perhaps someone can
> clarify this and perhaps even help with some link to documentation on this.
>
> Regards
> Christian Frommeyer
>
Re: Refresh of module system coming to jdk9/dev soon
On 05/12/2016 20:13, Martin Buchholz wrote: Whitebox testing is the most obvious example of code that has a good excuse for poking inside implementation details. For running jsr166 tests, I'm happy to report that the following seems to work: +if:set="modules"/> +if:set="modules"/> + + It would be nice if there was explicit guidance for authors of tooling software like test harnesses. There have been a number of threads on jigsaw-dev on this topic. Whitebox tests that are in the same package as the API under test (by convention or because they are testing package-private methods) can be compiled and run "as if" they are part of the module. This is done with the --patch-module option, like what you are doing to override the jsr166 classes in java.base. Code in a module can do "deep reflection" on any element of any type in its own module so the tests shouldn't have any issue when they are in the module. That said, there might some additional command line options needed to allow the test runner invoke the tests (where the tests are added to the module in a non-exported package) or where the tests links to the supporting test library (probably JUnit here). We've worked with many scenarios where everything is modules or where there is a mix of modules and class path, it can all be made to work. In time then I hope the test runners will make this easier but there isn't anything specifically written up yet. It would be nice if the production software could define test-only methods (think "checkInvariants()") that could be invoked without having to resort to reflection. Google has some use-this-method-in-tests-only tooling that uses annotations, but the enforcement is external to the jdk. I keep hoping that module systems would somehow work at the method level instead of the package level, because we already have visibility keywords like private at the method level. If the checkInvariant methods aren't public then the packages that they are in will needed to be opened to whoever calls them. For the scenario then qualified exports or qualified opens can be used to export and/or open specific packages to test modules. Giving access to internals to legitimate tools while preventing other uses seems like a Hard Problem. For tools like debuggers or heap analyzers that really want to see everything, there will be a strong desire to "disable all module checks". Or maybe the right way is for users to patch them into java.base? Guidance needed. We updated the debugger support and the tools APIs to support modules some time ago. I'm not sure if we have a specific issue in mind but the debugger support involves JVM TI and JNI on the backend so there isn't an issue with accessibility. Heap analyzers that are based on the tool APIs should be fine too, as should tools and agents based on the instrumentation API (it's even possible for agents that don't know anything about modules to instrument code in modules). -Alan
Re: Reading bootstrap class bytecode from Java 7
On 06/12/2016 02:07, Ess Kay wrote:
Are there any code snippets anywhere that demonstrate using Java 9's
jrt-fs.jar from within Java 8 to access Java 9 java.lang.Object?
Cannot find any using Google. Struggling to make this work.
Here's a code fragment that reads the bytes for java/lang/Object.class,
just point it at the target image and it will create a URLClassLoader
that loads from the target image's jrt-fs.jar:
String targetImage = ...
URL url = Paths.get(targetImage, "lib", "jrt-fs.jar").toUri().toURL();
URLClassLoader loader = new URLClassLoader(new URL[] { url });
FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"),
Collections.emptyMap(), loader);
Path file = fs.getPath("/modules/java.base/java/lang/Object.class");
byte[] bytes = Files.readAllBytes(file);
Existing tools might find it easier to look at the /packages tree, the
file system has sym links to support this type of navigation when needed.
-Alan
Re: Defining open modules and packages
Hi!
If anybody else struggles with this, I created a GitHub repo[1]
exploring different ways to make reflection work and also wrote about it[2].
so long ... Nicolai
[1] https://github.com/CodeFX-org/demo-jigsaw-reflection
[2]
https://www.sitepoint.com/reflection-vs-encapsulation-in-the-java-module-system/
On 06.12.2016 13:00, Christian Frommeyer wrote:
> Hi Claes,
>
> That's it. I just didn't realize there where different ea builds. Works now
> for me.
>
> Thanks for pointing me to the solution.
>
> Regards Christian
>
> -Original Message-
> From: Claes Redestad [mailto:claes.redes...@oracle.com]
> Sent: Dienstag, 6. Dezember 2016 12:41
> To: Christian Frommeyer ;
> jigsaw-dev@openjdk.java.net
> Subject: Re: Defining open modules and packages
>
> Hi Christian,
>
> could it be that you've downloaded the regular EA build 146 rather than the
> jigsaw EA build 146[1]?
>
> The changes enabling the new "open" keyword is set to appear in the regular
> EA builds starting from build 148 (from there on out I hope there'll be less
> difference between the regular EA builds and the jigsaw ones).
>
> Thanks!
>
> /Claes
>
> [1] https://jdk9.java.net/jigsaw/
>
> On 2016-12-06 12:34, Christian Frommeyer wrote:
>> Hi,
>>
>> I heard a lot about jigsaw at Devoxx Belgium this year and got curious what
>> is in the new module system for us. I downloaded ea build 146 and started to
>> experiment. So far it was mostly straight forward. But now I'm struggeling
>> to get open modules (and packages) to work. I tried the syntax described
>> here:
>>
>> http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html
>>
>> This is also what was presented in various talks at Devoxx. However when
>> trying to compile the module-info file I get this error:
>>
>> Compiling... src/moduleopen/module-info.java:1: error: class,
>> interface, or enum expected open module moduleopen { ^
>> 1 error
>>
>> Unfortunately I wasn't able to find any documentation on a change in syntax.
>> I only found this:
>>
>> http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html
>>
>> which seems to be a different version of the above. But I wasn't able to
>> match what might be the right alternative for open here. Perhaps someone can
>> clarify this and perhaps even help with some link to documentation on this.
>>
>> Regards
>> Christian Frommeyer
>>
>
--
PGP Key:
http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509
Web:
http://codefx.org
a blog about software development
https://www.sitepoint.com/java
high-quality Java/JVM content
http://do-foss.de
Free and Open Source Software for the City of Dortmund
Twitter:
https://twitter.com/nipafx
Re: Reading bootstrap class bytecode from Java 7
Hi,
On 12/05/2016 08:42 AM, Alan Bateman wrote:
On 05/12/2016 07:21, Remi Forax wrote:
Hi,
Object.class.getClassLoader().getResourceAsStream(Object.class.getName().replace('.',
'/') + ".class")
should work across all jdks.
This should work as before (ignoring the issue that
Object.class.getClassLoader() will return null :-))
However, as I read it, the original question involves a tool running
on JDK 7 trying to access the .class files in a JDK 9 image. There
isn't any supported way to do that, the tool needs to be on a minimum
of JDK 8 as the jrtfs provider is compiled to 8.
-Alan
Has anyone tried to translate the jrt-fs.jar using the following tool?
https://github.com/orfjackal/retrolambda
java.nio.file API was introduced in JDK 7 so in theory this could be
possible. With a caveat that even if this appears to work, the resulting
converted jrt-fs.jar will only be suitable for accessing classes in the
image of JDK 9. Until JDK 10 ships, the image format might change and a
new version of jrt-fs.jar will be needed...
Regards, Peter
[9] Review request: JDK-8170485: Switch to building JavaFX with new module-info syntax
Chien & Dave, Please review the preliminary webrev to allow building JavaFX with jdk-9+148 and later: https://bugs.openjdk.java.net/browse/JDK-8170485 http://cr.openjdk.java.net/~kcr/8170485/webrev.00/ The details are in the JBS issue and also in the "HEADS-UP" message [1] I sent yesterday. As indicated in JBS, I will update the webrev later this week to bump the minimum build to 148 once 148 is promoted and available on java.net. No other changes are anticipated (unless you find anything while reviewing it). -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-December/020014.html
Re: Fwd: RFR [9] 8166568 & 8169492 jmod extract and bug fix
On 06/12/2016 11:44, Chris Hegarty wrote: [ forwarding to a more appropriate list to review this change ] Begin forwarded message: From: Chris Hegarty Subject: RFR [9] 8166568 & 8169492 jmod extract and bug fix Date: 6 December 2016 at 10:46:08 GMT To: core-libs-dev This change adds a basic option to the jmod tool to extract all its contents to the current working directory, 8166568 [1]. Additionally, there is a bug fix for a public mutable static, 8169492 [2]. http://cr.openjdk.java.net/~chegar/8166568_8169492.00/ This looks okay to me although I would expect it would be useful to extract to a specific location too. -Alan
Re: RFR [9] 8166568 & 8169492 jmod extract and bug fix
Hi Chris, Changes looks good. I think tests should be added for case when there are extracted files in directory. —Andrey > On 6 Dec 2016, at 14:44, Chris Hegarty wrote: > > [ forwarding to a more appropriate list to review this change ] > >> Begin forwarded message: >> >> From: Chris Hegarty >> Subject: RFR [9] 8166568 & 8169492 jmod extract and bug fix >> Date: 6 December 2016 at 10:46:08 GMT >> To: core-libs-dev >> >> This change adds a basic option to the jmod tool to extract all its contents >> to >> the current working directory, 8166568 [1]. Additionally, there is a bug fix >> for >> a public mutable static, 8169492 [2]. >> >> http://cr.openjdk.java.net/~chegar/8166568_8169492.00/ >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8166568 >> [2] https://bugs.openjdk.java.net/browse/JDK-8169492 >
Lokkup.find* do not add read edges like reflection does
Hi all, when using Method.invoke, we automatically add a read edge between the current class and the called class when invoking a method by reflection but if one uses methods lookup.find*, he had to add the read edge manually. I think we should harmonize the behavior and add a read edge when using java.lang.invoke API too. cheers, Rémi
Re: Lokkup.find* do not add read edges like reflection does
On 06/12/2016 19:41, Remi Forax wrote: Hi all, when using Method.invoke, we automatically add a read edge between the current class and the called class when invoking a method by reflection but if one uses methods lookup.find*, he had to add the read edge manually. I think we should harmonize the behavior and add a read edge when using java.lang.invoke API too. Core reflection doesn't actually add read edges of course, it instead just assumes readability. This avoids needing to change code using core reflection when migrating that code to explicit modules. The reason that java.lang.invoke checks readability is because it's aligned with bytecode. It would be a significant change if the access checks in java.lang.invoke differed to bytecode. -Alan
Re: [9] Review request: JDK-8170485: Switch to building JavaFX with new module-info syntax
On 06/12/2016 16:10, Kevin Rushforth wrote: Chien & Dave, Please review the preliminary webrev to allow building JavaFX with jdk-9+148 and later: https://bugs.openjdk.java.net/browse/JDK-8170485 http://cr.openjdk.java.net/~kcr/8170485/webrev.00/ The updates to the module-info.java sources look good. -Alan
Re: Lokkup.find* do not add read edges like reflection does
On Dec 6, 2016, at 1:04 PM, Alan Bateman wrote: > > The reason that java.lang.invoke checks readability is because it's aligned > with bytecode. It would be a significant change if the access checks in > java.lang.invoke differed to bytecode. The CONSTANT_MethodHandle constants very closely align with bytecode behavior, in the same class-file as the hypothetical bytecodes; should they respect read-edges? Yes. The Lookup.find* API parallels those constants, with as little divergence as possible. Respect read-edges there? Yes again. Bytecode behavior alignment means that anything you can do by loading a classfile (or anon-class) next to the target class can also be done by a method handle. Should such aux. classes respect read-edges? Of course. Diverging behavior between the above three access points (to bytecode behaviors) is possible but undesirable. It would make refactoring operations and security analysis more painful. On the other hand, there are reasons why Core Reflection ignores read-edges. I suppose they are rooted in the dynamic, ad hoc, late-bound nature of reflective usage, as opposed to statically bound behavior attached to a particular bundle of bytecodes. MH usage is often static but sometimes ad hoc. Some MH use cases are: - dynamic language, compiled call sites (S) - dynamic language, interpreted call sites (S?) - lambda capture (S) - string concat (S) - future use of indy by javac (S) - unit tests for APIs (D?) - optimization of Core Reflection calls (D) Anything marked (S) is tightly coupled to a class file, *not* ad hoc, and must respect read-edges. (IMO read-edges are not a security feature but a help to debugging unexpectedly emergent dependencies at run time.) There are probably more (D) cases I'm missing. For that last case (D) the read-edge check by Lookup can be worked around by performing the lookup in Core Reflection, and then using Lookup.unreflect*. I think we should consider relaxing the read-edge check *just* for that case, allowable since Lookup.unreflect* is not precisely coupled to BC behavior. That would leave the Lookup.find* and CONSTANT_MH access points unchanged (strongly coupled to BC behavior). I think one reason Core Reflection requires a loophole for reads-edges is that it does not contain any reliable mechanism for delegated access checks. (This is also why the calls are slow: The checks are done in a hacky @CS manner.) Since MH-using code must always keep track of the Lookup for the principal, that principal's reads-edges can be expected to "make sense", and a failure to read is something that (should be) less likely than with Core Reflection, where there cannot be any accurate knowledge of the principal (whose reads-edges are the ones that matter). So, that's the theory that makes sense to me. What's the practice? :-) — John
Re: [9] Review request: JDK-8170485: Switch to building JavaFX with new module-info syntax
> On Dec 6, 2016, at 8:10 AM, Kevin Rushforth > wrote: > > Chien & Dave, > > Please review the preliminary webrev to allow building JavaFX with jdk-9+148 > and later: > > https://bugs.openjdk.java.net/browse/JDK-8170485 > http://cr.openjdk.java.net/~kcr/8170485/webrev.00/ > > The details are in the JBS issue and also in the "HEADS-UP" message [1] I > sent yesterday. > > As indicated in JBS, I will update the webrev later this week to bump the > minimum build to 148 once 148 is promoted and available on java.net. No other > changes are anticipated (unless you find anything while reviewing it). Looks good. Mandy
Re: testing for a class having been loaded
JDK-8170834 > On Nov 30, 2016, at 11:13 AM, Alan Snyder wrote: > > By the way, I had no trouble finding examples on the web of using > findLoadedClass() via reflection. I listed the first 11 below. > > Obviously, this hack is known, of interest, and used. > > I think it deserves to be an issue. > >> As I said, this change will not be popular but please bear with it until the >> extent of the issues uncovered is more widely understood. We need all the >> help we can get to identify issues and get them reported (and hopefully >> fixed) by the libraries and tools with the technical debt (and we expect a >> lot of it will be technical debt). For those working on OpenJDK and the JDK >> 9 project then it's very possible that some of these issues will redirect to >> the JDK as requests for new APIs or hooks (and I assume will need to be >> looked at on a case-by-case basis). >> >> Any help reporting issues to popular tools and libraries would be >> appreciated. > > > > https://github.com/HotswapProjects/HotswapAgent/blob/master/hotswap-agent-core/src/main/java/org/hotswap/agent/util/classloader/ClassLoaderHelper.java > > http://stackoverflow.com/questions/482633/in-java-is-it-possible-to-know-whether-a-class-has-already-been-loaded > > http://stackoverflow.com/questions/12093271/how-do-i-determine-class-loading-order-when-i-inject-them-into-the-systemclasslo > > https://dzone.com/articles/classloaderlocal-how-avoid > > http://snacktrace.com/artifacts/net.bytebuddy/byte-buddy-dep/1.3.20/net.bytebuddy.dynamic.loading.ClassInjector > > https://fossies.org/linux/yacy/source/net/yacy/document/parser/pdfParser.java > > http://lists.jboss.org/pipermail/jboss-cvs-commits/2010-May/120099.html > > https://devops.ands.org.au/browse/VT-BUILD-55/artifact/JOB1/Javadoc/src-html/au/org/ands/vocabs/toolkit/utils/ApplicationContextListener.html > > http://visualvm.sourcearchive.com/documentation/1.2.1-0ubuntu1/ClassLoaderManager_8java-source.html > > http://code.taobao.org/svn/QLExpress/trunk/src/main/java/com/ql/util/express/ExpressClassLoader.java > > http://svn.rifers.org/rife/tags/release-1.4/src/framework/com/uwyn/rife/engine/EngineClassLoader.java > >
