hg: jdk8/tl/jdk: 8006568: HTTP protocol handler NLTM Authentication should use Base64 API
Changeset: 33d0175ea8d9 Author:msheppar Date: 2013-01-19 08:39 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33d0175ea8d9 8006568: HTTP protocol handler NLTM Authentication should use Base64 API Reviewed-by: chegar, alanb ! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! test/sun/net/www/protocol/http/ProxyTunnelServer.java
Re: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl
On 15/01/2013 16:48, Lance Andersen - Oracle wrote: Here is a revision http://cr.openjdk.java.net/~lancea/8006139/webrev.01 I still have to enter the JBS entry for the javadoc clarifications (and I also found another javadoc issue that was due to incorrect cut paste when the code was written) and ccc request As i mentioned in an earlier thread, these classes are hardly ever, if at all used and would only be used when UDTs are used and the majority of databases do not support this. It would be good to get the ClassCastException specified when you get time. I looked at the latest webrev and it seems okay to me. SQLInputImpl.getNextAttribute would be bit better if it only incremented idx after retrieving an attribute but that is existing code. Minor intent issue in SQLOutputImpl. writeNClob. -Alan.
Re: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl
On Jan 19, 2013, at 9:43 AM, Alan Bateman wrote: On 15/01/2013 16:48, Lance Andersen - Oracle wrote: Here is a revision http://cr.openjdk.java.net/~lancea/8006139/webrev.01 I still have to enter the JBS entry for the javadoc clarifications (and I also found another javadoc issue that was due to incorrect cut paste when the code was written) and ccc request As i mentioned in an earlier thread, these classes are hardly ever, if at all used and would only be used when UDTs are used and the majority of databases do not support this. It would be good to get the ClassCastException specified when you get time. Yes will do once the ccc is approved on my list I looked at the latest webrev and it seems okay to me. SQLInputImpl.getNextAttribute would be bit better if it only incremented idx after retrieving an attribute but that is existing code. Minor intent issue in SQLOutputImpl. writeNClob. fixed the spacing. going to leave idx alone for now as but will look at this for the future Best Lance -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
hg: jdk8/tl/jdk: 8006139: add missing methods to javax.sql.rowset.serial.SQLInputImpl, SQLOutputImpl
Changeset: 78514544980d Author:lancea Date: 2013-01-19 10:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78514544980d 8006139: add missing methods to javax.sql.rowset.serial.SQLInputImpl, SQLOutputImpl Reviewed-by: naoto, ulfzibis, alanb ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
hg: jdk8/tl/jdk: 8005080: JDBC 4.2 Core changes
Changeset: d3da0d29d7cd Author:lancea Date: 2013-01-19 10:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3da0d29d7cd 8005080: JDBC 4.2 Core changes Reviewed-by: naoto ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/Driver.java ! src/share/classes/java/sql/DriverManager.java + src/share/classes/java/sql/JDBCType.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLTimeoutException.java + src/share/classes/java/sql/SQLType.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Types.java ! src/share/classes/java/sql/package.html ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/XADataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java
Re: Request for review: 8004698: Implement Core Reflection for Type Annotations
Hi Joel, I see, there is a dilema how to cache type annotations. To satisfy single-annotation-returning methods and repeating annotation logic, a HashMap would be a logical choice, but it has much bigger footprint than simple arrays of annotations... I experimented with an idea of using a special purpose immutable Map implementation: https://github.com/plevart/jdk8-tl/blob/anno-map/jdk/src/share/classes/sun/reflect/annotation/UniqueIndex.java and: https://github.com/plevart/jdk8-tl/blob/anno-map/jdk/src/share/classes/sun/reflect/annotation/AnnotationMap.java This is just a preview. I still have to create some tests to see how it compares to HashMap. Being an immutable wrapper for a single array of annotations it has a nice feature that a reference to it can be passed to other threads via a data race with no danger of data inconsistency, which simplifies caching mechanisms and helps scalability. Might even be a space-saving replacement for existing HashMaps of annotations. Depending on performance, of course. What do you think? Is it worth pursuing this further? Regards, Peter On Jan 17, 2013 5:24 PM, Joel Borggrén-Franck joel.fra...@oracle.com wrote: Hi, Here is a webrev for core reflection support for type annotations: http://cr.openjdk.java.net/~jfranck/8004698/webrev.00/ This code is based on the tl/jdk repository, but in order to run the tests you need a javac with type annotations support and also a recent copy of the VM that includes this change set: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35431a769282(This also means this code can't be pushed until all supporting pieces are in place.) Type annotations are still a bit of a moving target so there will be follow up work on this. There is no caching of annotations in this version and I am not sure how we want to do the space/time trade of for type annotations. cheers /Joel
Re: Improving performance and reducing object allocations of java.util.UUID to/from string
Thank you for the feedback! On Jan 10, 2013, at 4:50 AM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: On 01/09/2013 09:51 PM, Steven Schlansker wrote: Hello again, I sent this email a week ago and have received no replies. Is there any step I have missed necessary to contribute to the JDK libraries? I think the crucial part is OCA, as per: http://openjdk.java.net/contribute/ I have now taken care of this :-) The OCA is under the company name Ness Computing and was emailed yesterday. I am very interested in making your lives easier, so please let me know if I am in the wrong place or are otherwise misguided. You are at the correct place. On the first glance, the change looks good for the start. A few comments though: a) Do you need the masks before or-ing with most/leastSigBits? So, they seem to exist to satisfy a few Apache Harmony test cases: http://svn.apache.org/viewvc/harmony/enhanced/java/branches/java6/classlib/modules/luni/src/test/api/common/org/apache/harmony/luni/tests/java/util/UUIDTest.java?revision=929252 For example, uuid = UUID.fromString(123456789-0-0-0-0); Assert.assertEquals(0x23456789L, uuid.getMostSignificantBits()); Assert.assertEquals(0x0L, uuid.getLeastSignificantBits()); Without the masking, the values can smear together. It would be possible to avoid converting extra characters, but I believe that the mask is probably cheaper than an if to check for the presence of extra characters. Were I writing the code from scratch I would throw an IllegalArgumentException on such a UUID but I assume that is not acceptable for compatibility reasons. b) Is there a more standard (and still performant) way to do the hex conversion? Look around JDK source, I think there should be something else needing the same kind of conversion. I didn't see any candidates. I thought of at least the following places to look: Long, String, Formatter, BitSet, and did some general browsing around java.lang and java.util with no luck. The Long methods are in java.lang and so could not be used without making them public. I assume that having private helper methods for my class is preferable to introducing new public methods. It's entirely possible I missed something, but I'm not seeing it. c) I'd go for making utility methods a bit more generic. For one, I would rather make decodeHex(String str, int start, int end), and encodeHex(char[] dest, int offset, int value). I can do this if you feel strongly, but I believe that this compromises the readability of the code. For example, right now you can see: long mostSigBits = decode(str, dashPos, 0); mostSigBits = 16; mostSigBits |= decode(str, dashPos, 1); … whereas to make it use a more general helper it would have to look like this: long mostSigBits = decode(str, dashPos[0]+1, dashPos[1]); mostSigBits = 16; mostSigBits |= decode(str, dashPos[1], dashPos[2]+1); This is an increase from one magic value per invocation to three. It's not a huge difference either way, but I'm not sure that your suggestion is better? I suppose I could make it non-private helper method available to others, although I am not sure if this is considered a good practice in the JDK code. Let me know if you think I should do this. Microbenchmark glitches: a) % is the integer division, and at the scale of the operations you are measuring, it could incur significant costs; the usual practice is having power-of-2 size, and then (i % size) - (i (size - 1)). I fixed this, but it made no meaningful change to the numbers. b) Not sure if you want to stick with random UUIDs for comparisons. While the law of large numbers is on your side, 1000 random UUIDs might be not random enough. I don't believe that this has any bearing on the result. I've run the trials many, many times and the number rarely changes by even 1% from the values that I posted beforehand. If you think this is an actual problem, I can come up with an alternate methodology. I don't think it's a problem. Thanks again for the review. Please let me know if you agree or believe I am mistaken in my analysis above.
