>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 extract single .class using jrt file system
> pr
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 docu
Thanks Alex,
that makes sense.
Regards,
Volker
On Fri, Jun 2, 2017 at 2:13 AM, Alex Buckley 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 the Security Manager enabled are an imp
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 jars passed to --patch-modu
On Tue, May 23, 2017 at 10:01 PM, Alex Buckley 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
>> during the verific
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 will get
> the same Access
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 the "package.access" proper
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 :)
h
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 a
On Fri, May 19, 2017 at 1:05 PM, Alan Bateman 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 package P for some other module M2
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 be
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
perts/2017-March/16.html
On Mon, Mar 27, 2017 at 10:56 PM, Alan Bateman wrote:
> On 27/03/2017 19:34, Volker Simonis wrote:
>
>> Where can I find the authoritative definition of the Java SE 9 module
>> dependencies and relationships?
>
> JSR 379 / Java SE 9 isn't f
Where can I find the authoritative definition of the Java SE 9 module
dependencies and relationships?
When I'm looking at the "Modular platform" [1] section of the "Java SE
9 Public Review Specification", I can see the "module graph". Its
module dependencies seem to correspond to the Java 9 API do
On Tue, Mar 7, 2017 at 6:56 PM, Mandy Chung wrote:
>>
>> On Mar 7, 2017, at 12:32 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> java.lang.management.RuntimeMXBean offers methods like getClassPath(),
>> getLibraryPath() and even getBootClassPath() if
>>
On Tue, Mar 7, 2017 at 10:06 AM, Alan Bateman wrote:
> On 07/03/2017 08:32, Volker Simonis wrote:
>
>> Hi,
>>
>> java.lang.management.RuntimeMXBean offers methods like getClassPath(),
>> getLibraryPath() and even getBootClassPath() if
>> isBootClas
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) no
On Wed, Feb 15, 2017 at 5:20 PM, Volker Simonis
wrote:
>
> 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.securit
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 require
>> java.security.jgss,
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
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 first
regard to fixing the dependencies on the SA agent in the build
I'm completely happy with your change.
Thank you and best regards,
Volker
On Wed, Mar 9, 2016 at 12:00 AM, Mandy Chung wrote:
>
>> On Mar 8, 2016, at 6:08 AM, Alan Bateman wrote:
>>
>>
>> On 08/03/2016
On Tue, Mar 8, 2016 at 3:08 PM, Alan Bateman 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
>
On Mon, Mar 7, 2016 at 8:58 PM, Alan Bateman 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 SA dependency to
>> module-info.ja
at 3:00 PM, Alan Bateman wrote:
> On 07/03/2016 13:53, Volker Simonis wrote:
>>
>> 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/clas
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 webre
Hi Alan, Dmitry,
I've tried today to build the jake repository on AIX. Unfortunately
that doesn't work because we now have a hard dependency on SA which is
required by jcmd:
$cat jdk/src/jdk.jcmd/share/classes/module-info.java
module jdk.jcmd {
requires jdk.attach;
requires jdk.jvmstat;
On Tue, Jul 28, 2015 at 10:04 PM, Alan Bateman 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.jav
-8059035
>
> -Dmitry
>
>
> On 2014-12-09 20:12, Volker Simonis wrote:
>> On Fri, Dec 5, 2014 at 10:11 AM, Erik Joelsson
>> wrote:
>>> Hello Volker,
>>>
>>> Are these the only conditions for when sa-jdi.jar is not built? If so, then
>&g
tforms.
It just fixes the location of the static version of libjli:
http://cr.openjdk.java.net/~simonis/webrevs/8066589.v2/
OK to push now?
Thanks,
Volker
>
> /Erik
>
>
> On 2014-12-04 18:49, Volker Simonis wrote:
>>
>> Hi,
>>
>> could you please re
On Fri, Dec 5, 2014 at 7:43 PM, Chris Hegarty wrote:
> On 5 Dec 2014, at 18:14, Volker Simonis wrote:
>
>> On Fri, Dec 5, 2014 at 7:09 PM, Chris Hegarty
>> wrote:
>>> Volker,
>>>
>>> Personally I would use the more verbose version,
>>> Fil
throw an exception on Windows
I'll be happy to use that version for the binaries as well.
>
> -Chris.
>
> On 5 Dec 2014, at 16:50, Volker Simonis wrote:
>
>> Hi Chris,
>>
>> thanks for the fast response.
>>
>> I saw that code in ImageBuilder, bu
On Fri, Dec 5, 2014 at 6:37 PM, Alan Bateman 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&#x
On Fri, Dec 5, 2014 at 6:00 PM, Alan Bateman wrote:
> On 05/12/2014 16:50, Volker Simonis wrote:
>>
>> Hi Chris,
>>
>> thanks for the fast response.
>>
>> I saw that code in ImageBuilder, but it looked overly complicated to
>> me. Wh
etPosixFilePermissions(file, perms);
> } catch (IOException ioe) {
> throw new UncheckedIOException(ioe);
> }
> }
>
> -Chris.
>
>
> On 05/12/14 14:07, Volker Simonis wrote:
>>
>> Hi,
>>
>> after the integration of the modular
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:
htt
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
Thanks for the clarification Jonathan.
Regards,
Volker
On Tue, Nov 4, 2014 at 4:05 PM, Jonathan Gibbons
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
Hi,
first of all I'm not Jigsaw expert in any way so if this question has
been discussed/answered before please be so kind to point me to the
right link.
I've just skimmed JEP 220 and it is not clear to me how the removal of
rt.jar/tools.jar will affect the compilation with "-source -target
-boot
39 matches
Mail list logo
