Changeset: 4788eb38cac5
Author:emc
Date: 2013-11-11 09:47 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4788eb38cac5
8027439: Compile-time error in the case of ((Integer[] Serializable)new
Integer[1]).getClass()
8027253: javac illegally accepts array as bound
Hello,
Please review this trivial fix that adds @since documentation tags to
changes added in support of parameter reflection.
Webrev here:
http://cr.openjdk.java.net/~emc/8028021/
Thanks,
Eric
Changeset: ea91826bc2e9
Author:emc
Date: 2013-11-13 15:48 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea91826bc2e9
8026884: test for fix of JDK-8021398 does not have @bug tag
8028021: @since 1.8 missing for certain methods in java.lang.reflect.Method in
generated api
Changeset: 24eaf41a3974
Author:emc
Date: 2013-11-14 12:32 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/24eaf41a3974
8028282: Remove @ignore from test langtools/test/tools/javac/T7042623.java
Summary: Remove @ignore from test
Reviewed-by: jjg
!
Changeset: 9e91793fd516
Author:vlivanov
Date: 2014-01-15 20:48 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e91793fd516
8031502: JSR292: IncompatibleClassChangeError in LambdaForm for
CharSequence.toString() method handle type converter
Reviewed-by: sundar, lagergren,
Changeset: 56d05f260123
Author:vlivanov
Date: 2014-01-28 13:46 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56d05f260123
8032585: JSR292: IllegalAccessError when attempting to invoke protected method
from different package
Reviewed-by: twisti, jrose
!
Changeset: 11b83c913cca
Author:attila
Date: 2014-01-30 20:14 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/11b83c913cca
8032681: Issues with Nashorn
Reviewed-by: ahgross, jlaskey, sundar
+ src/jdk/internal/dynalink/linker/GuardedTypeConversion.java
!
Changeset: f684c9773858
Author:vlivanov
Date: 2014-01-31 21:07 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f684c9773858
8033278: Missed access checks for Lookup.unreflect* after 8032585
Reviewed-by: jrose, twisti
! src/share/classes/sun/invoke/util/VerifyAccess.java
!
I've been doing some upgrades on servers I run at home recently. One of
the upgrades I'd planned was to increase the key size of my internal CA
key and SSL keys to 8192 bits as a future-proofing measure (I use SSL
with client certificates for all service-to-service communication).
What I found
I am currently seeing build failures on solaris, coming from within the
JDK repo:
/opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING
-DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS
-DARCH='sparcv9' -Dsparcv9 -DNDEBUG -DTRIMMED
-DRELEASE='1.9.0-internal'
in the attach framework
On 05/09/14 14:08, Eric McCorkle wrote:
I am currently seeing build failures on solaris, coming from within the
JDK repo:
/opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING
-DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS
-DARCH='sparcv9' -Dsparcv9 -DNDEBUG
blocking this week hotspot snapshot:
http://prt-web.us.oracle.com//archive/2014/05/2014-05-09-174238.amurillo.jdk9-hs-2014-05-09-jdk9-dev-control/logs/solaris_sparcv9_5.10-fastdebug.log.FAILED.log
please fix ASAP
Thanks
Alejandro
On 5/9/2014 12:16 PM, Eric McCorkle wrote:
Bug created: https
, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
On 05/09/14 15:01, Eric McCorkle wrote:
The problem is a stray '' as the first two characters in the file.
I have posted a patch that removes it to serviceability-dev
Pushed. You may now resume normal integration activities.
On 05/09/14 15:12, Staffan Larsen wrote:
Looks good.
Many apologies.
/Staffan
On 9 maj 2014, at 21:08, Eric McCorkle eric.mccor...@oracle.com wrote:
The following patch will fix it:
diff -r 7426549b1e3b
src/solaris
Hello,
Please review the implementation of the core reflection API for method
parameter reflection. This changeset introduces a new class, Parameter,
which represents information about method parameters. It introduces a
new method into Executable which returns an array of the parameters for
the
It looks like its just generating a unique random seed for each HashMap. It
seems like that could be made thread-local.
On Dec 27, 2012, at 2:16 PM, Zhong Yu zhong.j...@gmail.com wrote:
Reported by the SO question
http://stackoverflow.com/questions/14010906
the HashMap constructor
Was the original purpose security-oriented? It seemed to me that the purpose
was to make performance pathologies less likely.
Consider, for example, a bad hash function that maps ip addresses directly to
their integer representation. If an application puts entire subnets into a
map. All the
Hello,
Please review the core reflection API implementation of parameter
reflection. This is the final component of method parameter reflection.
This was posted for review before, then delayed until the check-in for
JDK-8004728 (hotspot support for parameter reflection), which occurred
...
You should also retrieve the referent and check for it's presence before
returning it:
Parameter[] res;
if (parameters != null (res = parameters.get()) != null)
return res;
...
...
Regards, Peter
On 01/09/2013 10:55 PM, Eric McCorkle wrote:
Hello,
Please review the core
(you need
a local variable to hold intermediate states)...
Regards, Peter
On 01/10/2013 09:42 PM, Eric McCorkle wrote:
Thanks to all for initial reviews; however, it appears that the version
you saw was somewhat stale. I've applied your comments (and some
changes that I'd made since
The webrev has been refreshed with the solution I describe below
implemented. Please make additional comments.
On 01/10/13 17:29, Eric McCorkle wrote:
Good catch there. I made the field volatile, and I also did the same
with the cache fields in Parameter.
It is possible with what exists
, it should probably be reduced to a single write, for
performance reasons (to avoid unnecessary memory barriers). Therefore,
I changed it.
However, I won't be able to refresh the webrev until tomorrow.
Thanks
Sent from my phone
On Jan 10, 2013 6:05 PM, Eric McCorkle eric.mccor...@oracle.com
seeing that for some time now).
On 01/10/13 21:47, Eric McCorkle wrote:
On 01/10/13 19:50, Vitaly Davidovich wrote:
Hi Eric,
Parameter.equals() doesn't need null check - instanceof covers that already.
Removed.
Maybe this has been mentioned already, but personally I'm not a fan of
null
Update should be visible now.
On 01/11/13 11:54, Vitaly Davidovich wrote:
Yes that's exactly what I'm looking for as well.
Sent from my phone
On Jan 11, 2013 11:25 AM, Peter Levart peter.lev...@gmail.com
mailto:peter.lev...@gmail.com wrote:
On 01/11/2013 04:54 PM, Eric McCorkle
with the
*second* parameter since the first class file parameter is a synthesized
constructor added by the compiler. I think generally annotations should
not be associated with synthesized or synthetic parameters.
-Joe
On 1/11/2013 9:03 AM, Eric McCorkle wrote:
Update should be visible now
On 01/12/13 13:36, Joe Darcy wrote:
Hi Eric,
On 1/11/2013 9:14 PM, Eric McCorkle wrote:
I got halfway through implementing a change that would synthesize
Parameter's for the static links (this for the inner classes), when it
occurred to me: is there really a case for allowing reflection
, the annotation should be associated with the
*second* parameter since the first class file parameter is a synthesized
constructor added by the compiler. I think generally annotations should
not be associated with synthesized or synthetic parameters.
-Joe
On 1/11/2013 9:03 AM, Eric McCorkle
Are there any additional comments? I'd like to get this pushed today.
On 01/17/13 16:54, Eric McCorkle wrote:
After (lengthy) examination, it seems that properly addressing the
synthesized parameters issue will require more changes to javac. In
light of this, I think that the synthesized
.
Extra space:
316
317 parameters = tmp;
318
319 }
Fixed.
Parameter.java
41 * @author Eric McCorkle
We generally don't use author tags in new code under /src.
Removed
For consistency with existing code
(http://hg.openjdk.java.net/jdk8/tl/jdk/rev
I'm not a committer, so I need someone to push this changeset for me.
Thanks,
Eric
:16, Eric McCorkle wrote:
I'm not a committer, so I need someone to push this changeset for me.
Thanks,
Eric
I'm not volunteering (sorry) but just checking that the HotSpot changes
are in jdk8/tl/hotspot already? I think they are, but just doubling
checking to avoid problems if someone pushes
Hello,
Please review this trivial patch which removes JVM_PrintStackTrace from
jvm.h. It is no longer being used.
The webrev is here:
http://cr.openjdk.java.net/~emc/8006503/webrev.00/
The bug is here:
http://bugs.sun.com/view_bug.do?bug_id=8006503
Thanks,
Eric
Forgot to put the bug's title in the subject line...
On 01/24/13 10:59, Eric McCorkle wrote:
Hello,
Please review this trivial patch which removes JVM_PrintStackTrace from
jvm.h. It is no longer being used.
The webrev is here:
http://cr.openjdk.java.net/~emc/8006503/webrev.00
The current version of the spec for parameter reflection, found here:
http://cr.openjdk.java.net/~abuckley/8misc.pdf
states that if a parameter has no name, then the reflection API should
synthesize a name of the form argN, where N is the index of the
parameter. It also states that if a
On 01/24/13 14:40, Jonathan Gibbons wrote:
On 01/24/2013 11:33 AM, Eric McCorkle wrote:
The current version of the spec for parameter reflection, found here:
http://cr.openjdk.java.net/~abuckley/8misc.pdf
states that if a parameter has no name, then the reflection API should
synthesize
On 01/24/2013 10:59 AM, Eric McCorkle wrote:
Hello,
Please review this trivial patch which removes JVM_PrintStackTrace from
jvm.h. It is no longer being used.
The webrev is here:
http://cr.openjdk.java.net/~emc/8006503/webrev.00/
The bug is here:
http://bugs.sun.com/view_bug.do?bug_id
I think the question was more of does one need to be filed?
On 01/24/13 15:15, Joe Darcy wrote:
There is as of yet no ccc request for 8006503.
-Joe
On 1/24/2013 12:11 PM, Eric McCorkle wrote:
Joe, can you comment on this?
On 01/24/13 14:59, Coleen Phillimore wrote:
What
? Was it decided not to do
one because this function hasn't been used since before 1.4?
Code looks good to me. I removed the one in hotspot last week.
Thanks,
Coleen
On 01/24/2013 10:59 AM, Eric McCorkle wrote:
Hello,
Please review this trivial patch which removes JVM_PrintStackTrace from
jvm.h
contract), then a ccc request is not needed.
HTH,
-Joe
On 1/24/2013 12:26 PM, Eric McCorkle wrote:
I think the question was more of does one need to be filed?
On 01/24/13 15:15, Joe Darcy wrote:
There is as of yet no ccc request for 8006503.
-Joe
On 1/24/2013 12:11 PM, Eric McCorkle
Thanks for the input, everyone.
I take it this is ok to push, then?
On 01/25/13 06:22, Alan Bateman wrote:
On 24/01/2013 20:29, Eric McCorkle wrote:
Also, can someone more experienced in core-libs please confirm that it
has indeed not been used since that long ago (and perhaps more
I don't think anyone is using MethodParameters at this point, but I want
to post this just to be sure.
The latest version of the spec alters the class file format of
MethodParameters attributes.
The latest version can be found here:
http://cr.openjdk.java.net/~abuckley/8misc.pdf
I will be
On 01/26/13 02:52, David Holmes wrote:
There must already be tests for this new feature else you would be
pushing untested code, so you would break these tests while your changes
sync up.
Tests do exist, but they are presently disabled. The end-to-end tests
were part of JDK-8004729, which
I'm not a reviewer, but I did write the original test. The annotations
method is preferable, so I give a thumbs up to this change.
On 01/30/13 14:56, Joe Darcy wrote:
Hello,
Please review my refactoring of a regression test for the
java.lang.reflect.Parameter feature:
8007115:
Hello,
Please review this trivial patch which removes uses of _ as an
identifier in the jaxp API.
The webrev is here:
http://cr.openjdk.java.net/~emc/8007389/
The bug should be here, but does not seem to be showing up yet:
http://bugs.sun.com/view_bug.do?bug_id=8007389
Thanks. Do I have a second?
On 02/01/13 12:04, Lance Andersen - Oracle wrote:
Its OK.
Not sure I would have replaced it with 'unused' but not a big deal as it is
just a personal preference.
On Feb 1, 2013, at 11:45 AM, Eric McCorkle wrote:
Hello,
Please review this trivial patch
Thanks for the reviews everybody!
On 02/04/13 14:02, Joe Wang wrote:
Hi Eric,
The change is fine. Thanks for taking on fixing this!
Joe
On 2/1/2013 3:19 PM, Eric McCorkle wrote:
Thanks. Do I have a second?
On 02/01/13 12:04, Lance Andersen - Oracle wrote:
Its OK.
Not sure I would
Clarification here: the issue's title is a bit more narrow than the
scope of the fix. It addresses some javadoc comments and handling of
nameless parameters as well.
On 02/05/13 14:58, Eric McCorkle wrote:
Hello, please review this patch, which implements some spec changes for
parameter
Any other comments on this one, or is it good to go?
On 02/15/13 16:48, Joe Darcy wrote:
Hi Eric,
I'll approve this change as-is, but I'd prefer if the test were written
in the style of using annotations to record the expected value.
Cheers,
-Joe
On 2/15/2013 12:23 PM, Eric McCorkle
Hello,
Please review this simple change, which corrects some errors in the
javadoc comments for method parameter reflection.
Note that this changeset does not include any code changes.
The webrev is here:
http://cr.openjdk.java.net/~emc/8012937/webrev.00/
Also, if you have any additional
I have posted a newer version with some more edits. Please review and
suggest any further changes.
http://cr.openjdk.java.net/~emc/8012937/webrev.01/
On 04/22/13 12:10, Eric McCorkle wrote:
Hello,
Please review this simple change, which corrects some errors in the
javadoc comments
explicitly nor implicitly declared?
I still think the follow comment is better deleted given the source that
follows it:
157 // If a parameter has no name, return argX, where x is the
158 // index.
159 //
-Joe
On 4/22/2013 11:46 AM, Eric McCorkle wrote:
I
Any further comments, or is this one good to go?
On 04/23/13 19:54, Joseph Darcy wrote:
Acknowledged; thanks for checking,
-Joe
On 4/23/2013 7:46 AM, Eric McCorkle wrote:
I believe so. Alex Buckley recommended the exact wording.
On 04/22/13 22:09, Joseph Darcy wrote:
Hello,
240
Changeset: ca0957f0d408
Author:emc
Date: 2013-04-25 14:23 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca0957f0d408
8012937: Correct errors in javadoc comments.
Summary: Correct some errors in the javadoc comments for parameter reflection.
Reviewed-by: darcy
!
Hello,
Please review this simple patch which fixes an issue with several of the
shell script tests, namely that they do not start with #!/bin/sh
The webrev is here:
http://cr.openjdk.java.net/~emc/8014834/
The bug is here:
http://bugs.sun.com/view_bug.do?bug_id=8014834
Thanks,
Eric
Thanks, Kumar. Do I have a second?
Note: JPRT has been unreliable lately, so it may be a while before I can
put this in.
On 05/30/13 17:45, Kumar Srinivasan wrote:
Hi Erik,
This looks good, historically the #!shell was inserted after the
CopyRight,
because it was thought that the
Changeset: 3d4d7ed93731
Author:emc
Date: 2013-06-03 10:44 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3d4d7ed93731
8014834: shell tests don't begin with #!/bin/sh
Summary: Some shell tests don't begin with the command interpreter line
Reviewed-by: alanb, ksrini
!
Thanks all, putting the changes in.
On 06/03/13 06:07, Alan Bateman wrote:
On 01/06/2013 13:32, Eric McCorkle wrote:
Thanks, Kumar. Do I have a second?
For the jdk repository then only one reviewer is required although in
specialized or complicated areas then having a reviewer that knows
Changeset: 8717586f7b05
Author:emc
Date: 2013-06-06 08:48 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8717586f7b05
8015701: MethodParameters are not filled in for synthetic captured local
variables
Summary: Synthetic parameters for captured local variables in an
Hello,
Please review this simple patch that removes setProtectionDomain0 from
java.lang.Class. This is part of a two-stage process to remove the
function from the JVM as well.
This method is not used, and has not been used in some time (at least
before 1.5)
The webrev is here:
Changeset: 37aa82c52317
Author:emc
Date: 2013-06-06 09:51 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37aa82c52317
8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK
Summary: setProtectionDomain0 and JVM_SetProtectionDomain are unused since at
least
Thanks, Alan.
On 06/06/13 09:22, Alan Bateman wrote:
On 06/06/2013 14:07, Eric McCorkle wrote:
Hello,
Please review this simple patch that removes setProtectionDomain0 from
java.lang.Class. This is part of a two-stage process to remove the
function from the JVM as well.
This method
Hello, please review this patch which adds isNamePresent to the
java.lang.reflect.Parameter API.
The webrev is here:
http://cr.openjdk.java.net/~emc/8016285/
The change request is here:
http://bugs.sun.com/view_bug.do?bug_id=8016285
The updated spec is here:
On 06/21/13 16:15, Aleksey Shipilev wrote:
On 06/21/2013 11:57 PM, Eric McCorkle wrote:
The webrev is here:
http://cr.openjdk.java.net/~emc/8016285/
Looks generally good (but not a Reviewer).
A few questions though:
a) Are we em-bracing the brace-less control flow blocks?
Fixed
Changeset: bf020de5a6db
Author:emc
Date: 2013-06-24 22:03 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf020de5a6db
8012722: Single comma in array initializer should parse
Summary: Annotations of the form @Foo({,}) should parse
Reviewed-by: jjg
!
Hello,
Please review this simple patch which updates regression test
langtools/tools/javac/T6725036.java to offset the time returned by
JavaFileObject.getLastModified() with the local time to UTC delta.
Please note that this patch is intended to address the test failures,
and that I will be
entry, if
presents.
The API doc will be updated accordingly as well to explicitly explain
the source of the
date/time and the its timezone sensitive conversion.
-Sherman
On 06/25/2013 07:03 AM, Eric McCorkle wrote:
Hello,
Please review this simple patch which updates regression test
, if there is no objection.
-Sherman
On 06/25/2013 12:27 PM, Eric McCorkle wrote:
Does the fix for 8015666 stop the error from happening? If so, then
I'll withdraw this RFR.
On 06/25/13 13:50, Xueming Shen wrote:
This is fine to be a workaround for the test case for now. It probably
will need
use 8016760 to add the test to the ProblemList.txt. It can
then be removed along with the other changes for 8015666.
-Chris.
-Sherman
On 06/25/2013 12:27 PM, Eric McCorkle wrote:
Does the fix for 8015666 stop the error from happening? If so, then
I'll withdraw this RFR.
On 06/25/13 13
Can I get a capital-R review on this so I can put it through?
On 06/24/13 17:28, Aleksey Shipilev wrote:
Forgot to reply: I'm ok with webrev.01.
-Aleksey
(rural r reviewer)
On 06/24/2013 11:20 PM, Eric McCorkle wrote:
Pinging this RFR. It still needs a capital R reviewer.
http
Changeset: c674b396827c
Author:emc
Date: 2013-06-27 00:37 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c674b396827c
8014230: Compilation incorrectly succeeds with inner class constructor with 254
parameters
Summary: The compiler does not account fr extra parameters
Accidentally dropped core-libs-dev from the reply.
On 06/27/13 13:31, Eric McCorkle wrote:
I could easily replace the patch I have now with one that just marks the
test @ignore and commit it. Do we want to go ahead and approve that?
On 06/27/13 13:12, Jonathan Gibbons wrote:
Yes, I think
/2013 10:31 AM, Eric McCorkle wrote:
I could easily replace the patch I have now with one that just marks the
test @ignore and commit it. Do we want to go ahead and approve that?
On 06/27/13 13:12, Jonathan Gibbons wrote:
Yes, I think that this is the correct approach.
-- Jon
On 06/27/2013 09
Changeset: 5c548a8542b8
Author:emc
Date: 2013-06-27 17:45 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5c548a8542b8
8013357: javac accepts erroneous binary comparison operations
Summary: javac does not report type errors on illegal Object == primitive
comparisons
Changeset: 6101e52ce9e3
Author:emc
Date: 2013-06-28 06:54 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6101e52ce9e3
8016760: Failure of regression test langtools/tools/javac/T6725036.java
Summary: Marking the failing test @ignore; the proposed change for 8015666
Pinging this one again...
On 06/24/13 15:20, Eric McCorkle wrote:
Pinging this RFR. It still needs a capital R reviewer.
http://cr.openjdk.java.net/~emc/8016285/
On 06/21/13 19:21, Eric McCorkle wrote:
On 06/21/13 16:15, Aleksey Shipilev wrote:
On 06/21/2013 11:57 PM, Eric McCorkle wrote
Changeset: a8f51c3341a5
Author:emc
Date: 2013-07-03 19:47 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8f51c3341a5
8016285: Add java.lang.reflect.Parameter.isNamePresent()
Summary: Add isNamePresent method to parameter reflection library, which
indicates whether or real
Changeset: 558fe98d1ac0
Author:emc
Date: 2013-07-23 20:42 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/558fe98d1ac0
8016880: 42 tests in annot102* fail with compile-time errors.
Summary: Fixes error in type equality when bounds of type variables have
annotations.
Changeset: 2068190f8ac2
Author:emc
Date: 2013-08-21 20:23 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2068190f8ac2
7118412: Shadowing of type-variables vs. member types
4987840: What is the scope of an annotation?
Summary: Fixed issue with shadowing of type names.
Changeset: eebb29618f50
Author:emc
Date: 2013-08-21 20:41 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/eebb29618f50
8023520: Add missing test for JDK-7118412
Summary: The test for JDK-7118412 was dropped from the changeset in a merging
accident.
Reviewed-by: jjg
+
Changeset: 1ab22e60a738
Author:emc
Date: 2013-08-22 12:47 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1ab22e60a738
8020745: Suspicious MethodParameters attribute generated for local classes
capturing local variables
Summary: Corrected an error in a previous patch
Changeset: 67c5110c60fe
Author:emc
Date: 2013-09-09 17:11 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/67c5110c60fe
8015322: Javac template test framework
Summary: Putback of the javac template test framework from the Lambda repository
Reviewed-by: jjg
Changeset: f4efd6ef6e80
Author:emc
Date: 2013-09-09 16:26 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f4efd6ef6e80
8022322: Reject default and static methods in annotation
Summary: Causes javac to reject static and default method declarations inside
an annotation
Hello,
Please review this patch which updates the javadoc comments for
java.lang.reflect.Executable.getParameterAnnotations(). The patch
corrects the javadocs to describe the actual behavior of this method.
It also refers users to the new java.lang.reflect.Parameter API.
See comments on the bug
A new webrev has been posted, with some improvements to the comment.
On 09/09/13 17:41, Eric McCorkle wrote:
Hello,
Please review this patch which updates the javadoc comments for
java.lang.reflect.Executable.getParameterAnnotations(). The patch
corrects the javadocs to describe the actual
Changeset: 65c218b25b61
Author:emc
Date: 2013-09-11 08:30 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/65c218b25b61
8024510: lib/combo/tools/javac/combo/TemplateTest.java fails
Summary: Edit regex in Template to allow MAJOR. pattern.
Reviewed-by: briangoetz
!
Changeset: c3ef78cd9081
Author:emc
Date: 2013-09-11 09:24 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3ef78cd9081
6962494: Update documentation on Executable.getParameterAnnotations()
Summary: Update javadoc comments on getParameterAnnotations to correctly
describe its
Changeset: 5d2d484a1216
Author:emc
Date: 2013-09-12 14:52 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5d2d484a1216
8013846: javac fails to reject semantically equivalent generic method
declarations
Summary: Cause javac to consider intersection types with the same
Hello,
Please review this patch, which implements correct behavior for the
Parameter Reflection API in the case of malformed class files.
The bug report is here:
https://bugs.openjdk.java.net/browse/JDK-8020981
The webrev is here:
http://cr.openjdk.java.net/~emc/8020981/
This review is also on
A new webrev is posted (and crucible updated), which actually validates
parameter names correctly. Apologies for the last one.
On 09/12/13 16:02, Eric McCorkle wrote:
Hello,
Please review this patch, which implements correct behavior for the
Parameter Reflection API in the case of malformed
.
cheers
/Joel
On Sep 13, 2013, at 3:40 PM, Eric McCorkle eric.mccor...@oracle.com wrote:
A new webrev is posted (and crucible updated), which actually validates
parameter names correctly. Apologies for the last one.
On 09/12/13 16:02, Eric McCorkle wrote:
Hello,
Please review this patch
, 2013, at 4:49 PM, Eric McCorkle eric.mccor...@oracle.com wrote:
There is no simple means of generating bad class files for testing.
This is a huge deficiency in our testing abilities.
If these class files shouldn't go in, then I'm left with no choice but
to check in no test for this patch
inside a custom
ClassLoader...
To hacky? Dependent on future changes of javac? At least the bad name
patching could be performed trivially and reliably, I think: search and
replace with same-length string.
Regards, Peter
On 09/13/2013 07:35 PM, Eric McCorkle wrote:
Ugh. Byte arrays
On 09/13/13 09:53, Paul Benedict wrote:
MalformedParametersException should receive a @since tag.
Additionally, the javadoc doesn't describe what it means for a parameter to
be malformed. The answer doesn't need to be exhaustive, but I think some
examples would help developers if they catch
:
To avoid storing binaries in Hg, you could try something like:
* uuencode / ascii armor the class file
* convert to byte array in the test
* load classes from byte array
-Joe
On 09/13/2013 11:54 AM, Eric McCorkle wrote:
I did it by hand with emacs.
I would really rather tackle
This still needs to be reviewed.
On 09/16/13 14:50, Eric McCorkle wrote:
I pulled the class files into byte array constants, as a temporary
measure until a viable method for testing bad class files is developed.
The webrev has been refreshed. The class files will be taken out before
I push
The webrev has been updated with Joe's comments addressed.
On 09/19/13 00:11, David Holmes wrote:
On 19/09/2013 9:59 AM, Eric McCorkle wrote:
This still needs to be reviewed.
You seem to have ignored Joe's comments regarding the change to Modifier
being incorrect.
David
On 09/16/13 14
Changeset: 09301757bb32
Author:emc
Date: 2013-09-23 15:37 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09301757bb32
6499673: Assertion check for TypeVariable.getUpperBound() fails.
Summary: Fix TypeVariable.getUpperBound to return results as specified
Reviewed-by:
Updated webrev here:
http://cr.openjdk.java.net/~emc/8020981/
Are there any more comments, or is this good to go?
On 09/19/13 18:15, Eric McCorkle wrote:
The webrev has been updated with Joe's comments addressed.
On 09/19/13 00:11, David Holmes wrote:
On 19/09/2013 9:59 AM, Eric McCorkle
verifying function that throws IAE if given a bad index.
On 2013-09-19, Eric McCorkle wrote:
The webrev has been updated with Joe's comments addressed.
On 09/19/13 00:11, David Holmes wrote:
On 19/09/2013 9:59 AM, Eric McCorkle wrote:
This still needs to be reviewed.
You seem to have ignored Joe's
The enhanced metadata spec says nothing at all about an IAE. That is an
implementation detail, possibly subject to change at any point, and it
*should* not be leaked.
On 09/24/13 17:28, Paul Benedict wrote:
Eric,
Should MalformedParametersException save IAE as the root cause? Or is that
an
1 - 100 of 130 matches
Mail list logo
