On 04/10/2014 08:21 PM, Steven Schlansker wrote:
On Apr 9, 2014, at 2:21 AM, Paul Sandoz wrote:
On Apr 8, 2014, at 9:15 PM, Mike Duigou wrote:
That seems a terribly broken usage of UUID for 128 bit numbers or a pair of
signed 64 bit numbers :-)
Part of me thinks we should not be supportin
Hi,
This is an update from Xerces XPointer. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8037259.
Webrevs: http://cr.openjdk.java.net/~dli/8037259/webrev/
Existing tests: JAXP SQE and unit tests passed. No new tests were added
because most of the changes are minor
Hello,
This is a minor amplification of information already contained in the javadoc.
Issue: https://bugs.openjdk.java.net/browse/JDK-8035427
Patch: http://cr.openjdk.java.net/~bpb/8035427/webrev.00/
This is a doc-only change. If acceptable, a CCC request would I expect need to
be submitted a
Am 10.04.2014 21:53, schrieb Tim Bell:
On 04/10/14 19:26, Ulf Zibis wrote:
BTW, where are these links gone:
This part of the question I can handle.
The six digit Bug numbers came from the legacy OpenJDK bugzilla instance.
Before it was shut down, those bug reports were transferred to JBS. I
Second day back from vacation so I guess it’s time to beat this horse again …
As there was no response to the message included below I am simply re-posting
it.
Thanks,
Brian
On Mar 25, 2014, at 7:19 AM, Brian Burkhalter
wrote:
> On Mar 25, 2014, at 1:58 AM, Paul Sandoz wrote:
>
>> This is
On 04/10/14 19:26, Ulf Zibis wrote:
BTW, where are these links gone:
This part of the question I can handle.
The six digit Bug numbers came from the legacy OpenJDK bugzilla instance.
Before it was shut down, those bug reports were transferred to JBS. In
the process, they were assigned new JD
Am 10.04.2014 17:20, schrieb Xueming Shen:
Looks fine. Personally I would prefer the "canonicalized/real" name
"ISO-8859-1" though.
Yep, using the canonical name guarantees best performance for the charset
lookup.
BTW, where are these links gone:
Bug 100092 -- Speed-up FastCharsetProvider
On 4/10/14 11:34 AM, Brian Burkhalter wrote:
Would have been nice had I included the link:
http://cr.openjdk.java.net/~bpb/8039474/webrev.01/
Brian - thanks for getting this fixed. Looks good to me.
I reviewed the fix for JDK-8036848 and missed the subtle compatibility
issue (thanks to Sher
On 04/10/2014 12:03 PM, Chris Hegarty wrote:
On 10 Apr 2014, at 19:50, Xueming Shen wrote:
On 04/10/2014 11:38 AM, Mike Duigou wrote:
On Apr 10 2014, at 11:08 , Chris Hegarty wrote:
On 10 Apr 2014, at 18:40, Mike Duigou wrote:
On Apr 10 2014, at 03:21 , Chris Hegarty wrote:
On 10
On 4/10/14 11:05 AM, Mike Duigou wrote:
"Isn't all this sun.misc stuff going go away soon anyway?" <-- wishful thinking
We use them in our implementation and can't go away but at least access
will be denied with module boundary enforcement.
Mandy
On 10 Apr 2014, at 19:50, Xueming Shen wrote:
> On 04/10/2014 11:38 AM, Mike Duigou wrote:
>> On Apr 10 2014, at 11:08 , Chris Hegarty wrote:
>>
On 10 Apr 2014, at 18:40, Mike Duigou wrote:
> On Apr 10 2014, at 03:21 , Chris Hegarty wrote:
>
>> On 10 Apr 2014, at
On 04/10/2014 11:38 AM, Mike Duigou wrote:
On Apr 10 2014, at 11:08 , Chris Hegarty wrote:
On 10 Apr 2014, at 18:40, Mike Duigou wrote:
On Apr 10 2014, at 03:21 , Chris Hegarty wrote:
On 10 Apr 2014, at 11:03, Ulf Zibis wrote:
Hi Chris,
Am 10.04.2014 11:04, schrieb Chris Hegarty:
Tr
On Apr 10 2014, at 11:08 , Chris Hegarty wrote:
>
>> On 10 Apr 2014, at 18:40, Mike Duigou wrote:
>>
>>
>>> On Apr 10 2014, at 03:21 , Chris Hegarty wrote:
>>>
On 10 Apr 2014, at 11:03, Ulf Zibis wrote:
Hi Chris,
Am 10.04.2014 11:04, schrieb Chris Hegarty:
>
Would have been nice had I included the link:
http://cr.openjdk.java.net/~bpb/8039474/webrev.01/
Brian
On Apr 10, 2014, at 11:32 AM, Brian Burkhalter
wrote:
> Here’s an updated version with the encoder also modified for symmetry.
Here’s an updated version with the encoder also modified for symmetry.
Brian
On Apr 10, 2014, at 11:23 AM, Xueming Shen wrote:
> String version has the cache mechanism of charset -> CharsetDe/Encoder, so if
> cache hits, you don't need to have String->Charset lookup.
>
> We don't cache the "ex
On Apr 9, 2014, at 2:21 AM, Paul Sandoz wrote:
> On Apr 8, 2014, at 9:15 PM, Mike Duigou wrote:
>
> That seems a terribly broken usage of UUID for 128 bit numbers or a pair of
> signed 64 bit numbers :-)
>
> Part of me thinks we should not be supporting such broken usage. Might be
> worth g
On 04/10/2014 11:08 AM, Chris Hegarty wrote:
On 10 Apr 2014, at 18:40, Mike Duigou wrote:
On Apr 10 2014, at 03:21 , Chris Hegarty wrote:
On 10 Apr 2014, at 11:03, Ulf Zibis wrote:
Hi Chris,
Am 10.04.2014 11:04, schrieb Chris Hegarty:
Trivially, you could ( but of not have to ) use
ja
This fix is to "un-do" a previous changeset (8036848), in which it replaces the
use
of deprecated String.getBytes(int,int,byte[],int) method with String.getBytes()
(which uses the default platform default charset), therefor causes a behavioral
change. This one is to undo that change to go back to
=> Resolved: Won’t Fix.
On Apr 10, 2014, at 11:05 AM, Mike Duigou wrote:
> Strange, wrongheaded and nonsensical behaviour, but longstanding.
> On 10 Apr 2014, at 18:40, Mike Duigou wrote:
>
>
>> On Apr 10 2014, at 03:21 , Chris Hegarty wrote:
>>
>>> On 10 Apr 2014, at 11:03, Ulf Zibis wrote:
>>>
>>> Hi Chris,
>>>
>>> Am 10.04.2014 11:04, schrieb Chris Hegarty:
Trivially, you could ( but of not have to ) use
java.nio.
That is to say either explicitly or implicitly, i.e., using the default on both
ends?
On Apr 10, 2014, at 10:59 AM, Brian Burkhalter
wrote:
> How can one keep it symmetrical without forcing a particular encoding?
>
> Brian
>
> On Apr 10, 2014, at 10:54 AM, Mike Duigou wrote:
>
>> Shouldn't
It won't be symmetrical unless the default charset is ISO8859-1.
We can't change sun.misc.CharacterEncoder(byte) to use the default charset
because it has the longstanding behaviour of encoding to ISO8859-1 and I would
argue we can't change sun.misc.CharacterDecoder(String) from using the defaul
How can one keep it symmetrical without forcing a particular encoding?
Brian
On Apr 10, 2014, at 10:54 AM, Mike Duigou wrote:
> Shouldn't we be using the platform default character set rather than
> iso8859-1?
>
> This change will change the charset used for all platforms not using
> iso8859
Shouldn't we be using the platform default character set rather than iso8859-1?
This change will change the charset used for all platforms not using iso885901
as their default.
It is certainly odd that sun.misc.CharacterEncoder(byte) and
sun.misc.CharacterDecoder(String) are not symmetrical but
On Apr 10 2014, at 03:21 , Chris Hegarty wrote:
> On 10 Apr 2014, at 11:03, Ulf Zibis wrote:
>
>> Hi Chris,
>>
>> Am 10.04.2014 11:04, schrieb Chris Hegarty:
>>> Trivially, you could ( but of not have to ) use
>>> java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to
>
Looks fine. Personally I would prefer the "canonicalized/real" name
"ISO-8859-1" though.
-Sherman
On 4/10/14 7:57 AM, Brian Burkhalter wrote:
On Apr 10, 2014, at 3:27 AM, Ulf Zibis wrote:
Correction ...
Am 10.04.2014 12:03, schrieb Ulf Zibis:
Hi Chris,
Am 10.04.2014 11:04, schrieb Chris
On 10 Apr 2014, at 15:57, Brian Burkhalter wrote:
>
> On Apr 10, 2014, at 3:27 AM, Ulf Zibis wrote:
>
>> Correction ...
>>
>> Am 10.04.2014 12:03, schrieb Ulf Zibis:
>>> Hi Chris,
>>>
>>> Am 10.04.2014 11:04, schrieb Chris Hegarty:
Trivially, you could ( but of not have to ) use
j
On Apr 10, 2014, at 3:27 AM, Ulf Zibis wrote:
> Correction ...
>
> Am 10.04.2014 12:03, schrieb Ulf Zibis:
>> Hi Chris,
>>
>> Am 10.04.2014 11:04, schrieb Chris Hegarty:
>>> Trivially, you could ( but of not have to ) use
>>> java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of S
On 4/9/14, 10:42 PM, Alan Bateman wrote:
On 09/04/2014 17:00, Alexandre (Shura) Iline wrote:
Hi.
I'd like to ask for review of this fix:
http://cr.openjdk.java.net/~shurailine/8039438/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8039438
Looks okay to me.
For the class description
On 10/04/2014 11:35, Seán Coffey wrote:
This should make the code more robust Alan.
http://cr.openjdk.java.net/~coffeys/webrev.8038491.v3/webrev/
This looks much better and means that the checks prior to the read do
what they were intended to do. There are still works with this code as
it was
On 10 Apr 2014, at 11:56, Miroslav Kos wrote:
> Hi,
> please review the following change - this is just missing license headers fix
> -
>
> 8039899: Missing licence headers in test for JDK-8033113
> JBS: https://bugs.openjdk.java.net/browse/JDK-8039899
> WEBREV: http://cr.openjdk.java.net/~mkos
On 10/04/2014 11:49, Pavel Rappo wrote:
Given the amount of mutual exclusion and synchronization already involved, I
wonder if it's worth making it thread-safe after all. And (idialy) forget about
races there forever.
It's a fair point Pavel. All java.util.zip classes would need to be
looked
Hi,
please review the following change - this is just missing license
headers fix -
8039899: Missing licence headers in test for JDK-8033113
JBS: https://bugs.openjdk.java.net/browse/JDK-8039899
WEBREV: http://cr.openjdk.java.net/~mkos/8039899/jdk.01/
Chris, may I ask you to push it to jdk9u-d
+1
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
On Apr 10, 2014, at 1:02 AM, Joe Darcy wrote:
> Hello,
>
> I've started looking at cleaning up the fallthrough lin
Given the amount of mutual exclusion and synchronization already involved, I
wonder if it's worth making it thread-safe after all. And (idialy) forget about
races there forever.
-Pavel
On 10 Apr 2014, at 11:35, Seán Coffey wrote:
> This should make the code more robust Alan.
>
> http://cr.op
This should make the code more robust Alan.
http://cr.openjdk.java.net/~coffeys/webrev.8038491.v3/webrev/
regards,
Sean.
On 09/04/2014 22:16, Alan Bateman wrote:
On 09/04/2014 20:10, Seán Coffey wrote:
I played around with adding some skip testing Alan but didn't see it
increase the rate of
On 10 Apr 2014, at 11:03, David Holmes wrote:
> Looks good to me too Chris.
Thanks for looking at this David. Unfortunately I pushed before receiving this
mail, so you are not listed as a reviewer on the changeset,
> But I can't help wonder if there is a design flaw in javadoc here, as this
>
Correction ...
Am 10.04.2014 12:03, schrieb Ulf Zibis:
Hi Chris,
Am 10.04.2014 11:04, schrieb Chris Hegarty:
Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to
avoid the cost of String to CharSet lookup.
In earlier tests Sherman and I have found o
On 10 Apr 2014, at 11:03, Ulf Zibis wrote:
> Hi Chris,
>
> Am 10.04.2014 11:04, schrieb Chris Hegarty:
>> Trivially, you could ( but of not have to ) use
>> java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to
>> CharSet lookup.
>
> In earlier tests Sherman and I have f
Hi Chris,
Am 10.04.2014 11:04, schrieb Chris Hegarty:
Trivially, you could ( but of not have to ) use
java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to
CharSet lookup.
In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets
Looks good to me too Chris.
But I can't help wonder if there is a design flaw in javadoc here, as
this means you should never use relative links in any doc element that
might be inherited. Which almost reduces to never use relative links. :(
David
On 10/04/2014 12:07 AM, Chris Hegarty wrote:
Hi Volker,
Thanks a lot for your comments, I've made another patch,
http://cr.openjdk.java.net/~luchsh/JDK-8034220.v4/
On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis wrote:
> Hi Jonathan,
>
> sorry, but I found a few more issues:
>
> - please use strncpy instead of strcpy in TimeZone_md.c:798
On 10 Apr 2014, at 02:19, Brian Burkhalter wrote:
> Hello,
>
> Issue:https://bugs.openjdk.java.net/browse/JDK-8039474
> Patch:http://cr.openjdk.java.net/~bpb/8039474/webrev.00/
The change looks fine to me Brian.
Trivially, you could ( but of not have to ) use
java.nio.charset.
> BigInteger.java from java.lang was also touched.
sorry, from java.math
On 10.04.2014 12:23, alexander stepanov wrote:
Hello,
Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8030709
Webrev corresponding:
http://cr.openjdk.java.net/~yan/8030709/w
Hello,
Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8030709
Webrev corresponding:
http://cr.openjdk.java.net/~yan/8030709/webrev.00/
Just a minor cleanup of javadoc to avoid tidy warnings; no other code
affected.
BigInteger.java from java.la
45 matches
Mail list logo
