Hi Alan,
Based on current discussions we have had and existing usages in our code
base,
I would like to propose that the fix should ONLY make sure that
${TESTVMOPTS} will be passed in when launching java from shell script.
For other options such as ${TESTJAVAOPTS} ${TESTTOOLVMOPTS} and
${TES
eh - yes - ouch! 21 bit cannot occur (char = 16 bits)
please, please ignore my comment about it.
Am 07.02.2014 um 00:15 schrieb Xueming Shen :
> Modified UTF8 has to be used, as specified by the spec.
>
> http://download.java.net/jdk8/docs/api/java/io/DataInput.html#modified-utf-8
>
> -Sherman
Modified UTF8 has to be used, as specified by the spec.
http://download.java.net/jdk8/docs/api/java/io/DataInput.html#modified-utf-8
-Sherman
On 02/06/2014 02:50 PM, Robert Stupp wrote:
>>> -Chris.
>>
Hi,
I looked into the UTF serialization and deserialization code - and compared it
a bit with the code behind "new String(byte[], Charset)",
"String.getBytes(Charset)".
Just to find something that can be safely reused in Object*Stream classes to
optimize String handling.
The first thing I noti
String is probably the most commonly used class in the whole of Java.
Please please please do not pollute it with this dangerous new method.
Your Java-is-cool example is ridiculously trivial, of no practical use
whatsoever, and absolutely *not* cool.
How about a proper test where you have to doub
Hi,
I'm trying to trace/count object allocations - especially regarding the
ObjectIn/OutputStream stuff.
I know two API points: JVMTI and instrumentation. JVMTI fires an event for
nearly everything except allocations from bytecode - instrumentation allows to
transform bytecode (e.g. to issue a
To cover this problem, I filed a new language suggestion:
https://bugs.openjdk.java.net/browse/JDK-8033813 :-)
-Ulf
Am 06.02.2014 18:59, schrieb Ulf Zibis:
I still more like the break-to-label approach. It looks more logical and saves one comparison.
This might count on very very short strings
On 02/06/2014 11:41 AM, Ulf Zibis wrote:
Me again ;-)
On 02/06/2014 10:30 AM, Ulf Zibis wrote:
But why not just coding:
2558 char ch = value[first];
2559 if (Character.isSurrogate(ch) {
2560 hasSurr = true;
2561 break;
2562 }
Me again ;-)
On 02/06/2014 10:30 AM, Ulf Zibis wrote:
But why not just coding:
2558 char ch = value[first];
2559 if (Character.isSurrogate(ch) {
2560 hasSurr = true;
2561 break;
2562 }
2563 if (ch != Character.toLow
On 06/02/2014 17:16, Henry Jen wrote:
Hi,
Please review a simple bug fix that loosen the generic type, the
original proposed CCC for JDK-8009736 and webrev/specdiff has a
discrepancy, I am not sure if another CCC is needed.
https://bugs.openjdk.java.net/browse/JDK-8033590
http://cr.openjdk.j
Changeset: 7534523b4174
Author:henryjen
Date: 2014-02-06 10:30 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7534523b4174
8033590: java.util.Comparator::thenComparing has unnecessary type restriction
Reviewed-by: psandoz
! src/share/classes/java/util/Comparator.java
! test/
On 02/06/2014 10:30 AM, Ulf Zibis wrote:
Am 06.02.2014 18:40, schrieb Xueming Shen:
Ulf,
webrev has been updated to use isBmpCodePoint() as suggested. Another
benefit of using isBmpCodePoint() is that some Character.ERROR checks
are no longer necessary
Great, I didn't see that.
But why not
Am 06.02.2014 18:40, schrieb Xueming Shen:
Ulf,
webrev has been updated to use isBmpCodePoint() as suggested. Another
benefit of using isBmpCodePoint() is that some Character.ERROR checks
are no longer necessary
Great, I didn't see that.
But why not just coding:
2558 char ch = va
Paul,
toUpperCaseEx is overridden in CharacterData00/Latin1. Those two are
under gensrc/java/lang. It might be possible to combine them some day
(need to dig out some decade long history and probably there is compability
concern...), but definitely is beyond the scope of this "improvement" :-)
U
Am 05.02.2014 21:06, schrieb Xueming Shen:
http://cr.openjdk.java.net/~sherman/8032012/webrev
webrev has been updated accordingly.
I still more like the break-to-label approach. It looks more logical and saves one comparison. This
might count on very very short strings, but I would rename it
Hi,
8014320 is a JDK9 enhancement and everybody is probably busy with JDK8,
but I wanted to let the BigInteger people know the patch is finished. It
consists of 3 patched files and 1 new file; they can be found at
https://github.com/tbuktu/bigint/raw/5142a961252b2cd217377f32e4351640086c94e2/src/m
Hi,
Please review a simple bug fix that loosen the generic type, the
original proposed CCC for JDK-8009736 and webrev/specdiff has a
discrepancy, I am not sure if another CCC is needed.
https://bugs.openjdk.java.net/browse/JDK-8033590
http://cr.openjdk.java.net/~henryjen/tl/8033590.0/webrev/
Hi,
now that BigInteger deals better with large numbers, it would be nice
for that to translate into an improvement in BigDecimal performance
because BigDecimal is essentially a wrapper around BigInteger.
Unfortunately, BigDecimal is still slower than BigInteger because it has
to scale and round.
On 2/6/14 4:49 PM, Mandy Chung wrote:
Hi Daniel,
On 2/6/2014 7:29 AM, Daniel Fuchs wrote:
https://bugs.openjdk.java.net/browse/JDK-8029876
8029876: Add a test to verify that Logger.getLogger
& LogManager.getLogManager don't throw NPE
when System.out == null
webrev (trivial co
Hi,
Am 06.02.2014 00:57, schrieb Xueming Shen:
On 02/05/2014 03:28 PM, Ulf Zibis wrote:
Additionally you could use Character.isSurrogate() and Character.isSupplementaryCodeappropriate places. Both are better optimized for JIT.
j.l.C.isSupplementaryCodePoint() checks up boundary of supp, we pro
Hi Daniel,
On 2/6/2014 7:29 AM, Daniel Fuchs wrote:
https://bugs.openjdk.java.net/browse/JDK-8029876
8029876: Add a test to verify that Logger.getLogger
& LogManager.getLogManager don't throw NPE
when System.out == null
webrev (trivial copy of the test to jdk9-dev):
http://cr.
Hi,
Please find below a patch that adds a new test for logging
in JDK 9.
The test verifies an issue we had on JDK 7 (the test is already
in 7) but since the issue was not present in 8 & 9 the fix
(and test) went to 7 only.
This bug is about adding the same test that was added to 7 to
9 (and the
Thanks Peter, this is a nice improvement. I’ll incorporate your changes before
pushing.
-Chris.
On 5 Feb 2014, at 16:39, Peter Levart wrote:
> On 02/05/2014 04:11 PM, Chris Hegarty wrote:
>> Thanks stuart, Mike, and Paul.
>>
>>> - Why not have getClassSignature() return an interned string? (t
On Feb 6, 2014, at 5:37 AM, Xueming Shen wrote:
> Fair enough. I don't think it's going to be a measurable difference. I have
> updated the webrev
> to use the Character.isSurrogate() for better readability.
>
> http://cr.openjdk.java.net/~sherman/8032012/webrev
>
One last point, sorry :-)
Hi All
Please help to review a simple fix for
https://bugs.openjdk.java.net/browse/JDK-8030844
http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.00/.
Description:
Change replace a “/home/~user" folder with an test source path. Folder
“/home/~user” cause some problem whenever something wrong
On 06/02/2014 05:18, David Holmes wrote:
On 6/02/2014 8:58 AM, roger riggs wrote:
Please review this change to remove unused support in jni_util.c for
functions nativeNewStringPlatform and nativeGetStringPlatformChars.
On Windows, both were conditional on jvm.dll being installed on a path
conta
26 matches
Mail list logo
