On 19/03/2017 22:47, Jochen Theodorou wrote:
not wanting to hijack the thread, but why is there no canAccess method
that takes a class argument to check if that class can access? Why
always depending so much on caller sensitive methods?
This method is intended to be used in conjunction with
Hi,
please review this fix to avoid NPEs when calling certain Class methods
via JNI:
Bug: https://bugs.openjdk.java.net/browse/JDK-8177036
Webrev: http://cr.openjdk.java.net/~redestad/8177036/jdk.01/
Thanks!
/Claes
On 03/19/2017 11:42 PM, Peter Levart wrote:
No problem. Here it is (against tip of jake/jdk):
http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.02/
This patch changes a little when the stacktrace requested by
sun.reflect.debugModuleAccessChecks system p
On 20/03/2017 09:19, Claes Redestad wrote:
Hi,
please review this fix to avoid NPEs when calling certain Class
methods via JNI:
Bug: https://bugs.openjdk.java.net/browse/JDK-8177036
Webrev: http://cr.openjdk.java.net/~redestad/8177036/jdk.01/
This looks okay. At some point then we need to se
On 03/20/2017 11:41 AM, Alan Bateman wrote:
On 20/03/2017 09:19, Claes Redestad wrote:
Hi,
please review this fix to avoid NPEs when calling certain Class
methods via JNI:
Bug: https://bugs.openjdk.java.net/browse/JDK-8177036
Webrev: http://cr.openjdk.java.net/~redestad/8177036/jdk.01/
Th
On 20/03/2017 11:42, Peter Levart wrote:
I guess that when only the ClassLoader of the caller is checked in
logic of @CS method, such calls should behave as though the caller was
some class loaded by bootstrap ClassLoader. But what about @CS methods
that inspect the caller class more deeply
On 03/20/2017 12:42 PM, Peter Levart wrote:
Currently core reflection throws InternalError (because of the check
in Reflection::ensureMemberAccess). But jake repo already contains
changes that remove this check and NPE is thrown later on in
verifyModuleAccess...
Regards, Peter
...it is a
I have a couple of questions on the spec wording.
1. * {@code $BUILD}, matching {@code
* (0|[1-9][0-9]*)} --- The build number, incremented for each promoted
* build. {@code $BUILD} is reset to {@code 1} when any portion of {@code
* $VNUM} is incremented.
If the build number i
On 03/20/2017 12:54 PM, Peter Levart wrote:
On 03/20/2017 12:42 PM, Peter Levart wrote:
Currently core reflection throws InternalError (because of the check
in Reflection::ensureMemberAccess). But jake repo already contains
changes that remove this check and NPE is thrown later on in
verif
Hi,
Please find below a patch for:
8177136: Caller sensitive methods Logger.getLogger,
Logger.getAnonymousLogger, and System.getLogger should throw
IllegalCallerException if there is no caller on the stack.
https://bugs.openjdk.java.net/browse/JDK-8177136
Caller sensitive methods Logger.getL
Hi Peter,
On 20/03/2017 12:01, Peter Levart wrote:
Perhaps the best way to rectify those problems in one place would be for
Reflection.getCallerClass() to return a special internal class in its
own package, such as:
jdk.internal.solitary.NoCaller
...when there is no caller. This would work cor
Sorry Daniel but I don't understand how calling a public method via JNI
can be deemed an illegal call ??? This seems to be a hole in the notion
of "caller sensitive" to me.
Also see discussion re: "RFR [9]: 8177036: Class.checkMemberAccess
throws NPE when calling Class methods via JNI"
David
Hi David,
On 20/03/2017 12:16, David Holmes wrote:
Sorry Daniel but I don't understand how calling a public method via JNI
can be deemed an illegal call ???
In the case of these methods, it's only illegal if there's no
java frame on the stack as the caller's module cannot be determined.
It's p
On 20/03/2017 10:29 PM, Daniel Fuchs wrote:
Hi David,
On 20/03/2017 12:16, David Holmes wrote:
Sorry Daniel but I don't understand how calling a public method via JNI
can be deemed an illegal call ???
In the case of these methods, it's only illegal if there's no
java frame on the stack as the
On 20/03/2017 12:37, David Holmes wrote:
What about those API's says there has to be a Java frame higher up. Why
can't an attached thread request a reference to the logger?
Hi David,
Did you look at the webrev?
1582 * @throws IllegalCallerException if there is no caller frame, i.e.
1583
Hello
Hope you can help me with an advice.
I'm using a library, namely spring-jdbc, which implements
java.lang.Object.finalize() in one static inner class which does get
instantiated *a lot*. It creates significant contention on synchronized block
in java.lang.ref.Finalizer from Object's constr
Hi Milan,
On 03/20/2017 02:13 PM, Milan Mimica wrote:
Hello
Hope you can help me with an advice.
I'm using a library, namely spring-jdbc, which implements
java.lang.Object.finalize() in one static inner class which does get
instantiated *a lot*. It creates significant contention on synchroniz
Hello Peter
I created them a task: https://jira.spring.io/browse/SPR-15363
You don't suppose it would be worth trying to play with
RegisterFinalizersAtInit? Maybe
it could help for some reason if the registration was moved a bit earlier.
Milan Mimica, Senior Software Engineer / Division Lead
frankly I would migrate more from the normal reflection API to the
MethodHandles API instead of extending the Reflection API further, but I
see the use case and reasoning here. thanks.
bye Jochen
On 20.03.2017 10:04, Alan Bateman wrote:
On 19/03/2017 22:47, Jochen Theodorou wrote:
not want
Igor, let me capture our offline conversation.
The design you are suggesting is aimed to allow to chain methods which check
different outputs: stderr, stdout and other possible artifacts of a process
execution. To that end,
1. the method which you call stdout(Consumer) should really the
called
> On Mar 19, 2017, at 3:42 PM, Peter Levart wrote:
>
> Hi Alan,
>>
>> When integrating with the cache came up on jigsaw-dev a few work ago then I
>> think Mandy wanted to defer to it to JDK 10. However since canAccess is new
>> then having is be more efficient might be good, it just mightn't
> On Mar 20, 2017, at 2:58 AM, Peter Levart wrote:
>
>
>
> On 03/19/2017 11:42 PM, Peter Levart wrote:
>> No problem. Here it is (against tip of jake/jdk):
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.02/
>>
>>
>> This patch changes a little
> On Mar 20, 2017, at 5:15 AM, Daniel Fuchs wrote:
>
> Hi Peter,
>
> On 20/03/2017 12:01, Peter Levart wrote:
>> Perhaps the best way to rectify those problems in one place would be for
>> Reflection.getCallerClass() to return a special internal class in its
>> own package, such as:
>>
>> jdk.
> On Mar 20, 2017, at 2:19 AM, Claes Redestad wrote:
>
> Hi,
>
> please review this fix to avoid NPEs when calling certain Class methods via
> JNI:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177036
> Webrev: http://cr.openjdk.java.net/~redestad/8177036/jdk.01/
Looks okay. I agree t
> On Mar 20, 2017, at 6:37 AM, Peter Levart wrote:
>
> So the most productive way would be to ask Spring developers to remove
> finalization and instead employ their own PhantomReference based cleanup
> and/or adopt new JDK 9 Cleaner API when time comes…
+1 Moving away from using finalizers
On 20/03/2017 10:56 PM, Daniel Fuchs wrote:
On 20/03/2017 12:37, David Holmes wrote:
What about those API's says there has to be a Java frame higher up. Why
can't an attached thread request a reference to the logger?
Hi David,
Did you look at the webrev?
1582 * @throws IllegalCallerExce
As I'm discussing in the RFR for
"8177136: Caller sensitive methods Logger.getLogger,
Logger.getAnonymousLogger, and System.getLogger should throw
IllegalCallerException if there is no caller on the stack."
I am quite concerned by this, seemingly sudden, problem that we have a
whole bunch of
I saw the thread on JDK-8177136. I share your concern that throwing ICE does
not seem a good choice. I’ll reply on that thread. It seems to me that it
should default to the unnamed module if no caller frame rather than throwing an
exception.
For 8177036, no change in behavior. This actually
On 20/03/2017 20:22, David Holmes wrote:
I see this as a basic hole in the whole notion of "current module".
Surely if there is no module available then we should be in the
unnamed-module?
There isn't any notion of "current module". If there's no caller then
you can't make any assumptions as
Hi Daniel,
Have you considered default to the unnamed module when there is no caller frame
on the stack?
I don’t think we should make these APIs not callable from JNI attached thread
even though very rarely be called from JNI (not sure any report on the current
behavior throwing NPE).
Mandy
Hi Mandy
On 20/03/17 20:40, Mandy Chung wrote:
Hi Daniel,
Have you considered default to the unnamed module when there is no caller frame
on the stack?
I don’t think we should make these APIs not callable from JNI attached thread
even though very rarely be called from JNI (not sure any repor
On 21/03/2017 6:56 AM, Daniel Fuchs wrote:
Hi Mandy
On 20/03/17 20:40, Mandy Chung wrote:
Hi Daniel,
Have you considered default to the unnamed module when there is no
caller frame on the stack?
I don’t think we should make these APIs not callable from JNI attached
thread even though very rar
On 20/03/17 21:28, David Holmes wrote:
If you are going to introduce an API with such a constraint then the
constraint needs to be clearly documented and the alternatives also
documented IMHO. System.getLogger relies on a notion of "current module".
Yes:
Instances returned by this method r
Hi!
I came across an exception when running pack200 test PackTestZip64.java when I
use a non-bundled zlib library with JDK8. This causes the test to fail.
Upon examining the code, I believe the test fails incorrectly. The error is an
side-effect of how new JarEntry's are created.
Below is the de
Hi Dean,
Thanks for doing this.
Though as I suggested last time personally I prefer to make minimum
change to simply
seal those holes in ASB at this late stage of JDK9. I'm fine with the
webrev.2 and it looks
better and reasonable to pull all UTF16 operations into StringUTF16.java.
Just for
Hi Alan
I'm profiling the new FilePermission implementation and found a lot of
time spending on comparing a Path to a string, and the path has only one
element.
Here are them:
1. Comparing with "-":
Path lastName = npath.getFileName();
if (lastName != null && lastName.toString().equal
36 matches
Mail list logo
