Re: Retrieving the bytes of platform classes

>From within Java (i.e. for the current VM) you could simply do: ClassLoader.getSystemResourceAsStream("java/io/InputStream.class") Regards, Volker On Tue, Oct 24, 2017 at 3:47 AM, Sundararajan Athijegannathan wrote: > A simple nashorn sample to

"The State of the Module System" should be marked as outdated

Hi, I think this has been mentioned before, but "The State of the Module System" under http://openjdk.java.net/projects/jigsaw/spec/sotms/ is outdated and constantly keeps confusing people. E.g. it still uses "requires public" instead of "requires transitive" Can you please either update the

Re: JPMS Access Checks, Verification and the Security Manager

Thanks Alex, that makes sense. Regards, Volker On Fri, Jun 2, 2017 at 2:13 AM, Alex Buckley <alex.buck...@oracle.com> wrote: > On 5/24/2017 12:13 AM, Volker Simonis wrote: >> >> OK, so from what you say I understand that the verification errors I >> see with t

Re: Will split-packages ever be supported?

One limitation is that it is not a "standard" Java option so you can't be sure every Java 9 implementation supports it. On Tue, May 30, 2017 at 7:11 PM, Stephen Felts wrote: > So for this use case if patches are used, there would be one jar on the > module path and 44

Re: JPMS Access Checks, Verification and the Security Manager

On Tue, May 23, 2017 at 10:01 PM, Alex Buckley <alex.buck...@oracle.com> wrote: > On 5/23/2017 7:44 AM, Volker Simonis wrote: >> >> So maybe I rephrase my question a little more generally: >> >> Is it required for the verifier to do security and/or access checks

Re: JPMS Access Checks, Verification and the Security Manager

On Tue, May 23, 2017 at 10:20 AM, Alan Bateman wrote: > Volker - one suggestion for your experiments is to change your JDK 8 > security properties file (java.security) to add "com.sun.crypto.provider." > to the value of the "package.access" property. That should mean you

Re: JPMS Access Checks, Verification and the Security Manager

On Tue, May 23, 2017 at 10:51 AM, David Holmes wrote: > On 23/05/2017 6:20 PM, Alan Bateman wrote: >> >> Volker - one suggestion for your experiments is to change your JDK 8 >> security properties file (java.security) to add "com.sun.crypto.provider." >> to the value of

JPMS Access Checks, Verification and the Security Manager

Hi, my question is if it is OK for a program which otherwise runs fine to fail during class verification if running with a security manager because of module access restrictions? As the following write-up got a little lengthy, I've also uploaded a html version for a nicer reading experience :)

Re: Attaching to a JVM image that does not include java.instrument

Hi, without judging any of the proposals in this thread, I just want to clarify some things: - jlink is no standard tool (i.e. it is neither specified nor mandated by the new Java SE 9 specification). This equally applies to the new jimage/jmod file formats. - in contrast, the minimal, compact

Re: Proposal: Allow illegal reflective access by default in JDK 9

On Fri, May 19, 2017 at 1:05 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 19/05/2017 10:48, Volker Simonis wrote: > >> : >> >> From my understanding, at run-time, "open" implicates "exports" (i.e. >> if a module M1 opens a p

Re: Proposal: Allow illegal reflective access by default in JDK 9

Hi Mark, thanks for this proposal. I think it is pragmatic and well balanced. While I personally agree with the advocates of a clean solution I also understand the the needs of big (and slow) companies (including the one I'm working for:) After all, the new default isn't that bad in my opinion

Re: Disallowing the dynamic loading of agents by default

This attempt to disable the ability of "dynamic agent loading" by default somehow reminds me of the recently added "ptrace protection" Linux kernel feature [1] which can be configured to disallow PTRACE_ATTACH to any other process running under the same uid. As far as I know, only Ubuntu disallows

Re: java.lang.management.RuntimeMXBean not module aware

On Tue, Mar 7, 2017 at 6:56 PM, Mandy Chung <mandy.ch...@oracle.com> wrote: >> >> On Mar 7, 2017, at 12:32 AM, Volker Simonis <volker.simo...@gmail.com> wrote: >> >> Hi, >> >> java.lang.management.RuntimeMXBean offers methods like getClassPath(

java.lang.management.RuntimeMXBean not module aware

Hi, java.lang.management.RuntimeMXBean offers methods like getClassPath(), getLibraryPath() and even getBootClassPath() if isBootClassPathSupported() returns true. While isBootClassPathSupported() has been changed in jdk9 to always return false (although the VM still supports -Xbootclasspath/a)

Re: Extending java.base module

On Wed, Feb 15, 2017 at 5:20 PM, Volker Simonis <volker.simo...@gmail.com> wrote: > > On Wed, Feb 15, 2017 at 5:16 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 15/02/2017 16:01, Daniel Fuchs wrote: > > > >> > >> In th

Re: Extending java.base module

On Wed, Feb 15, 2017 at 5:16 PM, Alan Bateman wrote: > On 15/02/2017 16:01, Daniel Fuchs wrote: > >> >> In that specific case it's not java.base that depends >> on java.security.jgss, but the application itself. >> >> So I would expect the application code to either

Re: Extending java.base module

Hi Max, I'm not an jigsaw either, but wouldn't your solution break a tool like jlink? In other words, if an application uses your code and the developer uses jlink to create a run-time image, wouldn't that image fail to execute his application because jlink fails to see that java.base depends on

Build jigsaw ans jdk9 ea builds with '--with-version-patch=1'

Hi, I would highly recommend to build the jigsaw andjdk9 ea builds with '--with-version-patch=1'. This will result in a java.version of the form "9.0.0.1-..." and give people a chance to "really" test the new Java versioning scheme. Otherwise they will only detect potential problems with the

Re: Need help testing the EA builds

wrote: >> >> >> On 08/03/2016 07:45, Volker Simonis wrote: >>> : >>> OK, that would be fine. This problem isn't very urgent but it would be >>> good if we could resolve it before the big jake integration into >>> jdk9-dev. >>> &g

Re: Need help testing the EA builds

On Tue, Mar 8, 2016 at 3:08 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 08/03/2016 07:45, Volker Simonis wrote: >> >> : >> OK, that would be fine. This problem isn't very urgent but it would be >> good if we could resolve it before the b

Re: Need help testing the EA builds

On Mon, Mar 7, 2016 at 8:58 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 07/03/2016 18:23, Volker Simonis wrote: >> >> : >> >> So while the tools are not being refactored, how can we fix the build >> on non-SA platforms if moving the

Re: Need help testing the EA builds

Hi Alan, Dmitry, thanks a lot for your help. Alan's suggestion to move the dependency from src/jdk.jcmd/share/classes/module-info.java to src/jdk.jcmd/$OS/classes/module-info.java.extra works fine. After doing that change I could successfully build on AIX. I'll open a bug for this and post a

Re: RFR(XS): 8132475 : The commands in the modular images are executable by the owner only (once again)

On Tue, Jul 28, 2015 at 10:04 PM, Alan Bateman alan.bate...@oracle.com wrote: On 28/07/2015 19:32, Volker Simonis wrote: Hi, could you please review this tiny change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132475/ https://bugs.openjdk.java.net/browse/JDK-8132475 After 8080511

Re: RFR(XS): 8066589: Make importing sa-jdi.jar optional on its existance

On 2014-12-09 20:12, Volker Simonis wrote: On Fri, Dec 5, 2014 at 10:11 AM, Erik Joelsson erik.joels...@oracle.com wrote: Hello Volker, Are these the only conditions for when sa-jdi.jar is not built? If so, then I suppose this is fine. Yes. But with my proposed solution any new platform may

RFR(XXS): 8066766: The commands in the modular images are executable by the owner only

Hi, after the integration of the modular changes into jdk9-dev the executable commands in jdk/bin and jre/bin images are only executable by the file owner. This means that only the user who built the images can execute the programs. This can be easily fixed with the following trivial change:

Re: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only

On Fri, Dec 5, 2014 at 6:37 PM, Alan Bateman alan.bate...@oracle.com wrote: On 05/12/2014 17:34, Alan Bateman wrote: On 05/12/2014 17:26, Volker Simonis wrote: But why do we need an exception if setting the executable flags fails on 'jspawnhelper' and don't need on if it fails

RFR(XS): 8066589: Make importing sa-jdi.jar optional on its existance

Hi, could you please review this tiny change which fixes the build on platforms which don't built the SA agent after the recent modualrity integrations: http://cr.openjdk.java.net/~simonis/webrevs/8066589 https://bugs.openjdk.java.net/browse/JDK-8066589 I've tested that the fix works on AIX but

Re: How does the removal of rt.jar affect javac -source -target -bootclasspath?

Thanks for the clarification Jonathan. Regards, Volker On Tue, Nov 4, 2014 at 4:05 PM, Jonathan Gibbons jonathan.gibb...@oracle.com wrote: On 11/04/2014 01:55 AM, Volker Simonis wrote: Hi, first of all I'm not Jigsaw expert in any way so if this question has been discussed/answered before