On 9/15/16 19:13, David Holmes wrote:
On 16/09/2016 8:52 AM, serguei.spit...@oracle.com wrote:
Hi Harold,
I did not got deep into the fix yet but wonder why the JVMTI function is
My copy-paste failed.
I wanted to list the JVMTI function name: GetMethodDeclaringClass.
Thanks,
Serguei
not
On 16/09/2016 8:52 AM, serguei.spit...@oracle.com wrote:
Hi Harold,
I did not got deep into the fix yet but wonder why the JVMTI function is
not used.
I was wondering a similar thing. It seems very heavyweight to use Java
level reflection from inside native code to validate the native
Hi Harold,
I did not got deep into the fix yet but wonder why the JVMTI function is
not used.
Thanks,
Serguei
On 9/15/16 13:05, harold seigel wrote:
Hi Dan,
One could argue that a spec compliant JNI implementation wouldn't need
this change in the first place...
Regardless, I'm
On 9/15/16 2:05 PM, harold seigel wrote:
Hi Dan,
One could argue that a spec compliant JNI implementation wouldn't need
this change in the first place...
That's a completely different discussion. And we don't want to go down
that rat hole again... :-)
Regardless, I'm withdrawing this
Hi Dan,
One could argue that a spec compliant JNI implementation wouldn't need
this change in the first place...
Regardless, I'm withdrawing this change because I found that it fails a
com/sun/jdi JTreg test involving static methods in interfaces.
Thanks, Harold
On 9/15/2016 3:37 PM,
On 9/15/16 12:10 PM, harold seigel wrote:
(Adding hotspot-runtime)
Hi Dan,
Thanks for looking at this.
I could pass NULL instead of clazz to ToReflectMethod() to ensure that
the method object isn't being obtained from clazz.
I don't think that would be a JNI spec compliant use of the
JNI
(Adding hotspot-runtime)
Hi Dan,
Thanks for looking at this.
I could pass NULL instead of clazz to ToReflectMethod() to ensure that
the method object isn't being obtained from clazz.
Harold
On 9/15/2016 1:09 PM, Daniel D. Daugherty wrote:
On 9/15/16 9:31 AM, harold seigel wrote:
Hi,
On 9/15/16 9:31 AM, harold seigel wrote:
Hi,
Please review this small fix for JDK-8160987. The JDWP InvokeStatic()
method was depending on the JNI function that it called to enforce the
requirement that the specified method must be a member of the
specified class or one of its super
Dmitry,
I'd reproduced it. I'll check what is happening.
-Dmitry
On 2016-09-15 15:34, Dmitry Dmitriev wrote:
> Hi Dmitry,
>
> I don't think that this solves the problem. If some test build
> testlibrary before TestJpsJar.java, then testlibrary classes will be
> outside the folder with
Hi,
Please review this small fix for JDK-8160987. The JDWP InvokeStatic()
method was depending on the JNI function that it called to enforce the
requirement that the specified method must be a member of the specified
class or one of its super classes. But, JNI does not enforce this
On 9/15/16 8:18 AM, Severin Gehwolf wrote:
On Thu, 2016-09-15 at 08:15 -0600, Daniel D. Daugherty wrote:
Dmitry,
This fix needs to be run through the entire JPDA test stack
before it is pushed. Don't know if we still have test definitions
to support that style of run anymore so it might be
On Thu, 2016-09-15 at 08:15 -0600, Daniel D. Daugherty wrote:
> Dmitry,
>
> This fix needs to be run through the entire JPDA test stack
> before it is pushed. Don't know if we still have test definitions
> to support that style of run anymore so it might be easier to
> run it through the
Dmitry,
This fix needs to be run through the entire JPDA test stack
before it is pushed. Don't know if we still have test definitions
to support that style of run anymore so it might be easier to
run it through the equivalent of a JDK9-hs nightly.
Dan
On 9/14/16 11:50 AM, Dmitry Samersoff
Hi Dmitry,
I wonder whether failures can be caused by adding
the classes in the wrong order...
If you have -cp a:b:c - the class loader will look
at a first, then b, then c.
But if you create a jar and adds a first, b second, and
c last, then it's equivalent to -cp c:b:a
Could there be an
Hi Dmitry,
I don't think that this solves the problem. If some test build
testlibrary before TestJpsJar.java, then testlibrary classes will be
outside the folder with JpsHelper class and thus missed in the jar file.
I can reproduce this problem with your patch applied:
1) Run
Everybody,
Please, review the small fix.
http://cr.openjdk.java.net/~dsamersoff/JDK-8165500/webrev.01/
The problem:
TestJpsJar attempts to copy all directories found in test.class.path
into a single jar file.
It's not necessary and could lead to intermittent ClassNotFound exceptions.
+1
PS.
* SA module does not export any package - as of now, only jhsdb is the
only way to use SA. So, most findbugs findings are noise. i.e., user
code or any code outside SA module cannot access SA programmatically.
Only way is to use command line switches of Java launcher - if untrusted
code
Sharath,
I don't see any requirements that ObjectReader should run with an
application that install security manager but doesn't have
RuntimePermission.createClassLoader
So I would recommend to close this bug as "not an issue".
-Dmitry
On 2016-09-15 06:38, Harsha wardhana B wrote:
> Hello,
>
Hello,
It is not required that SA should be run under security manager to
address this change. Any standalone application when run under security
manager can use ObjectReader class to exploit vulnerabilities. That is
something that should be evaluated.
With the below fix any application
Hi Serguei,
On Wed, 2016-09-14 at 11:44 -0700, serguei.spit...@oracle.com wrote:
> Hi Severin,
>
> The fix looks good.
> Thank you for persistence in fixing the issue!
Thanks for the review!
> The only suggestion is to refactor the lines 800-815 into a method call.
> Something like
On Wed, 2016-09-14 at 20:50 +0300, Dmitry Samersoff wrote:
> Severin,
>
> The fix looks good for me.
>
> I'll sponsor the push, but please wait for Serguei.
Thanks, Dmitry.
Cheers,
Severin
> -Dmitry
>
>
> On 2016-09-09 19:27, Severin Gehwolf wrote:
> >
> > Hi,
> >
> > Could I please get a
21 matches
Mail list logo
