ArrayListString list = ...
iterator.forEachRemaining(list::add);
Rémi
On 29 août 2014 00:22:11 UTC+02:00, Pavel Rappo pavel.ra...@oracle.com wrote:
If we were to provide a Collections util it would to wrap Enumeration
as an Iterator but that's it.
Mike, that's what I'm talking about. It's just
On 06/30/2012 12:29 AM, Stuart Marks wrote:
Hi Core Libbers,
Please review some small wording and markup changes to the doc for
String.subSequence. The wording change is simply fixing a mistake, not
a semantic spec change.
http://cr.openjdk.java.net/~smarks/reviews/7170938/webrev.0/
The other solution is for 7 to use murmur hash instead of classical hash
but to always with the same seed, in that case it will not change from
run to run.
cheers,
Rémi
On 07/14/2012 01:09 AM, Mike Duigou wrote:
Hello all;
About a month ago a significant change was made to the Java SE 7 and
On 08/21/2012 10:45 PM, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/6984084-jdk8-StringRepeat/
http://cr.openjdk.java.net/%7Ejgish/6984084-jdk8-StringRepeat/
This started in lambda, making changes to both StringJoiner and
String. However, the dependence of
On 08/23/2012 11:46 PM, Dan Xu wrote:
Please review the fix of CR 7193406 at
http://cr.openjdk.java.net/~dxu/7193406/webrev/.
It cleans up warnings in the following java files.
src/share/classes/java/io/FilePermission.java
src/share/classes/java/util/ArrayDeque.java
I also vote for adding this overload, a lot of the usage of
Class.forName with three parameters are in fact just a way to load a
class without initialize it.
Rémi
On 08/24/2012 07:21 AM, serguei.spit...@oracle.com wrote:
I was thinking about the same.
But a CCC request is needed for such a
On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote:
Thanks for cleaning up those spaces Dan. The changes look fine.
Sorry for the extra trouble!
- Kurchi
On 8/28/12 10:22 PM, Dan Xu wrote:
It is funny. :) I have searched all source codes under jdk and
removed spaces for the similar cases.
On 08/29/2012 09:11 PM, Dan Xu wrote:
On 08/29/2012 08:27 AM, Joe Darcy wrote:
Hello,
On 8/29/2012 1:48 AM, Rémi Forax wrote:
On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote:
Thanks for cleaning up those spaces Dan. The changes look fine.
Sorry for the extra trouble!
- Kurchi
On 8/28/12
On 08/30/2012 01:39 AM, Dan Xu wrote:
On 08/29/2012 12:11 PM, Dan Xu wrote:
On 08/29/2012 08:27 AM, Joe Darcy wrote:
Hello,
On 8/29/2012 1:48 AM, Rémi Forax wrote:
On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote:
Thanks for cleaning up those spaces Dan. The changes look fine.
Sorry
On 08/30/2012 04:14 PM, Ulf Zibis wrote:
Am 30.08.2012 01:20, schrieb Stuart Marks:
On 8/29/12 4:36 AM, Ulf Zibis wrote:
@SuppressWarnings(fallthrough) is put to suppress warnings
generated by
another switch/case statements
Can't you move it from method scope to there?
while (i
On 08/07/2013 10:57 AM, Peter Levart wrote:
On 08/07/2013 12:23 AM, Dan Smith wrote:
On Aug 6, 2013, at 2:43 PM, Remi Forax fo...@univ-mlv.fr
fo...@univ-mlv.fr wrote:
On 08/06/2013 11:11 PM, Dan Smith wrote:
Please review this warnings cleanup.
Bug:
Le 29/09/2010 15:57, Alan Bateman a écrit :
I need a reviewer for a change to java.io.File's setReadOnly and
setWritable methods so that they don't change the DOS readonly
attribute on directories (or folders as Windows calls them). These
methods have never worked correctly for directories
Le 05/11/2010 15:57, assembling signals a écrit :
Hello, everyone!
Sorry, not sure if it's the right mailinglist, here [
http://mail.openjdk.java.net/mailman/listinfo ] there were no mailinglist
listed for java.dyn.
This is the wrong mailing list, the right one is mlvm
Le 08/11/2010 15:03, Chris Hegarty a écrit :
Doug, David,
This webrev contains the fix for CR 6993789: LinkedBlockingDeque
iterator/descendingIterator loops and owns lock forever, and also
contains some other minor changes that we inherit for free when
syncing to the latest LBQ in Dougs CVS,
The soft way to kill a process on windows to send a WM_CLOSE/WM_QUIT.
http://stackoverflow.com/questions/2055753/how-to-gracefully-terminate-a-process
Rémi
Le 10/11/2010 10:46, Andreas Kohn a écrit :
On Wed, 2010-11-10 at 06:02 +1000, David Holmes wrote:
Hi Andreas,
On 10/11/2010 5:31
Le 10/11/2010 13:55, Alan Bateman a écrit :
Rémi Forax wrote:
The soft way to kill a process on windows to send a WM_CLOSE/WM_QUIT.
http://stackoverflow.com/questions/2055753/how-to-gracefully-terminate-a-process
Rémi
Yes, that could work for graphical/foreground applications
Le 11/11/2010 20:34, Kelly O'Hair a écrit :
So some of these changes are using the new jdk7 language features?
(diamond operator)
Is this a first, or is this happening already? Just curious.
It's not the first time. I have seen it time to time.
Mark (Reinhold) was the first to push a patch
Le 17/11/2010 00:39, Mike Duigou a écrit :
I'll ask the same as Alan for a small doc review for ConcurrentLinkedQueue
Thanks,
Mike
diff --git a/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
b/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
---
Le 19/11/2010 16:49, John Platts a écrit :
Here are improvements that I really want to see to Java Collection APIs:
[...]
- Addition of methods that iterates through the collection and invokes a
callback. This is useful in cases where the callback object can be
pre-allocated, since
Le 22/11/2010 14:52, Alan Bateman a écrit :
This is a patch to default deserialization so that it uses
volatile-write when setting final fields:
http://cr.openjdk.java.net/~alanb/6647361/webrev/
Thanks,
Alan.
I wonder if we can't use putOrdered instead of putVolatile.
In that case
On 12/01/2010 06:24 PM, Joe Darcy wrote:
Hello.
Please review my simple fix for
7002594 Math.max and Math.min should use floatToRawIntBits() to
check for -0.0
http://cr.openjdk.java.net/~darcy/7002594.0/
Besides addressing the reported issues with max/min, I also review the
other
On 12/03/2010 11:52 PM, Mandy Chung wrote:
Fix for 6977034: Thread.getState() very slow
Webrev at:
http://cr.openjdk.java.net/~mchung/6977034/webrev.00/
Hi Mandy,
you can use Integer.highestOneBit instead of the loop.
Also, setMapElement should be a pure function, i.e without the side
Le 06/12/2010 08:35, Joe Darcy a écrit :
Hi Peter.
[...]
Off-list, Alan found the a related closed test and Stuart and I have
developed an explicit test that tickles this bug:
http://cr.openjdk.java.net/~darcy/6990094.1/
I plan to shortly push the fix with the test, although the test
On 12/06/2010 05:03 PM, Peter Jones wrote:
On Mon, Dec 6, 2010 at 2:35 AM, Joe Darcyjoe.da...@oracle.com wrote:
Off-list, Alan found the a related closed test and Stuart and I have
developed an explicit test that tickles this bug:
http://cr.openjdk.java.net/~darcy/6990094.1/
Looks good to
I will answer with a question.
Correct me if i'm wrong.
You see no slowdown to use StringBuffers instead of StringBuilders.
This means that perhaps the VM is able to remove synchronization block.
Which means that the NetBeans startup is most done by one thread.
If you want to improve the startup
Le 09/12/2010 05:57, Joe Darcy a écrit :
Rémi Forax wrote:
Le 14/11/2010 16:23, joe.da...@oracle.com a écrit :
Changeset: e1a1a2f5d7e1
Author:darcy
Date: 2010-11-14 07:22 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1a1a2f5d7e1
6991528: Support making
Paul,
see http://blogs.sun.com/jjg/entry/building_javac_for_jdk7
If you want more details.
Rémi
On 12/20/2010 11:43 PM, Kelly O'Hair wrote:
Not sure about a policy, but yes typically we require the previous JDK
release to be
the boot jdk. However, the policy, if you want to call it that, has
Hi Chris,
On 12/22/2010 02:45 PM, Chris Hegarty wrote:
Mike,
On 12/21/10 09:38 PM, Mike Duigou wrote:
Thanks. That's an important clarification to include. Here's the
revised text:
*
*pCare must also be exercised when using collections that do
not permit
* calling the
On 12/22/2010 04:10 PM, Chris Hegarty wrote:
On 12/22/10 03:07 PM, Rémi Forax wrote:
Hi Chris,
On 12/22/2010 02:45 PM, Chris Hegarty wrote:
Mike,
On 12/21/10 09:38 PM, Mike Duigou wrote:
Thanks. That's an important clarification to include. Here's the
revised text:
*
*pCare must also
On 12/22/2010 04:55 PM, Chris Hegarty wrote:
On 12/22/10 03:34 PM, Gregg Wonderly wrote:
On 12/22/2010 9:10 AM, Chris Hegarty wrote:
On 12/22/10 03:07 PM, Rémi Forax wrote:
On 12/22/2010 02:45 PM, Chris Hegarty wrote:
Have we thought about catching/swallowing these exceptions?
What do you
On 01/04/2011 02:02 AM, Ulf Zibis wrote:
Am 03.01.2011 21:16, schrieb Mike Duigou:
On Dec 24 2010, at 17:32 , Ulf Zibis wrote:
Am 23.12.2010 23:59, schrieb Paul Benedict:
Ulf, a previous email by Remi said only to invoke size() if the
collection is a Set.
Thanks I missed that.
My guess was,
Hi maurizio,
In my opinion, XlintWarn should also test invokeGeneric().
Moreover, it will be better to have one test by invoke*() instead of
having one
test for all invoke*()
Rémi
On 01/05/2011 11:00 AM, maurizio.cimadam...@oracle.com wrote:
Changeset: 15484cb7e5ae
Author:mcimadamore
On 01/05/2011 12:53 PM, Maurizio Cimadamore wrote:
On 05/01/11 11:23, Alan Bateman wrote:
Hi maurizio,
In my opinion, XlintWarn should also test invokeGeneric().
Moreover, it will be better to have one test by invoke*() instead of
having one
test for all invoke*()
Rémi
Hi Remi
I agree on your
On 01/13/2011 11:11 PM, Brian Goetz wrote:
rathole
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide
easier access to aspirin.) Java developers are *constantly* writing
methods like the suggested
On 01/13/2011 11:41 PM, David M. Lloyd wrote:
On 01/13/2011 04:31 PM, Rémi Forax wrote:
On 01/13/2011 11:11 PM, Brian Goetz wrote:
rathole
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide
easier access
On 01/14/2011 01:20 AM, mark.reinh...@oracle.com wrote:
Date: Thu, 13 Jan 2011 18:15:30 -0500
From: brian.go...@oracle.com
...
Between checkNonNull() and throwIfNull(), I lean towards the former. In any
case the answer should be driven by what is more obvious to the reader.
Agreed.
Nice,
thank you, Kumar.
Rémi
On 01/18/2011 05:38 PM, kumar.x.sriniva...@oracle.com wrote:
Changeset: 5cf6c432ef2f
Author:ksrini
Date: 2011-01-18 08:37 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5cf6c432ef2f
6982999: tools must support -target 7 bytecodes
On 01/27/2011 09:38 AM, Stephen Colebourne wrote:
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
I think we can't.
This method is already used at many place in the JDK.
About the name, I propose:
iUsedToUseGetClassHereButNodobyWasAbleToUnderstand()
Hi David,
On 01/27/2011 06:27 PM, Brian Goetz wrote:
Overall these look like good additions. I haven't reviewed the code
in detail but a quick sanity check suggests that this is a good
direction. There's definitely some more work needed on the testing
(for example, testing that the contents
You could use elementData.clone() instead of System.arraycopy
Rémi
On 02/11/2011 02:03 PM, Neil Richards wrote:
Hi Peter,
Using putFields/writeFields was the only way I found of properly
addressing the problem in Vector serialization.
The fix has not impacted performance significantly in
On 02/11/2011 02:59 PM, Neil Richards wrote:
Please find
where :)
an updated webrev zip file with corrected license text and
references to the RFE number, 7014637, in the testcases.
Thanks,
Neil
Rémi
On 02/17/2011 10:34 AM, Alan Bateman wrote:
Sean Chou wrote:
Hi,
I find there is a mismatch between the spec and the behavior of
java.io.FileOutputStream.getChannel().
The spec reads: The initial position of the returned channel will be
equal to the number of bytes written to the file so
Le 01/03/2011 10:46, Alan Bateman a écrit :
Stuart Marks wrote:
Here's a small webrev with changes to a handful of java.io tests to
use TWR.
http://cr.openjdk.java.net/~smarks/reviews/7022624/webrev.0/
* test/java/io/OutputStreamWriter/Encode.java
Pretty clearly a ServerSocket is a
On 03/01/2011 11:26 PM, Stuart Marks wrote:
On 3/1/11 7:28 AM, Rémi Forax wrote:
Le 01/03/2011 10:46, Alan Bateman a écrit :
Stuart Marks wrote:
Here's a small webrev with changes to a handful of java.io tests to
use TWR.
http://cr.openjdk.java.net/~smarks/reviews/7022624/webrev.0
Le 08/03/2011 11:06, Alan Bateman a écrit :
I need a reviewer for a small fix to two tests that no longer compile
in the jdk7/tl forest as they were using diamond with anonymous inner
classes.
Thanks,
Alan.
Looks good.
Rémi
diff --git a/test/java/nio/file/DirectoryStream/Basic.java
On 03/18/2011 06:01 PM, assembling signals wrote:
Hello, community!
Hello Ivan,
I noticed a new error since b134: Cannot use '' with anonymous inner
classes.
The code uses diamond syntax and was error-free before b134.
(Please see reproducible example at the end.)
Can someone explain: is
On 04/07/2011 08:29 AM, Joe Darcy wrote:
Hello.
Returning to some earlier work, I've developed a proposed fix for
6998871 Support making the Throwable.stackTrace field immutable
http://cr.openjdk.java.net/~darcy/6998871.2/
One constructor of Throwable now takes an additional boolean
On 04/07/2011 04:12 PM, Alan Bateman wrote:
Lance Andersen - Oracle wrote:
Hi all,
This is a request for a review of the changes to remove the lint
warnings for DriverManager. The diff is at
http://cr.openjdk.java.net/~lancea/7034656/.
Looks okay to me.
-Alan
So am I.
Rémi
Maybe I'm wrong but you can reuse the same clone.
I mean, it has to have a different identity from UNASSIGNED_STACK but
it can be the same for all clones.
Rémi
On 04/08/2011 08:27 PM, Joe Darcy wrote:
Updated webrev described below...
Joe Darcy wrote:
Joe Darcy wrote:
Hi Rémi.
Rémi Forax
On 04/15/2011 07:55 PM, Daniel D. Daugherty wrote:
Thumbs up.
Dan
Hi Mandy,
if fc.close() throws an IOException , it goes wrong.
I think you need to put fc.close() in its own a try/catch(IOException).
Rémi
On 4/15/2011 11:01 AM, Mandy Chung wrote:
Fix for 7032589: FileHandler leaking
On 04/15/2011 10:55 PM, Mandy Chung wrote:
On 04/15/11 13:41, Daniel D. Daugherty wrote:
On 4/15/2011 1:12 PM, Mandy Chung wrote:
Hi Remi,
On 04/15/11 11:05, Rémi Forax wrote:
Hi Mandy,
if fc.close() throws an IOException , it goes wrong.
I think you need to put fc.close() in its own
On 04/20/2011 02:22 AM, Mike Duigou wrote:
My sentiment is for StandardCharset.
I received offlist feedback which would support this. The pattern for enum like
collections of constants has been to use the singular form;
java.math.RoundingMode, java.lang.annotation.ElementType,
On 04/22/2011 06:22 PM, Lance Andersen - Oracle wrote:
Hi Folks,
Hi Lance,
I am looking for a reviewer for this update to BatchUpdateException to address
a findbugs issue for exposing a mutable object.
The webrev is at http://cr.openjdk.java.net/~lancea/7038565/
You should use clone()
On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote:
Hi Remi,
Thank you for the feedback.
[...]
You should use clone() instead of Arrays.copyOf.
Can you explain why you have a preference for clone() in this case?
It does the job :)
Arrays.copyOf() allows to resize the array.
Also
On 04/23/2011 12:11 PM, David Holmes wrote:
Rémi Forax said the following on 04/23/11 04:22:
On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote:
You should use clone() instead of Arrays.copyOf.
Can you explain why you have a preference for clone() in this case?
It does the job
know.
I think you should use Arrays.copyOfRange instead of Arrays.copyOf
because it looks as an improved version of Arrays.copyOf.
sorry just kidding :)
Thank you to those who have provided input.
Best Regards,
Lance
regards,
Rémi
On Apr 23, 2011, at 6:11 AM, David Holmes wrote:
Rémi
Hi Lance,
- logSync is not declared final.
- the comment thow a SecurityException is not that useful
- in getDrivers(), I think you can use an ArrayList to gather
all drivers and use Collections.enumeration() at the end.
- also instead of
if (drivers == null || drivers.equals())
On 04/27/2011 08:04 PM, Lance Andersen - Oracle wrote:
Hi David, Stuart
On Apr 26, 2011, at 8:34 PM, David Holmes wrote:
Hi Stuart,
Actually my comments more a response to Remi's assertion that clone should have
been used instead, without giving any technical rationale as to why clone would
On 05/07/2011 02:17 PM, Ulf Zibis wrote:
Hi all,
please excuse, that I have still problems to accept this additional
class, but +1 for the plural name.
If those charset constants are there, people _will use_ them without
respect on the existing _performance disadvantages_.
A common typical
control over the decoding process is
required.
as a way to say that it's ok to reuse a previously existing decoder.
Rémi
On 05/07/2011 07:55 PM, Ulf Zibis wrote:
Rémi, thanks for your feedback.
Am 07.05.2011 18:00, schrieb Rémi Forax:
On 05/07/2011 02:17 PM, Ulf Zibis wrote:
Hi all,
please
On 05/07/2011 08:54 PM, Xueming Shen wrote:
On 05-07-2011 上午 9:00, Rémi Forax wrote:
On 05/07/2011 02:17 PM, Ulf Zibis wrote:
Hi all,
please excuse, that I have still problems to accept this additional
class, but +1 for the plural name.
If those charset constants are there, people _will
On 05/09/2011 06:14 PM, mike.dui...@oracle.com wrote:
Changeset: bd8c10d1db87
Author:mduigou
Date: 2011-05-09 09:13 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bd8c10d1db87
7043104: disable test java/lang/invoke/InvokeDynamicPrintArgs.java
Reviewed-by: alanb
!
On 05/09/2011 09:39 PM, Alan Bateman wrote:
Rémi Forax wrote:
On 05/09/2011 06:14 PM, mike.dui...@oracle.com wrote:
Changeset: bd8c10d1db87
Author:mduigou
Date: 2011-05-09 09:13 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bd8c10d1db87
7043104: disable test java/lang
On 06/15/2011 08:00 PM, Joe Darcy wrote:
Hello.
Please review my JDK 8 fix for
7021922: java.lang.annoation.IncompleteExceptions throws NPE when
type is null
http://cr.openjdk.java.net/~darcy/7021922.0/
Thanks,
-Joe
Looks good.
Rémi
Le 16/06/2011 02:35, Joe Darcy a écrit :
Hello.
Please review my JDK 8 fix for
6226715: (ann) java.lang.annotation.AnnotationTypeMismatchException
could not be serialized
http://cr.openjdk.java.net/~darcy/6226715.0/
This fix includes the unusual step of marking a non-transient field
On 06/16/2011 05:17 PM, Joe Darcy wrote:
Rémi Forax wrote:
Le 16/06/2011 02:35, Joe Darcy a écrit :
Hello.
Please review my JDK 8 fix for
6226715: (ann)
java.lang.annotation.AnnotationTypeMismatchException could not be
serialized
http://cr.openjdk.java.net/~darcy/6226715.0
On 06/16/2011 06:49 PM, Mike Duigou wrote:
I guess that's what I should have suggested--that all exceptions/errors with
public constructors should support all four of the standard constructors
declared by 1.4+ Throwable. It's been occasionally annoying to use an exception
class that's missing
On 06/18/2011 09:39 PM, Alan Bateman wrote:
I need a reviewer for a small fix to a test that I caught looping on
my system. The test creates a server thread that emulates a non
responding LDAP server. Unfortunately the thread goes into a loop
reading from the connection once it is closed.
Yes, make sense.
Rémi
On 06/27/2011 06:03 PM, Ulf Zibis wrote:
+1
-Ulf
Am 27.06.2011 17:57, schrieb Sean Mullan:
Hey Alan,
Would it be a good idea if we add this Windows limitation to the NIO
javadocs somewhere, say in the FileChannel class? I spent a lot of
time chasing this down until
Le 30/06/2011 23:16, Zhong Yu a écrit :
Why does it return Class? extends |X| instead of Class? extends X? Quote:
The actual result type is Class? extends |X| where |X| is the
erasure of the static type of the expression on which getClass is
called.
This means the following code does not
It doesn't work because the complexity of size() can be O(n).
In my opinion, only the checks for emptyness are Ok.
Rémi
On 07/13/2011 05:40 PM, Sebastian Sickelmann wrote:
Jeff Hain wrote:
Hello.
I have some remarks about the methods named in the subject (JDK 6u26, JDK
7b147).
1)
On 08/04/2011 06:17 PM, Colin Decker wrote:
One better way to handle this in Java 8 would be to have a utility method
that takes a SupplierEnumerationE SAM argument (with a no-arg method
that returns an EnumerationE) and returns an IterableE that gets a new
Enumeration from the supplier each
reference on the method iterator.
IterableString iterable = #Collections.iterator(enumeration).iterator;
Rémi
On Thu, Aug 4, 2011 at 12:34 PM, Rémi Forax fo...@univ-mlv.fr
mailto:fo...@univ-mlv.fr wrote:
On 08/04/2011 06:17 PM, Colin Decker wrote:
One better way to handle
.
--
Colin
doh, sorry, right.
Rémi
On Thu, Aug 4, 2011 at 1:03 PM, Rémi Forax fo...@univ-mlv.fr
mailto:fo...@univ-mlv.fr wrote:
On 08/04/2011 06:52 PM, Colin Decker wrote:
No, that copies the Enumeration. I'm talking about something that
creates lazy Iterators backed
Agree, looks good.
Rémi
On 08/08/2011 03:41 PM, Lance Andersen - Oracle wrote:
Looks fine to me Joe
Best
Lance
On Aug 8, 2011, at 1:24 AM, Joe Darcy wrote:
Hello.
Please review this small fix, developed after I went through my open bug list;
patch below, webrev at:
6380161 (reflect)
On 08/09/2011 01:43 PM, Alan Bateman wrote:
A few months back there was a bug report [1] pointing out that it's
possible to continue writing to a BufferedWriter after invoking its
close method and the close fails. A similar issue arises with
BufferedOutputStream and other classes. At issue
On 08/10/2011 09:39 PM, Joe Darcy wrote:
On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
Hello Joe,
Could you please review these small changes to remove javac build
warnings from the reflection classes?
Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
webrev:
On 08/10/2011 09:39 PM, Joe Darcy wrote:
On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
Hello Joe,
Could you please review these small changes to remove javac build
warnings from the reflection classes?
Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
webrev:
On 08/11/2011 09:07 PM, Alexandre Boulgakov wrote:
Please review the attached patch to fix a build break.
The fix changes new Class[] to new Class?[] in two places.
Thanks,
Sasha
Hi Sasha,
you can rewrite:
connectMethod = corbaStubClass.getMethod(connect,
new Class[]
On 08/11/2011 10:19 PM, assembling signals wrote:
Hello, community!
Enum does implement Comparable, while EnumSet does NOT implement SortedSet and
EnumMap doesn NOT implement SortedMap.
Should I file a bug report (RFE), would there be a chance to see this being
implemented in JDK8?
I've
On 08/11/2011 10:55 PM, Jonathan Gibbons wrote:
Rémi, you wrote:
On 08/11/2011 09:07 PM, Alexandre Boulgakov wrote:
/ Please review the attached patch to fix a build break.
//
// The fix changes new Class[] to new Class?[] in two places.
//
// Thanks,
// Sasha
/
Hi Sasha,
you can rewrite:
On 08/12/2011 01:29 AM, Jonathan Gibbons wrote:
On 08/11/2011 02:56 PM, Rémi Forax wrote:
On 08/11/2011 10:55 PM, Jonathan Gibbons wrote:
Rémi, you wrote:
On 08/11/2011 09:07 PM, Alexandre Boulgakov wrote:
/ Please review the attached patch to fix a build break.
//
// The fix changes new
On 08/12/2011 02:46 PM, mike.ske...@talk21.com wrote:
Hi Remi,
Your argument is flawed
The complexity of the operations is not defined by the interface or the
presence or absence of the interface
In theory yes, but in practice ...
What is the purpose of java.util.RandomAccess ?
If you have
in the spec.
So practically, you have to 'infer' it.
Regards
Mike
Regards,
Rémi
--Original Message--
From: Rémi Forax
To: Mike Skells
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Any chance to see EnumSet implement SortedSet in JDK8?
Sent: 12 Aug 2011 14:06
On 08/12/2011 02:46 PM
One day, someone brave enough should rewrite sun/reflect/generics
because there is a lot of boilerplate in this package.
The same code in ASM is at least 5 times shorter.
Rémi
On 08/17/2011 09:12 PM, jonathan.gibb...@oracle.com wrote:
Changeset: e59aad6ed600
Author:jjg
Date:
Hurrah, this is the changeset of the month,
removing things is always a win.
Rémi
On 08/17/2011 11:05 PM, xueming.s...@oracle.com wrote:
Changeset: 2961329a6774
Author:sherman
Date: 2011-08-17 14:14 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2961329a6774
6237353:
On 09/02/2011 12:51 PM, Alan Bateman wrote:
Xueming Shen wrote:
Hi,
This is a forward porting. Same fix has been in jdk5/6, and will be
in jdk 7u2 later.
http://cr.openjdk.java.net/~sherman/6898310/webrev
The change itself is relative simple. And given its race-condition
nature, no
On 09/02/2011 01:34 PM, Alan Bateman wrote:
Rémi Forax wrote:
Arghhh, next() can return null !
CharsetProvider provider = ...
IteratorCharset it = provider.charsets();
IteratorCharset it2 = provider.charsets();
Charset charset = it.next();
provider.deleteCharset(charset.name
On 09/02/2011 03:17 PM, Ulf Zibis wrote:
Am 02.09.2011 15:00, schrieb Rémi Forax:
A way to solve the problem is to split AbstractCharsetProvider in two
objects
i.e we should create a new object named CharsetProviderView that
contains
deleteCharset() and charset() and provide this object
On 09/03/2011 12:06 AM, joe.da...@oracle.com wrote:
Hello.
Please review this simple patch to replace explicit array copy loops
with System.arraycopy:
6989067 BigInteger's array copiers should be converted to
System.arraycopy()
http://cr.openjdk.java.net/~darcy/6989067.0/
Patch
to know :)
Thanks,
-Joe
cheers,
Rémi
On 9/2/2011 3:30 PM, Rémi Forax wrote:
On 09/03/2011 12:06 AM, joe.da...@oracle.com wrote:
Hello.
Please review this simple patch to replace explicit array copy loops
with System.arraycopy:
6989067 BigInteger's array copiers should be converted
On 09/06/2011 03:54 PM, Joe Darcy wrote:
Oops! Should have listed Remi as the second reviewer.
Sorry,
:)
-Joe
Rémi
joe.da...@oracle.com wrote:
Changeset: 5077e7a68259
Author:darcy
Date: 2011-09-06 06:17 -0700
URL:
On 09/19/2011 04:21 PM, michael.x.mcma...@oracle.com wrote:
Changeset: e3d78fe803d4
Author:michaelm
Date: 2011-09-19 15:14 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3d78fe803d4
7091369: DatagramSocket/Limit.java failing on 8 and 7u2
Reviewed-by: chegar, alanb
!
On 10/25/2011 12:23 PM, David Holmes wrote:
I'm getting a build error due to -Werror and the fact that Util.java
uses a raw type: new Class[] { ...} and so generates a raw type warning
Until recently, javac has forgotten to warn about that kind of rawtype
(array of rawtype).
new Class?[] {
On 11/07/2011 01:28 AM, David Holmes wrote:
Hi Mike,
On 5/11/2011 2:29 AM, Mike Duigou wrote:
On Nov 3 2011, at 17:40 , David Holmes wrote:
I see that you have pushed a version of this change and that I was
listed as a reviewer. However I never saw an updated webrev and
there was no
On 11/07/2011 05:03 PM, Gary Adams wrote:
Here's another test with race conditions built into the test
that can be easily avoided
CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails
intermittently
There are at least two race conditions in the test as currently written.
The
On 11/07/2011 09:50 PM, Brian Goetz wrote:
Wait/notify may be better than sleeping, but semaphore/latch/barrier are much
better than wait/notify. Much.
Sent from my iPhone
Yeah, APIs evolve, it seems I'm to old for that s... :)
Rémi
On Nov 7, 2011, at 1:28 PM, chris
On 11/08/2011 02:12 PM, Gary Adams wrote:
Let's see if this captures all the comments and
is a bit more robust in the face of the original
race conditions mentioned.
- threads are started before they are recorded in local variables
- second is now volatile
- stop thread group is
On 11/14/2011 05:09 PM, Gary Adams wrote:
I've updated the webrev for CR#6860309 using a CountDownLatch.
The main thread will wait til both worker threads are ready to
block on the read() before the process is destroyed.
http://cr.openjdk.java.net/~gadams/6860309/
Tested with -Xcomp, but
On 11/20/2011 08:14 PM, Alan Bateman wrote:
On 18/11/2011 18:27, Darryl Mocek wrote:
Hello. Please review this patch to fix a serialization issue with
String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize
the class, the equals test will fail in the comparison of what was
1 - 100 of 357 matches
Mail list logo
