Mostly fine.
1. "import java.text.FieldPosition;" is not needed anymore.
2. In jar/Main, you can also consider creating a separate
SimpleDateFormat object (maybe private final static?). It seems the
initialization is quite heavy.
You recently became a jdk8 committer, right? That means you ca
Hello Max,
Thanks a lot for review, here's the updated patch,
http://cr.openjdk.java.net/~luchsh/7163483_5/
On 07/10/2012 08:54 AM, Weijun Wang wrote:
Hi Jonathon
This is better. Two minor comments, you can decide what to do or we
can see what core-lib-devs think:
I was proposing my soluti
Hi Paul,
This is now for 7u8, so I started a new thread.
As we discussed, I've removed the hack of using escapeNonUSAscii. In
this regard, we're now in sync with the source code in Xerces.
Here's the webrev:
http://cr.openjdk.java.net/~joehw/7u8/7166896/webrev/
Thanks,
Joe
Hi,
In JDK7, the decoder and encoder implementation of most of our
single-byte charsets
and UTF-8 charset are optimized to implement the internal interfce
sun.nio.cs.ArrayDecoder/
Encoder to provide a fastpath for String.getBytes(...) and new
String(byte[]...) operations. I
have an old blog
Hello,
I approve the original changeset being backed out.
Cheers,
-Joe
On 7/10/2012 3:36 PM, Seán Coffey wrote:
thanks for review Chris, I've no problem dropping the new testcase for
now. I was just being extra diligent by adding one. I haven't seen the
testcase fail incorrectly yet however.
thanks for review Chris, I've no problem dropping the new testcase for
now. I was just being extra diligent by adding one. I haven't seen the
testcase fail incorrectly yet however. When you get time, maybe you can
share tips on what's flaky in it!
I need one more reviewer since we're in critic
On 07/09/2012 04:41 PM, Stuart Marks wrote:
OK, here's the review for the second half of the files in the webrev.
I saw your reply to the first half (to which I'll reply separately),
and I don't think there's anything here that's affected by them.
*** AppleUserImpl.java
*** ApplicationServer
Sean,
The backout approach seems reasonable, but I really don't like the test.
It is racey and not guaranteed to consistently pass. I agree/approve the
backout, but would prefer not to add the test in its current state.
-Chris.
On 10/07/2012 17:37, Seán Coffey wrote:
7105952 fix introduced
I think pushing what we have now and doing the cleanup after to get the
RMI test changes in is the best approach.
Darryl
On 07/10/2012 01:52 PM, Stuart Marks wrote:
On 7/9/12 11:56 PM, Olivier Lagneau wrote:
Le 10/07/2012 08:49, Olivier Lagneau a écrit :
Now in the 7161503 SetChilEnv case:
Hi Paul,
I agree, it looked quite messy, isn't it :), keeping a hack that
generates encoded url and yet not support IPv6 addresses that contain
international characters?
It IS a more preferable solution to remove the hack of using
escapeNonUSAscii -- so I'll do :)
Thanks,
Joe
On 7/10/2012
On 7/9/12 11:56 PM, Olivier Lagneau wrote:
Le 10/07/2012 08:49, Olivier Lagneau a écrit :
Now in the 7161503 SetChilEnv case:
I think we should just revert to the existing code regarding the
DebugExecWatcher and related exception cleanup fix.
We must then accept to keep this exception raised
Hello,
Please review the JDK8 changes for JEP 127: Improve Locale Data
Packaging and Adopt Unicode CLDR Data
(http://openjdk.java.net/jeps/127). The webrev is located at:
http://cr.openjdk.java.net/~naoto/6336885/webrev.00/
The main bug id for this enhancement is:
6336885: RFE: Locale Data
Hi Joe,
If you are gonna fix things to support IPv6 addresses in URLs i really think
you need to make it work for URLs with international characters too.
On Jul 10, 2012, at 8:50 PM, Joe Wang wrote:
>>
>> 602 if (reader == null) {
>> 603 stream = xmlInputSource.getByteStre
On 7/9/2012 10:59 PM, Paul Sandoz wrote:
Hi Joe,
What happens when someone logs a bug for system IDs containing IPv6 addresses
and non-percent encoded international characters?
Exception would be expected just as if Xerces is used.
On Jul 10, 2012, at 3:42 AM, Joe Wang wrote:
Hi Paul,
I
7105952 fix introduced some improvements for finalization strategy
around FileInputStream/FileOutputStream/RandomAccessFile.
However a recently reported issue has highlighted an issue where memory
heap can be consumed with SocketOutputStream objects as a result of
clients repeatedly calling
Hi Stuart,
I am in vacation for 2 days, but I think I need reply anyway now.
First thanks for reviewing and giving your time on this.
Now in the 7161503 SetChilEnv case:
*** SetChildEnv.java
The testing of the message string from the IOException causes me great
concern. This message is def
16 matches
Mail list logo
