On 24/06/2014 00:45, Coleen Phillimore wrote:
Please review a change to the JDK code for adding classLoader field to
the instances of java/lang/Class. This change restricts reflection
from changing access to the classLoader field. In the spec,
AccessibleObject.setAccessible() may throw
On 24/06/2014 01:14, huizhe wang wrote:
:
One thing that concerns me a bit is that none of the .java files that
I looked at have any comments to say what the test does. Is there
anything that could be brought over from the original issue in JIRA
to explain what each of these tests is
On Jun 24, 2014, at 2:42 AM, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
This changeset corrects a reported problem with the lists returned by
Collections.checkedList(). Since Java 8 the replaceAll() method on checked
lists has erroneously allowed the operator providing
Hi All,
I have a question about repeated annotation depth. If this is not the
proper mailing list group, please tell me where I should send it to.
My question will be about the depth of container annotations. For instance,
assume there are 3 annotations.
- RepeatedAnn
- ContainerAnn
-
On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
Please review a change to the JDK code for adding classLoader field to
the instances of java/lang/Class. This change restricts reflection
from changing access to the classLoader field. In the spec,
AccessibleObject.setAccessible() may throw
Hi Coleen,
It seems that there's still a reference to JVM_GetClassLoader
in file jdk/src/share/native/common/check_code.c. The code looks
like dead code, but it would be nice to clean it up.
Thanks,
Fred
On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
Please review a change to the JDK code
Looks good to me Mike.
I agree with Paul’s comment that the javadoc change will never be seen in the
public docs, but I still think it is a reasonable addition for future
maintainers.
Trivially, you should probably add @SuppressWarnings(unchecked”) to
typeCheck(Object).
-Chris.
On 24 Jun
Neil,
Some nits:
TestSpecialArgs.java:
extra space
105 for ( String line : tr.testOutput) {
This is very C'ish, I suggest.
-106 int index;
-107 if ((index = line.indexOf(envVarPidString)) = 0) {
+106 int index =
Hi Peter,
On 6/24/14, 4:23 AM, Peter Levart wrote:
On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
Please review a change to the JDK code for adding classLoader field
to the instances of java/lang/Class. This change restricts
reflection from changing access to the classLoader field. In
Fred,
Thank you for finding this. Yes, I meant to clean this up with the bug
to remove JVM_GetClassLoader but I should remove this with this change
instead, since the other change will be in hotspot only.
Yes, it's dead code.
Thanks!
Coleen
On 6/24/14, 4:41 AM, Frederic Parain wrote:
Hi
On Jun 17, 2014, at 6:52 PM, Joel Borggrén-Franck joel.fra...@oracle.com
wrote:
Hi,
Can I get a review for this fix and javadoc clarification for
https://bugs.openjdk.java.net/browse/JDK-8044629
The problem is with potentially annotated receiver parameters, they only
exist for inner
Hi Martin,
On 06/22/2014 07:12 PM, Martin Buchholz wrote:
We know that loading the networking machinery is problematic. On Linux we
would be content to hard-code a read from /dev/urandom, which is safer and
strictly more random than the existing network hardware determination, but
y'all will
On 6/24/14, 4:41 AM, Frederic Parain wrote:
Hi Coleen,
It seems that there's still a reference to JVM_GetClassLoader
in file jdk/src/share/native/common/check_code.c. The code looks
like dead code, but it would be nice to clean it up.
I removed this code. There are no other instances of the
On Jun 23, 2014, at 10:23 PM, Mandy Chung mandy.ch...@oracle.com wrote:
The loadLibrary implementation is missing to wrap the call
to File.getCanonicalPath method with doPrivileged block.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047904/webrev.00/
Looks ok to me.
Paul.
On 6/24/2014 12:19 AM, Alan Bateman wrote:
On 24/06/2014 01:14, huizhe wang wrote:
:
One thing that concerns me a bit is that none of the .java files
that I looked at have any comments to say what the test does. Is
there anything that could be brought over from the original issue in
JIRA
Daniel,
With regard to JDK-4420020, in the original webrev Jim was incorrectly using
java.io.File.canWrite() but that webrev was replaced by the current version.
The NIO.2 code performs the effective access checks correctly.
With regard to JDK-6244047 my concern was that checking the
Hi Jason,
Thanks for the feedback!
On 6/24/14 7:08 PM, Jason Mehrens wrote:
Daniel,
With regard to JDK-4420020, in the original webrev Jim was incorrectly using
java.io.File.canWrite() but that webrev was replaced by the current version.
The NIO.2 code performs the effective access checks
Will there be another ticket to update the section (9.6.4.7.) in JLS 9?
Cheers,
Paul
On Tue, Jun 24, 2014 at 12:27 PM, Lance Andersen lance.ander...@oracle.com
wrote:
+1
On Jun 24, 2014, at 1:13 PM, Joe Darcy joe.da...@oracle.com wrote:
Hello,
Please review the libraries update
On 06/24/2014 10:43 AM, Paul Benedict wrote:
Will there be another ticket to update the section (9.6.4.7.) in JLS 9?
JDK-8047159: 9.6.4.7: Allow @SafeVarargs on private methods
https://bugs.openjdk.java.net/browse/JDK-8047159
Cheers,
-Joe
Cheers,
Paul
On Tue, Jun 24, 2014 at
On Jun 24 2014, at 01:46 , Chris Hegarty chris.hega...@oracle.com wrote:
Looks good to me Mike.
I agree with Paul’s comment that the javadoc change will never be seen in the
public docs, but I still think it is a reasonable addition for future
maintainers.
Trivially, you should
Hello,
The behavior you're interested in is defined in the AnnotatedElement
specification:
http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html
In brief, none of the methods in AnnotatedElement look through more than
one level of containment. (Likewise, when
Hi,
As a follow up task, please review the trivial webrev to remove @version
tags used with SCM, which is likely to be meaningless to javadoc readers.
In this webrev, we only remove @version with $Id or $Revision for .jave
or package.html cause appearance to javadoc.
We keep those in
Looks good. Thanks for the extra work!
I think your webrev is here:
http://cr.openjdk.java.net/~henryjen/jdk9/8048021/0/webrev/
Cheers,
Joe
On 6/24/2014 1:00 PM, Henry Jen wrote:
Hi,
As a follow up task, please review the trivial webrev to remove
@version tags used with SCM, which is
23 matches
Mail list logo