On Wed, Jan 23, 2013 at 9:17 PM, Xueming Shen wrote:
> Hi Martin, sorry for the late response, was busy on other stuff these days.
Current deadline pressures are understood!
> I'm OK
> with the idea of introducing a system property to turn off zip64 support,
> but NOT
> by default. You can make
Changeset: b68ac92d0b2a
Author:alanb
Date: 2013-01-24 09:47 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b68ac92d0b2a
8006524: JSR-3: Allows java.beans to be optional
Reviewed-by: dfuchs, mchung
! src/share/classes/javax/management/MXBean.java
! src/share/classes/javax/man
Hello,
Recently I stumbled upon the scalability problem of
j.l.r.Proxy.isProxyClass(Class) method when trying to find-out why the
equals() method of annotations is not scalable. The reason is that
j.l.r.Proxy uses a single synchronized wrapper around WeakHashMap to
keep track of proxy classes
On 24/01/2013 13:49, Peter Levart wrote:
Should I file a RFE first?
Sorry I don't have time at the moment to study the proposed patch but
just to mention that it has come up a few times, its just that it never
bubbled up to the top of anyone's list. Here's the bug tracking it:
http://bugs.sun
On 01/24/2013 03:10 PM, Alan Bateman wrote:
On 24/01/2013 13:49, Peter Levart wrote:
Should I file a RFE first?
Sorry I don't have time at the moment to study the proposed patch but
just to mention that it has come up a few times, its just that it
never bubbled up to the top of anyone's list.
Peter,
I know this was brought up on your c-i mailing list thread, but it really
feels like a new boolean field in j.l.Class is the cleaner solution (and
infinitely scalable and doesn't require bookkeeping in the Proxy class).
Is there really no existing alignment gap in j.l.Class layout that a
bo
On 01/24/2013 03:40 PM, Vitaly Davidovich wrote:
Peter,
I know this was brought up on your c-i mailing list thread, but it
really feels like a new boolean field in j.l.Class is the cleaner
solution (and infinitely scalable and doesn't require bookkeeping in
the Proxy class). Is there really
The boolean seems better from an intent standpoint as well - all this wants
to do is tag a Class as having been internally generated by the proxy.
This information is present at the point of generation, obviously (and the
new. field can be marked final). Doing the tagging via indirection
(ClassVal
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
Hi,
Please review, this test needs to be disabled until Pack200/JSR-200 conforms
and adjusts to TypeAnnotations/JSR-308.
Thanks
Kumar
diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -321,6 +321,9 @@
tools/pack200/CommandLineTes
On 24/01/2013 16:07, Kumar Srinivasan wrote:
Hi,
Please review, this test needs to be disabled until Pack200/JSR-200
conforms
and adjusts to TypeAnnotations/JSR-308.
Looks fine to me.
-Alan
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/
>
On 01/24/2013 04:45 PM, Peter Levart wrote:
Is there really no existing alignment gap in j.l.Class layout that a
boolean can slide into?
There might be, I will check.
All instance fields in j.l.Class are either references or ints.
Regards, Peter
Changeset: 1fd613016ad9
Author:ksrini
Date: 2013-01-24 09:34 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fd613016ad9
8006850: [pack200] disable pack200 tests until JSR-308 is implemented
Reviewed-by: alanb
! test/ProblemList.txt
Changeset: b3f0e0c79bcc
Author:vinnie
Date: 2013-01-24 18:21 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3f0e0c79bcc
8006863: javadoc cleanup for 8005408
Reviewed-by: alanb
! src/share/classes/java/security/PKCS12Attribute.java
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 Method
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 a name of the form "argN", where N is the index of
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
>> syn
What was the disposition of the CCC request? 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
Joe, can you comment on this?
On 01/24/13 14:59, Coleen Phillimore wrote:
>
>
> What was the disposition of the CCC request? 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,
>
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 the disposition of the CCC request? Was it decided not to do
one because this function hasn't been used since b
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:
>>>
>>> W
Also, can someone more experienced in core-libs please confirm that it
has indeed not been used since that long ago (and perhaps more
importantly, that there are no current plans to use it)?
On 01/24/13 14:59, Coleen Phillimore wrote:
>
>
> What was the disposition of the CCC request? Was it d
If this function was only usable with the JDK implementation (an
internal JDK 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 y
I was trying to test the fixes for the langtools jtreg issue but when I
submitted my tl forest to JPRT the windows builds failed:
Packing
/cygdrive/c/jprt/T/P1/024730.daholme/s/build/windows-x86-normal-clientANDserver-release/install/j2re-image/lib/rt.jar
61395044 bytes
Exception in thread "m
As far as Coleen and I are aware, this is internal-only. If anyone
knows otherwise, please comment before the end of tomorrow.
Other than that, do you see any problems, Joe?
On 01/24/13 15:41, Joe Darcy wrote:
> If this function was only usable with the JDK implementation (an
> internal JDK cont
Changeset: 4d3c05cc21d5
Author:darcy
Date: 2013-01-24 16:54 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d3c05cc21d5
8006895: Clarify that FunctionalInferface is only informative
Reviewed-by: briangoetz
! src/share/classes/java/lang/FunctionalInterface.java
On 25/01/2013 2:36 AM, Peter Levart wrote:
On 01/24/2013 04:45 PM, Peter Levart wrote:
Is there really no existing alignment gap in j.l.Class layout that a
boolean can slide into?
There might be, I will check.
All instance fields in j.l.Class are either references or ints.
Instance are als
28 matches
Mail list logo
