Re: CharsetEncoder.maxBytesPerChar()

Am 21.09.19 um 00:03 schrieb mark.reinh...@oracle.com: > To avoid this confusion, a more verbose specification might read: > * Returns the maximum number of $otype$s that will be produced for each > * $itype$ of input. This value may be used to compute the worst-case > size > * o

Re: CharsetEncoder.maxBytesPerChar()

Hey Martin, great, that you got my issue. The link you shared is an interesting basis for this discussion. Maybe at some places e.g. in the "upfront specifications", additionally the term "UTF-16 char" or "UTF-16 code unit" could be helpful and then determining "char" or "{@code char}" as a short

Re: RFR 8234147 : Avoid looking up standard charsets in core libraries

Hi Ivan, you may compare your proposal with: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6790402 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6850361 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6796087 -Ulf Am 27.11.19 um 05:39 schrieb Ivan Gerasimov: Hello! It is a

Re: array clone() vs Arrays.copyOf()

Am 27.04.2011 02:34, schrieb David Holmes: 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 be better, and so much better that it warranted Lance changing the code. Perso

Re: array clone() vs Arrays.copyOf()

Am 27.04.2011 11:19, schrieb David Holmes: Ulf Zibis said the following on 04/27/11 19:09: Am 27.04.2011 02:34, schrieb David Holmes: 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

Re: Review (Updated) : 4884238 : Constants for Standard Charsets

No answer ? Especially on: static constant vs. static method -Ulf Am 20.04.2011 13:47, schrieb Ulf Zibis: Am 20.04.2011 02:23, schrieb Mike Duigou: On Apr 19 2011, at 04:52 , Ulf Zibis wrote: I think, we should catch the problem at the source. ... In my approach from Bug 100098 - Make

Re: Unreachable catch classes

Am 27.04.2011 10:40, schrieb David Holmes: Maurizio Cimadamore said the following on 04/27/11 18:35: On 27/04/11 09:18, David Holmes wrote: What I suggested on coin-dev ( which has finally turned up now that someone has unblocked the openjdk mail pipes ;-) ) is that instead of doing an analysi

Re: Review (Updated) : 4884238 : Constants for Standard Charsets

No answer ? Especially on: static constant vs. static method -Ulf Am 20.04.2011 13:47, schrieb Ulf Zibis: Am 20.04.2011 02:23, schrieb Mike Duigou: On Apr 19 2011, at 04:52 , Ulf Zibis wrote: I think, we should catch the problem at the source. ... In my approach from Bug 100098 - Make

Re: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

Interesting results! Some days ago we had the discussion about constants for standard Charsets. Looking at your results, I see, that using *charset names constants*, the conversion mostly performs little better (up to 25 %), than using *charset constants*. So again my question: Why do we need

Re: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

According to comments in 6795537 I additionally assume else if (b1< (byte)0xc2) should be little faster than else if ((b1>> 5) == -2) and if (isMalformed2(b1, b2)) could be replaced by if (isNotContinuation(b2)) -Ulf Am 28.04.2011 14:44, schrieb Ulf Zibis: In

Re: hg: jdk7/tl/jdk: 2 new changesets

Hey Mike, why didn't you follow Mark's explanation about the naming for StandardCharset(s) ? Did you have had other discussions internally? -Ulf Am 27.04.2011 23:18, schrieb mike.dui...@oracle.com: Changeset: 5b05f8d1c0e5 Author:mduigou Date: 2011-04-26 14:25 -0700 URL: http:

Re: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

Am 28.04.2011 21:56, schrieb Xueming Shen: That said, you do have the point, we should do better even in malformed case, ... Yes, that's what I wanted to point on. But I thought, you could go 1 step further, declaring bb as member of UTF_8.Decoder. Then it should be guaranteed, the a decoder is

Re: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

Am 28.04.2011 23:28, schrieb Xueming Shen: On 04/28/2011 01:55 PM, Ulf Zibis wrote: Am 28.04.2011 21:56, schrieb Xueming Shen: That said, you do have the point, we should do better even in malformed case, ... Yes, that's what I wanted to point on. But I thought, you could go 1 step fu

Re: hg: jdk7/tl/jdk: 2 new changesets

x27;t seem to be leading anywhere but inaction and there are other issues (always) that need attention. Mike On Apr 28 2011, at 10:15 , Ulf Zibis wrote: Hey Mike, why didn't you follow Mark's explanation about the naming for StandardCharset(s) ? Did you have had other discuss

Re: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

Am 29.04.2011 02:11, schrieb Xueming Shen: On 04-28-2011 3:46 PM, Ulf Zibis wrote: It's safe to say that java.nio.cs.StandardCharset is not for String.getBytes()/toCharArray() only, so the fact that "cs" variant of String.getBytes()/toCharArray() is "slower" than i

Re: StandardCharset vs. StandardCharsets

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 use case should be: String.getBytes(...) On

Re: StandardCharset vs. StandardCharsets

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 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

Re: StandardCharset vs. StandardCharsets

Am 08.05.2011 10:33, schrieb Xueming Shen: On 5/7/2011 10:55 AM, Ulf Zibis wrote: I agree 50 %. 100 % would be to have: byte[] String.getBytes(CharsetEncoder encoder) String(byte[] bytes, CharsetDecoder decoder) So for convenience in consequence we should introduce constants for

Re: StandardCharset vs. StandardCharsets

Am 08.05.2011 11:13, schrieb Ulf Zibis: Am 08.05.2011 10:33, schrieb Xueming Shen: On 5/7/2011 10:55 AM, Ulf Zibis wrote: I agree 50 %. 100 % would be to have: byte[] String.getBytes(CharsetEncoder encoder) String(byte[] bytes, CharsetDecoder decoder) So for convenience in

Re: Is it finally time to remove the sun.io converters?

As replacement for the 323 classes in original sun.io you could use my wrapper classes: http://java.net/projects/java-nio-charset-enhanced/sources/svn/show/trunk/src/sun/io/ There remain only 8 classes. -Ulf Am 13.06.2011 18:03, schrieb Alan Bateman: The JDK hasn't used the legacy sun.io co

Re: Is it finally time to remove the sun.io converters?

Am 14.06.2011 10:25, schrieb Alan Bateman: Ulf Zibis wrote: As replacement for the 323 classes in original sun.io you could use my wrapper classes: http://java.net/projects/java-nio-charset-enhanced/sources/svn/show/trunk/src/sun/io/ There remain only 8 classes. I think this should be backup

Re: Bug 4715154

+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 I finally figured out it was a known issue. --Sean On 6/27/11 9

Re: Return type of Object.getClass()

Am 30.06.2011 23:16, schrieb Zhong Yu: Why does it return Class instead of Class? Quote: The actual result type is Class where |X| is the erasure of the static type of the expression on which getClass is called. This means the following code does not compile T obj = ...; Class claz

Re: Contribution to Bug 100120

At least: - provide a formal patch as attachment to bug 100120 - pray for a sponsor - pray, the sponsor would have time ;-) -Ulf Am 24.07.2011 09:18, schrieb Peter Lawrey: Hello, I am trying to following the http://openjdk.java.net/contribute/ What is the next step to progressing bug https://

Re: Any chance to see EnumSet implement SortedSet in JDK8?

Am 12.08.2011 01:03, schrieb Joe Darcy: Hello. On 8/11/2011 1:56 PM, Rémi Forax wrote: 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 bu

Re: Request for review 6237353: Remove sun.io package from j2se binary

As a consequence, allmost all classes in sun.nio.cs and templates in make/tools/CharsetMapping could be made package private, at least all access to the mapping tables! ... and don't forget to remove in each sun.nio.cs class and template: /** * These accessors are temporarily supplied

Re: Request for review 6237353: Remove sun.io package from j2se binary

Sherman, thanks. There are some more public sun.io-bridge-methods which could be saved or at least made package-private, e.g.: - EUC_TW.Encoder.toEUC() - EUC_TW.Decoder.toUnicode() - DoubleByte.Encoder.encodeChar() - DoubleByte.Decoder.decodeSingle() - DoubleByte.Decoder.decodeDouble() - Double

Re: Enumeration adapters in SE 8

Some other candidates for Iterable: Bug 6793773 - Let CharsetProvider implement Iterable Bug 6935695 - String should implement Iterable -Ulf Am 25.08.2011 10:19, schrieb

Re: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized

Sherman, IMHO, synchronizing multiple call site does NOT look good to me. On next chance, someone other calls lookup() without knowing, that it has to be synchronized. Please simply synchronize lookup() itself, maybe in sophisticated way (only the necessary part of the code). The same seems to

Re: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized

Am 02.09.2011 13:34, schrieb Alan Bateman: Rémi Forax wrote: Arghhh, next() can return null ! CharsetProvider provider = ... Iterator it = provider.charsets(); Iterator it2 = provider.charsets(); Charset charset = it.next(); provider.deleteCharset(charset.name(), ...) System.out.println(it2.ne

Re: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized

Am 02.09.2011 15:40, schrieb Rémi Forax: 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

Re: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized

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 as parameter of init. The idea is that during th

Re: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math"

Without a deeper look, I discovered several ternary operators without spacing. For better readability, it would be nice to insert some spaces. :-) -Ulf Am 17.09.2011 03:52, schrieb joe.da...@oracle.com: Hello. Please review the changes to address 7091682 "Move sun.misc.FpUtils code into j

Re: Review Request: 7088913/7088952 : Additions to primitive wrappers

Hi, why don't we have Boolean.SIZE and Boolean.BYTES ? -Ulf Am 20.09.2011 22:11, schrieb Mike Duigou: Hello all; Here's a webrev for two small additions to the primitive wrapper types (Boolean, Byte, Character, Double, Float, Integer, Long, Short). http://cr.openjdk.java.net/~mduigou/70

Re: Review Request: 7088913/7088952 : Additions to primitive wrappers

ingle answer. Mike On Sep 21 2011, at 03:36 , Ulf Zibis wrote: Hi, why don't we have Boolean.SIZE and Boolean.BYTES ? -Ulf Yep, not easy to make a right decision here. One if the questions might be, if SIZE/BYTES are meant as resolution (2**SIZE = number of distinct values) or as memor

Re: Review Request: 7088913/7088952 : Additions to primitive wrappers

Am 22.09.2011 12:04, schrieb David Holmes: On 22/09/2011 7:40 PM, Ulf Zibis wrote: Yep, not easy to make a right decision here. One if the questions might be, if SIZE/BYTES are meant as resolution (2**SIZE = number of distinct values) or as memory usage. I would say: SIZE should be meant as

Re: Review Request: 7088913/7088952 : Additions to primitive wrappers

The bug id links in your webrev do not work for me: 7088913 7088952 -Ulf Am 20.09.2011 22:11, schrieb Mike Duigou: Hello all; Here's a webrev for two small additions to the primitive wrappe

Re: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math"

I'm wondering why you don't have moved concerning documentation from sun.misc.* to java.lang.(Strict)Math. E.G.: The comment on the scalb operations: /* * The scalb operation should be reasonable ... */ To save some source code footprint and allow better overview, I suggest to erase all javado

Re: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math"

Am 22.09.2011 19:18, schrieb Ulf Zibis: I'm wondering why you don't have moved concerning documentation from sun.misc.* to java.lang.(Strict)Math. E.G.: The comment on the scalb operations: /* * The scalb operation should be reasonable ... */ To save some source code footprint

Re: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math"

Am 23.09.2011 01:29, schrieb Joe Darcy: On 9/22/2011 2:07 PM, Ulf Zibis wrote: Am 22.09.2011 19:18, schrieb Ulf Zibis: I'm wondering why you don't have moved concerning documentation from sun.misc.* to java.lang.(Strict)Math. E.G.: The comment on the scalb operations: /* *

Re: Review Request: 7088913/7088952 : Additions to primitive wrappers

Am 24.09.2011 01:57, schrieb Mike Duigou: On Sep 22 2011, at 14:34 , David Holmes wrote: On 22/09/2011 11:23 PM, Ulf Zibis wrote: Am 22.09.2011 12:04, schrieb David Holmes: On 22/09/2011 7:40 PM, Ulf Zibis wrote: Yep, not easy to make a right decision here. One if the questions might be

Re: Codereview request for 7082884: Incorrect UTF8 conversion for sequence ED 31

Am 19.09.2011 22:21, schrieb Xueming Shen: The current implementation decode new String(new byte[]{(byte)0xed, 31}, "UTF8") Bug 7082884 refers to ED 31, so it should be: new String(new byte[]{(byte)0xed, 0x31}, "UTF8") -Ulf

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Hi Sherman, 1. bug 7096080 is not visible at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7096080 2. bug 7096080 seems to be a duplicate of 6798514 - Charset UTF-8 accepts CESU-8 codings which was closed. It should be reopened

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Hi, Am 29.09.2011 05:27, schrieb Xueming Shen: Hi, On 9/28/2011 3:44 PM, Ulf Zibis wrote 3. Consider additionally 6795537 - UTF_8$Decoder returns wrong results <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795537> (1) new byte[]{(byte)0xE1, (byte)0x80, (byt

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Am 30.09.2011 22:46, schrieb Xueming Shen: On 09/30/2011 07:09 AM, Ulf Zibis wrote: (1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42} ---> CoderResult.malformedForLength(1) It appears the Unicode Standard now explicitly recommends to return the malformed length 2, what UTF-8 is doing

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Am 02.10.2011 08:29, schrieb Xueming Shen: http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf Go to 3.9 Unicode Encoding Forms. Or simply search D93 On 10/1/2011 2:21 PM, Ulf Zibis wrote: Am 30.09.2011 22:46, schrieb Xueming Shen: On 09/30/2011 07:09 AM, Ulf Zibis wrote: (1) new byte

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Hi again, Am 30.09.2011 00:27, schrieb Xueming Shen: On 09/29/2011 02:16 PM, Ulf Zibis wrote: 280 if (Character.isSurrogate(c)) 281 return malformedForLength(src, sp, dst, dp, 3); Shouldn't we return cr.length() = 1to allow remaining 2 bytes

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Hi Sherman, I didn't read anything from you since longer time. You are in holidays? Am 30.09.2011 22:46, schrieb Xueming Shen: I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to 2009(?) because the benchmark shows the "shift" version is slightly faster. Do you have any number sho

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Am 11.10.2011 13:36, schrieb Ulf Zibis: I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to 2009(?) because the benchmark shows the "shift" version is slightly faster. Do you have any number shows any difference now. My non-scientific benchmark still suggests

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Am 11.10.2011 19:49, schrieb Xueming Shen: I don't know which one is better, I did a run on private static boolean op1(int b) { return (b >> 6) != -2; } private static boolean op2(int b) { return (b & 0xc0) != 0x80; } private static boolean op3(byte b) {

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Am 13.10.2011 21:13, schrieb Xueming Shen: On 10/13/2011 09:55 AM, Ulf Zibis wrote: Am 11.10.2011 19:49, schrieb Xueming Shen: I don't know which one is better, I did a run on private static boolean op1(int b) { return (b >> 6) != -2; } private static boolea

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Am 30.09.2011 22:46, schrieb Xueming Shen: I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to 2009(?) because the benchmark shows the "shift" version is slightly faster. Do you have any number shows any difference now. My non-scientific benchmark still suggests the "shift" type is f

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Am 14.10.2011 10:47, schrieb Ulf Zibis: My new guess for the reason: The unfolding of the bytes to int to serve the isNotContinuation / isMalformedxx methods. So those methods should be coded in byte logic too. + use the "bx <= (byte)abc" logic instead "shift" or "(bx & abc) != def". -Ulf

Re: Code Review 7104650: rawtype warnings in java.nio.charset.Charset and sun.nio.ch.Util

All looks fine to me. -Ulf Am 25.10.2011 16:32, schrieb Chris Hegarty: Alan, I found the same problem in the net and security makefiles, incremental build fails because of raw type warnings. I can file another CR or amend the category and description of this one, to be more generic. The

Bug 6963115 - String.split() returns wrong result on short sequence

Hi, I do not agree to the evaluation on http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6963115 because: > Same as the "x".split("x") case, this is a "match found" situation, > the resulting empty string is now a "trailing empty string", Yes, but don't forget the leading empty string. In m

Re: JEP 112: Charset Implementation Improvements

Great! I like to be part of it. -Ulf Am 28.10.2011 18:46, schrieb mark.reinh...@oracle.com: Posted: http://openjdk.java.net/jeps/112 - Mark

Who is on Dedoxx?

Hi all, I want to know, if there are any members of the list participating on the Devoxx Conference next week. Thanks for your response, -Ulf

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Hi Sherman, 2 nits again: protected static final class Encoder extends CharsetEncoder - If final, protected doesn't make sense, as it can't be subclassed. (ideally this should be a compiler error) - Where is it used? Otherwise it could be private. -Ulf Am 07.11.2011 21:30, schrieb Xueming Sh

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

11 22:28, schrieb Xueming Shen: Hi Ulf, Good catch. It was the leftover of my first drift, in which CESU.de/encoder is the subclass of the UTF8 de/encoder. webrev has been updated accordingly. -Sherman On 11/07/2011 12:57 PM, Ulf Zibis wrote: Hi Sherman, 2 nits again: protected static final

Re: Who is on Dedoxx?

Hi Dalibor, thanks for the invitation. Can one explain me what BOF stands for? The Devoxx is totally overbooked, so no chance to come. Anyway I do not have an employer sponsering me the fee. :-( Thanks for all your answers, Ulf Am 07.11.2011 20:28, schrieb Dalibor Topic: On 11/7/11 8:20 PM

Re: Re : what is the most precise time I can get in JDK?

Sounds interesting, but there is no attachment ? -Ulf Am 18.11.2011 20:35, schrieb Jeff Hain: Hi. I've had the same need (or desire), and made a ThinTime class for it (attached). Returned time : - is not much more inaccurate than System.currentTimeMillis(), - is always ahead of System.curren

Re: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer

Hi Sherman, I would like a different computation of the percentages: Am 23.11.2011 00:26, schrieb Xueming Shen: Lengthbyte[](ns/len) ByteBuffer(direct) ByteBuffer 1 13,409,610 2,990,525 ( 77%) 13,196,357 ( 1%) checksum=bd00bd 2 5,808,804 1,664,460 ( 71%)

Re: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer

Sherman, what is the magic behind, that the adler32 function runs faster on BirectBuffer than on byte[]? Is it GetPrimitiveArrayCritical(env, b, 0) + ReleasePrimitiveArrayCritical(env, b, buf, 0) ? Am 24.11.2011 23:47, schrieb Xueming Shen: Alan, Ulf, Webrev has been updated accordingly (1)

Re: zlib 1.2.3 -> 1.2.5

Would zlib 1.2.3 remain in JDK8 repo alongside 1.2.5 ? -Ulf Am 28.11.2011 23:06, schrieb Xueming Shen: Hi, Here is the webrev for upgrading the bundled zlib from 1.2.3 to 1.2.5 for JDK8 http://cr.openjdk.java.net/~sherman/7110149/webrev The changes to the original zlib source code (other tha

Re: zlib 1.2.3 -> 1.2.5

Am 29.11.2011 11:23, schrieb Alan Bateman: When we talked about the zlib version here (I think back in February) we talked about having the option to use the system's zip library where appropriate. Have you given this any thought recently? +1 Ulf

Re: A behavior mismatch in AbstractCollection.toArray(T[] )

Am 13.12.2011 08:41, schrieb David Holmes: Hi Sean, On 13/12/2011 5:21 PM, Sean Chou wrote: When I was reading the code of AbstractCollection.toArray(T[] ), I found its behavior maybe different from the spec in multithread environment. The spec says "If the collection fits in the specified arra

Re: A behavior mismatch in AbstractCollection.toArray(T[] )

Am 13.12.2011 12:18, schrieb Sean Chou: Hi , Is it possible to change the spec ? I found it is defined in java.utils.Collection interface. It would be easy for AbstractCollection to state that it is not designed for concurrent operations, and its subclass should take care of them. +1 -U

Re: A behavior mismatch in AbstractCollection.toArray(T[] )

IMO in 99.8 % this check would be superfluous overhead. For those, who want 100 %, they can check and copy in their code. -Ulf Am 13.12.2011 14:30, schrieb Sean Chou: Sorry for the confuse. By "ok", I mean "compare the size of array which is going to be returned and the size of the specified ar

Re: JDK 8 code review request for initial unsigned integer

Am 18.01.2012 21:09, schrieb Joe Darcy: Hi Roger, On 01/18/2012 11:21 AM, Roger Riggs wrote: 1. In the new parsing methods, could the String arguments be changed to the more general java.lang.CharSequence? For many parsing applications, it could be more convenient to pass a CharSequence than

Re: JDK 8 code review request for initial unsigned integer arithmetic library support

Am 18.01.2012 03:54, schrieb Joe Darcy: I've posted a revised webrev at http://cr.openjdk.java.net/~darcy/4504839.2 Instead '\u0030' you can use {@code '\u005Cu0030'} Byte: = 459 public static int toUnsignedInt(byte x) { 460 return ((int) x) & 0xff; 461 } This s

Re: JDK 8 code review request for initial unsigned integer arithmetic library support

Am 19.01.2012 07:43, schrieb Eamonn McManus: Ulf Zibis writes: > What about: > private static final BigInteger BEYOND_UNSIGNED_LONG = BigInteger.valueOf(1).shiftLeft(64); > private static BigInteger toUnsignedBigInteger(long i) { > BigInteger result = BigInteger.valueOf(i);

Re: JDK 8 code review request for initial unsigned integer

Am 18.01.2012 22:20, schrieb Roger Riggs: On 01/18/2012 03:09 PM, Joe Darcy wrote: 1. In the new parsing methods, could the String arguments be changed to the more general java.lang.CharSequence? For many parsing applications, it could be more convenient to pass a CharSequence than to create

Re: JDK 8 code review request for initial unsigned integer arithmetic library support

A little different approach... I worry about the wording of e.g. toUnsignedInt(x). At first look, it claims to return an unsigned integer, which fairly doesn't exist in Java for now. 1. Better: unsignedIntValueOf(x) 2. We could have a naming problem if unsigned integers were introduced in any fu

Re: JDK 8 code review request for initial unsigned integer arithmetic library support

Am 20.01.2012 16:12, schrieb Ulf Zibis: A little different approach... Instead e.g. int Byte.unsignedIntValueOf(byte x) aka int Byte.toUnsignedInt(byte x) I would vote for int Integer.unsignedValueOf(byte x) Alternative: int Integer.valueAsUnsigned(byte x) -Ulf

Re: JDK 8 code review request for initial unsigned integer arithmetic library support

Thanks for your feedback. Am 21.01.2012 01:31, schrieb Joseph Darcy: On 1/18/2012 7:52 PM, Ulf Zibis wrote: Am 18.01.2012 03:54, schrieb Joe Darcy: I've posted a revised webrev at http://cr.openjdk.java.net/~darcy/4504839.2 Instead '\u0030' you can use {@code '

Re: JDK 8 code review request for initial unsigned integer arithmetic library support

Am 21.01.2012 01:35, schrieb Joseph Darcy: On 1/19/2012 8:05 AM, Ulf Zibis wrote: But again, moving the entire method to BigInteger would additionally avoid to clown around with the available BigInteger's public APIs. Having the method at BigInteger would allow elegant direct access t

Re: JDK 8 code review request for 7132338 Use @code friendly idiom for '\' in javadoc

Am 23.01.2012 11:33, schrieb Alan Bateman: On 23/01/2012 08:23, Joe Darcy wrote: With these changes, the javadoc builds runs without additional warnings and a specdiff against a reference copy of the javadoc shows no unexpected changes. I'm wondering because of ... error, Alan pointed out. In

Re: JDK 8 code review request for 7132338 Use @code friendly idiom for '\' in javadoc

Am 23.01.2012 18:53, schrieb Joe Darcy: Well, there is the make/scripts directory in the the top-level JDK repository forest. Could you please publish your script there? (maybe via this patch) Joe, thanks for catching my change proposal. Would like to see me as contributor :-) I meant via

Re: Using unsigned library work in the JDK

Am 26.01.2012 17:11, schrieb Roger Riggs: Is there any performance impact of the method call vs the &0xff? Hotspot will in-line the code but for VMs with less sophisticated optimizations it will be a net loss. +1 At least in interpreter and maybe -client compiler the new code would have perform

Re: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods

Am 30.01.2012 13:19, schrieb Tom Hawtin: A better solution to the unchecked casts from clone, is not to clone. Using a constructor gets rid of the problem, and ensures you aren't using some funky (potentially malicious) subclass. -return (Hashtable)_env.clone(); +return

Re: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods

Am 30.01.2012 14:28, schrieb Tom Hawtin: On 30/01/2012 13:16, Ulf Zibis wrote: Isn't cloning faster than normal instantiation? I can imagine, that behind the scenes cloning mainly only needs to duplicate the binary footprint of an object. I don't see a good reason why it should b

Re: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods

Am 30.01.2012 07:52, schrieb Rémi Forax: WTF ! while it's maybe a binary compatible change, I haven't take a look to all modified classes to be sure it's not a source compatible change. People had created class that inherits from ArrayList and override clone, while it's not a good practice, t

Re: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods

Sent from my phone On Jan 30, 2012 4:08 PM, "Ulf Zibis" wrote: Am 30.01.2012 14:28, schrieb Tom Hawtin: On 30/01/2012 13:16, Ulf Zibis wrote: Isn't cloning faster than normal instantiation? I can imagine, that behind the scenes cloning mainly only needs to duplicate t

Re: Using unsigned library work in the JDK - please rename them!

Hi again, isn' there any chance for a renaming? I think, e.g., +return unsigned(b[n]) | (unsigned(b[n + 1]) << 8); would be much more writeable + readable than ... +return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n + 1]) << 8); In 2nd case, static import is not p

Re: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

I agree with the fix. In test/java/io/OutputStreamWriter/Flush.java I suggest: a) As all values are positive, following would be better readable: byte[] bytes = new byte[] {0x1b, 0x24, 0x42, 0x3a, 0x47, 0x1b, 0x28, 0x42}; ... or remember the format rule - which I still don't like - to insert

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

Interesting issue, especially for us germans! What is about System.in, if one types some umlaute at Windows console? Why are there theoretically different code pages for stdout and stderr? -Ulf Am 13.02.2012 18:36, schrieb Xueming Shen: Hi This is a long standing Windows codepage support is

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

Am 13.02.2012 19:35, schrieb Xueming Shen: On 2/13/2012 10:15 AM, Ulf Zibis wrote: Interesting issue, especially for us germans! What is about System.in, if one types some umlaute at Windows console? System.in is a "InputStream", no charset involved there, you build your own &

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

Sherman, thanks for your additional explanation. One nit more... Why you use the "sun." prefix? I think, "stdout.encoding" "stderr.encoding" would be enough + nicer. In some years, nobody will have any association with 'sun'. On the other hand, it would be more true to use: "windows

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

On 2/13/2012 11:07 AM, Bill Shannon wrote: Can you detect the case of creating an InputStreamReader using the default encoding, wrapped around the InputStream from System.in that refers to the console? If so, it might be good to handle that case as well, although at this point I would conside

Re: Re : Review: JDK 8 CR for Support Integer overflow updated

Am 14.02.2012 00:41, schrieb Jeff Hain: (I don't really like the term "exact", which supposes modulo arithmetic is not exact in its kind, and it doesn't contain the supposition that the result should be in range.) +1 -Ulf

Re: java.io.File field "path" is not declared final

Am 17.02.2012 13:54, schrieb Rémi Forax: On 02/17/2012 01:41 PM, Alan Bateman wrote: I understand, I just remarking that I probably would have used a volatile store for both to make it clearer but that would be less efficient. Knowing that some codes already serialize File instances, I wanted

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Am 09.03.2012 10:53, schrieb David Holmes: Hi Sean, That seems to implement the required semantics. Minor style nit: }else{ -> } else { There are some more in lines 183, 184, 188. Not sure about the testcase ... Can size() not remove some elements directly but return the original size? Go

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Am 09.03.2012 09:16, schrieb Sean Chou: Hi all, AbstractCollection.toArray(T[] ) might return a new array even if the given array has enough room for the returned elements when it is concurrently modified. This behavior violates the spec documented in java.util.Collection . This patch

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Nice work! Especially the saving of the sleep times. Regarding your Infrastructure: It is stated, that jtreg is able to process standard JUnit testcases, so IMHO there is no need to recode similar infrastructure. I think you could stay at name CollectionToArray, so Bug 7121314 would be one par

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Am 09.03.2012 09:16, schrieb Sean Chou: Hi all, AbstractCollection.toArray(T[] ) might return a new array even if the given array has enough room for the returned elements when it is concurrently modified. This behavior violates the spec documented in java.util.Collection . This patch

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Am 10.03.2012 13:42, schrieb David Holmes: On 9/03/2012 11:39 PM, Ulf Zibis wrote: Regarding your Infrastructure: It is stated, that jtreg is able to process standard JUnit testcases, so IMHO there is no need to recode similar infrastructure. I simply copied am existing test

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Am 10.03.2012 13:52, schrieb David Holmes: On 10/03/2012 12:02 PM, Ulf Zibis wrote: Why don't we have public T[] toArray(T[] a) ? This would prevent from the cast r[i] = (T)it.next(); It's too late to change the method signature now. Sorry about my english, I meant why don

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Am 13.03.2012 07:58, schrieb Sean Chou: Hi Ulf and David, I modified the patch and added the testcase, it's now : http://cr.openjdk.java.net/~zhouyx/7121314/webrev.02/ . Ulf's compact version is used, it looks beautiful; T

Re: CR 7148271 REGESSION with PNG Image loading

Am 13.03.2012 20:03, schrieb Xueming Shen: While this indeed is a "regression", the question is do we really want this behavior (allow those corrupt zip/png files without throwing exception) to be the default behavior? A possible approach is to by default the j.u.zip.Inflater/PNGImageReader rejec

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

s bug, not 7121314 . My complain was in assumption, that a test, named t.j.u.AC.ToArray, should test the whole complexity of method toArray(), not just concerning a single bug. -Ulf On Wed, Mar 14, 2012 at 7:36 AM, Ulf Zibis mailto:ulf.zi...@gmx.de>> wrote: Am 13.03.2012 07:58, sch

  1   2   3   4   5   6   7   8   9   10   >