Mystery solved or problem solved? Have you fixed it somewhere else?
Thanks
Max
On 7/7/2016 17:00, Peter Firmstone wrote:
Problem solved, even though it didn't occur on Java 8, the potential for
it to occur still exists there, it's simply that Java 9 seems to have
hit this execution path, it wa
Ok, please send me your putback comment. Otherwise, I will just use my
own wording. ;)
Should get it done either later today or tomorrow...
Thanks,
Valerie
On 7/6/2016 11:31 AM, Alexandre (Shura) Iline wrote:
Valerie, could you sponsor the patch for me?
Shura
On Jul 6, 2016, at 10:08 AM, Val
It should be pointed out that the only reason IoC containers can succeed
with setAccessible() is because developers commonly run without the
Security Manager enabled. People who use IoC want to this circumvention on
purpose. It's not an oversight -- it's intended. As far as I am concerned,
if you'r
Hi Jason,
On 7/7/2016 1:17 PM, Jason Greene wrote:
I wanted to second Paul’s comments on jams-spec-comments[1], but with
some additional thoughts.
The proposal takes a step in the right direction by allowing a
runtime path to bypass access control. However, the fundamental issue
at play is that
On Jul 7, 2016, at 11:05 AM, Martin Buchholz wrote:
> private static final jdk.internal.misc.Unsafe
> java.util.concurrent.ConcurrentHashMap.U
Unless the security manager is turned on, you can do setAcc to pick up all
sorts of private fields.
As Alan points out, it would be good to tighten th
I wanted to second Paul’s comments on jams-spec-comments[1], but with some
additional thoughts.
The proposal takes a step in the right direction by allowing a runtime path to
bypass access control. However, the fundamental issue at play is that class
visibility is being used as an access contro
Not always. For example in the very common situation of existing module
systems where there is one module per class loader, if that module is
the default module (which BTW allows these module systems to retain
their existing resolution and delegation logic), it is certain that the
module will
Clearly the unnamed/default module is an aggregation of many artifacts. I
still don't find the unnamed/default module name useful, but the artifact
enmeshed in the aggregate is. Not only should the stack trace provide this
info, but there should be an API for it too. WDYT?
Cheers,
Paul
On Wed, Ju
On 07/07/2016 19:05, Martin Buchholz wrote:
When jdk9 is released, an army of white, black, grey, and red hats will try
to keep their old Unsafe hacks alive and maybe get their hands on a
jdk.internal.misc.Unsafe.
I assume these Unsafe usages are sun.misc.Unsafe so they should continue
to work.
When jdk9 is released, an army of white, black, grey, and red hats will try
to keep their old Unsafe hacks alive and maybe get their hands on a
jdk.internal.misc.Unsafe. Here's some code that tries to do that. The call
to setAccessible succeeds! And the code succeeds in getting hold
of jdk.interna
Right - I was trying to find documentation on the new url format. Using
the newly downloaded documentation, what I found was things like this
instead:
./api/javax/tools/StandardJavaFileManager.html:
jar:lib/vendorA.jar!/com/vendora/LibraryClass.class
I assumed that they just weren't updated yet;
Not sure how you meant 'jar:' is being replaced, so I might've just
added to the confusion here.
'jrt' is the new scheme used to reference resources in the runtime
image, e.g., "jrt:/java.base/java/net/URL.class", and in some places
where you previously got a jar-based URL you might now get a
Here's the subset that appear to be out of date:
./technotes/guides/javadoc/whatsnew-1.4.2.html
./technotes/guides/io/fsp/zipfilesystemprovider.html
./technotes/guides/jmx/tutorial/lookup.html
./technotes/guides/jmx/examples/Lookup/jini/README
./technotes/guides/security/jaas/tutorials/GeneralAcnA
Oh is that what it is? Yeah, 0 of those either.
Malachi de Ælfweald
http://www.google.com/profiles/malachid
On Thu, Jul 7, 2016 at 8:56 AM, Claes Redestad
wrote:
> Would that be 'jrt:'?
>
> /Claes
>
>
> On 2016-07-07 17:50, Malachi de Ælfweald wrote:
>
>> I believe it was mentioned in one of
Would that be 'jrt:'?
/Claes
On 2016-07-07 17:50, Malachi de Ælfweald wrote:
I believe it was mentioned in one of the threads that part of this change
include moving from jar: to jrl:
Checking the javadoc download, there are 0 mentions of 'jrl:' but 50
mentions of 'jar:'.
Malachi de Ælfwea
I believe it was mentioned in one of the threads that part of this change
include moving from jar: to jrl:
Checking the javadoc download, there are 0 mentions of 'jrl:' but 50
mentions of 'jar:'.
Malachi de Ælfweald
http://www.google.com/profiles/malachid
On Wed, Jul 6, 2016 at 11:36 AM, Alan
2016/7/7 7:58:29 -0700, ad...@redhat.com:
> On 07/07/16 15:52, Paul Benedict wrote:
>> Hi Mark. Do these set of changes mean those alternative proposals are now
>> set in stone? I didn't know feedback was finished. ...
>
> I though Alan's note made this clear
>
> "The jigsaw/jake forest has been
Thanks Andrew. Lots of emails flying around. I picked the wrong one. I do
see he made it clear in another post. Thanks.
Cheers,
Paul
On Thu, Jul 7, 2016 at 9:58 AM, Andrew Dinn wrote:
>
>
> On 07/07/16 15:52, Paul Benedict wrote:
> > Hi Mark. Do these set of changes mean those alternative propo
On 07/07/16 15:52, Paul Benedict wrote:
> Hi Mark. Do these set of changes mean those alternative proposals are now
> set in stone? I didn't know feedback was finished. For example, and I may
> have missed this, but I can't recall one message in support of the
> "requires static" syntax. As I sai
Hi Mark. Do these set of changes mean those alternative proposals are now
set in stone? I didn't know feedback was finished. For example, and I may
have missed this, but I can't recall one message in support of the
"requires static" syntax. As I said, I may have missed the supporters, but
I don't r
+1
On 7/5/2016 7:48 PM, Jim Laskey (Oracle) wrote:
> Much of the removed code seems unnecessary since the same functionality can
> be accomplished with much simpler code. An example is provided with
> ClassForNamePlugin.java (temporary.) A shipping byte code optimizer plugin
> will be suppli
On 06/07/16 19:36, Alan Bateman wrote:
> So please try it out. As always, the most valuable feedback is from
> those trying out the builds to migrate or modularize existing libraries
> and applications.
Thanks, Alan, I will try this out as soon as I can.
I'm currently trying to organize feedback
On 07/07/2016 09:06, Jayaprakash Arthanareeswaran wrote:
Hi Alan,
That's what I wanted to confirm, that it is not possible to use a
jrt-fs from the JDK wouldn't work on a JRE. If you were wondering why
we would do that, we were looking at other alternatives in case [1]
doesn't happen soon en
Problem solved, even though it didn't occur on Java 8, the potential for it to
occur still exists there, it's simply that Java 9 seems to have hit this
execution path, it was a latent bug.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
Fro
> On Jul 7, 2016, at 4:47 PM, Peter Firmstone
> wrote:
>
> Sorry, I wasn't clear, I meant, create a new instance of SSL, call its
> checkPermission method, then make that instance your system security manager.
That would cure the test too, since it references SQLPermission when
checkPermissi
Yes, that's correct. ;)
Sent from my Samsung device.
Include original message
Original message
From: Alan Bateman
Sent: 07/07/2016 06:37:49 pm
To: Wang Weijun
Cc: jigsaw-dev ; OpenJDK
Subject: Re: Strange test failure when referencing a class in a deprivileged
module
On 07/07/2
Sorry, I wasn't clear, I meant, create a new instance of SSL, call its
checkPermission method, then make that instance your system security manager.
Although the check permission call will be repeated in the test, it will have
run while the standard SecurityManager is in force, so the jvm won't
> On Jul 7, 2016, at 4:37 PM, Alan Bateman wrote:
>
> On 07/07/2016 09:27, Wang Weijun wrote:
>
>> Like this?
>>
>> https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6
>>
>> The horizontal line is printed on line 706 of the gist.
>>
> I assume the suggestion was to reference SQ
On 07/07/2016 09:27, Wang Weijun wrote:
Like this?
https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6
The horizontal line is printed on line 706 of the gist.
I assume the suggestion was to reference SQLPermission before setting
the security manager. As regards module loading t
Like this?
https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6
The horizontal line is printed on line 706 of the gist.
--Max
> On Jul 7, 2016, at 12:57 PM, Peter Firmstone
> wrote:
>
> Can you change the test to call checkPermission prior to setting SSL as the
> system securit
30 matches
Mail list logo
