Result: New core-libs Group Member: David Holmes
The vote for David Holmes [1] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. - Alan (nominator) [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008839.html
Result: New core-libs Group Member: Brian Goetz
The vote for Brian Goetz [1] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. - Alan (nominator) [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008836.html
Re: JDK 8 code review request for initial unsigned integer
On 19/01/2012 00:38, Ulf Zibis wrote: 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 to create a new String. I don't think that would be very helpful in this case. If the methods were changed to take a CharSequence, the first action I'd write in the method would be to call toString on the argument; this is necessary to guard against the class of time-of-check-versus-time-of-use problems because the CharSequence objects can be mutable. Doesn't this argument make the usage of CharSequence in most other API's inappropriate at all? It depends. If the parsing requires backtracking then you have to be careful or else parse a copy. -Alan.
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);
if (i 0L)
result = result.add(BEYOND_UNSIGNED_LONG);
return result;
}
That's a nice idea! But the problem is that it would mean that BigInteger.class would be loaded as
soon as Long.class is, which I think is undesirable.
Thanks for the critic. I didn't see that.
The problem could be easily avoided if method toUnsignedBigInteger(long i) would be moved to class
BigInteger as unsignedValueOf(long i), as I additionally noted in my last post.
However it does make me think that we could change...to this:
if (i = 0L) {
return BigInteger.valueOf(i);
} else {
return BigInteger.valueOf(i Long.MAX_VALUE).setBit(63);
}
Another nice idea!
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 to the private value fields.
-Ulf
Re: JDK 8 code review request for initial unsigned integer
The scope of CR 4504839 doesn't cover broader changes to APIs, so the suggestion to upgrade String to CharSequence should be a separate CR to be examined and reviewed separately. The new (and some old) NumberFormatExceptions contain English text preformatted with arguments. From an I18n localization view, that's hard to localize. A fixed string, though less informative could be localized more easily. On 01/19/2012 10:49 AM, Ulf Zibis wrote: 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 a new String. I don't think that would be very helpful in this case. If the methods were changed to take a CharSequence, the first action I'd write in the method would be to call toString on the argument; this is necessary to guard against the class of time-of-check-versus-time-of-use problems because the CharSequence objects can be mutable. Though the existing methods do operate on immutable inputs, there is no expectation of synchronization provided by the parsing methods of Integer, etc. Making the change would not break any existing code because it continues to pass immutable inputs. New code that calls the methods using CharSequences, in full knowledge of the mutability of CharSequences, would manage or avoid the concurrency issues, most likely by keeping the computation to a single thread or otherwise synchronizing changes to the object that implement CharSequence. Since Integer makes no assurances about being multi-thread safe it can operate under those assumptions and does not need to make copies of the arguments. In any case, the copy operation itself could run afoul of concurrency faults, and it doesn't matter where the copy occurs, inside or outside of the Integer methods. Please consider the necessity of extra steps by the developer (to produce strings) and the potential savings in the load on the heap by not creating copies of strings. Roger +1 -Ulf
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 a new String. I don't think that would be very helpful in this case. If the methods were changed to take a CharSequence, the first action I'd write in the method would be to call toString on the argument; this is necessary to guard against the class of time-of-check-versus-time-of-use problems because the CharSequence objects can be mutable. Though the existing methods do operate on immutable inputs, there is no expectation of synchronization provided by the parsing methods of Integer, etc. Making the change would not break any existing code because it continues to pass immutable inputs. New code that calls the methods using CharSequences, in full knowledge of the mutability of CharSequences, would manage or avoid the concurrency issues, most likely by keeping the computation to a single thread or otherwise synchronizing changes to the object that implement CharSequence. Since Integer makes no assurances about being multi-thread safe it can operate under those assumptions and does not need to make copies of the arguments. In any case, the copy operation itself could run afoul of concurrency faults, and it doesn't matter where the copy occurs, inside or outside of the Integer methods. Please consider the necessity of extra steps by the developer (to produce strings) and the potential savings in the load on the heap by not creating copies of strings. Roger +1 -Ulf
Re: JDK 8 code review request for initial unsigned integer
On 19/01/2012 16:17, Roger Riggs wrote: : The new (and some old) NumberFormatExceptions contain English text preformatted with arguments. From an I18n localization view, that's hard to localize. A fixed string, though less informative could be localized more easily. Right but we don't localize exception messages. -Alan
hg: jdk8/tl/jdk: 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck.
Changeset: 313da5d059bf Author:valeriep Date: 2012-01-19 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/313da5d059bf 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. Summary: Changed patternCache from synchronizedMap to ConcurrentHashMap. Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java
JEP 135: Base64 Encoding and Decoding
Posted: http://openjdk.java.net/jeps/135 - Mark
