I guess we agree that the only use of serialVersionUID would be to remove the
warning, as it's not useful for serialization compatibility. Wouldn't it be
better just to suppress the warning instead?
Regarding the "throw syntaxError()" change, yes that would be a bit too much of
a refactoring to pe
Whoops, good catch. Those changes are indeed not permitted. We'll have to use
@SuppressWarnings("rawtypes") or some such instead.
s'marks
On 12/4/11 6:04 PM, David Holmes wrote:
Are the signature changes in
src/share/classes/java/lang/EnumConstantNotPresentException.java
permitted?
Otherwis
On 12/4/11 7:10 PM, David Schlosnagle wrote:
On Dec 4, 2011, at 7:17 PM, Stuart Marks wrote:
I've been mulling over what to do with these two patches for the past couple days.
Initially I was thinking of merging the patches and generating a new one combining the
best of both. But after I loo
Hi,
Mike, Stuart, Alan, and Masayoshi:
Thank you for your comments.
If no one has any objections, I'd like to fix only
> - The parens are probably not needed around 'length=(srcIndex-prevSrc);'
pointed out by Mike.
Both the serialVersionUID of AttributedCharacterIterator.Attribute and breaks
On Dec 4, 2011, at 7:17 PM, Stuart Marks wrote:
> I've been mulling over what to do with these two patches for the past couple
> days. Initially I was thinking of merging the patches and generating a new
> one combining the best of both. But after I looked over both of them, I felt
> that we s
Thanks Chris and Doug et al. These fixups look good to me too.
One minor nit:
src/share/classes/java/util/concurrent/atomic/AtomicLong.java
The javadoc changes on longValue() changed actual text not just
formatting. It changes it to be consistent with other methods, but is a
change none-the-l
Hi Brandon,
On 3/12/2011 9:59 AM, Brandon Passanisi wrote:
Hello core-libs-dev. I was wondering if somebody could review the
following proposed fix and test case for bug #5063455. Here's the info:
Bug URL: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5063455
Webrev: http://cr.openjdk.java
On 5/12/2011 11:03 AM, Rémi Forax wrote:
On 12/05/2011 01:27 AM, Joe Darcy wrote:
On 12/4/2011 2:13 PM, Rémi Forax wrote:
On 12/04/2011 08:38 PM, Joe Darcy wrote:
Are there alternatives to adding two new fields to java.lang.Class?
I assume most Class'es won't have ClassValue information assoc
Changeset: 2ae848ea980a
Author:weijun
Date: 2011-12-05 10:19 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ae848ea980a
7116857: Warnings in javax.security and some sun.misc
Reviewed-by: smarks
! src/share/classes/javax/security/auth/kerberos/ServicePermission.java
! src/sh
Are the signature changes in
src/share/classes/java/lang/EnumConstantNotPresentException.java
permitted?
Otherwise looks okay to me.
David
On 5/12/2011 11:02 AM, Stuart Marks wrote:
Please review the following webrev submitted by Omair Majid, consisting
of warnings fixes for a variety of fil
On 4/12/2011 5:37 AM, Rémi Forax wrote:
On 12/03/2011 05:21 PM, Mike Duigou wrote:
On Dec 3 2011, at 07:12 , Rémi Forax wrote:
On 12/03/2011 03:33 PM, Alan Bateman wrote:
On 03/12/2011 12:37, Rémi Forax wrote:
I've started to remove warnings from java.util
and I'm not able to cleanly retrofi
On 12/05/2011 01:27 AM, Joe Darcy wrote:
On 12/4/2011 2:13 PM, Rémi Forax wrote:
On 12/04/2011 08:38 PM, Joe Darcy wrote:
Hi John,
Are there alternatives to adding two new fields to java.lang.Class?
I assume most Class'es won't have ClassValue information associated
with them.
-Joe
If y
Please review the following webrev submitted by Omair Majid, consisting of
warnings fixes for a variety of files in java.lang.
http://cr.openjdk.java.net/~omajid/webrevs/warnings-day-2011/01/
It looks pretty clean, but it would be good to get another pair of eyes on this
since there is sometim
On 12/4/2011 2:13 PM, Rémi Forax wrote:
On 12/04/2011 08:38 PM, Joe Darcy wrote:
Hi John,
Are there alternatives to adding two new fields to java.lang.Class?
I assume most Class'es won't have ClassValue information associated
with them.
-Joe
If you use Groovy, JRuby or Nashorn in your co
On 12/2/11 9:00 AM, Omair Majid wrote:
On 12/02/2011 07:18 AM, Alan Bateman wrote:
cc'ing core-libs-dev as that is the place to discuss these changes. I
see on the sign-up sheet [1] that omajid has signed up for java.lang,
maybe you are working together?
Unfortunately, David and I were not wor
On 12/04/2011 08:38 PM, Joe Darcy wrote:
Hi John,
Are there alternatives to adding two new fields to java.lang.Class? I
assume most Class'es won't have ClassValue information associated with
them.
-Joe
If you use Groovy, JRuby or Nashorn in your code, all visible classes
will use this tw
We know serialVersionUID is useless for this case. But we decided to add
it, which is the standard fix, in order to eliminate the warning
message. I think serialization compatibility of anonymous inner classes
is another issue.
Thanks,
Masayoshi
On 2011/12/02 13:53, Stuart Marks wrote:
> On 12/1/
Hi John,
Are there alternatives to adding two new fields to java.lang.Class? I
assume most Class'es won't have ClassValue information associated with them.
-Joe
On 12/3/2011 7:59 PM, John Rose wrote:
The caching ClassValue is still under review. I took the opportunity to remove
-Xlint war
18 matches
Mail list logo
