http://blog.gmane.org/gmane.comp.java.openjdk.core-libs.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10310 <pre>Attached is the fix for 7171918. If a WebRowSet is written to disk that contains a row marked for deletion and then read back into a WebRowSet, it was not marked again as a deleted row. Here is the fix to endElement() to address this. hg diff XmlReaderContentHandler.java diff -r 4580652d9828 src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java --- a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.javaFri May 04 16:00:47 2012 -0400 +++ b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.javaFri May 25 15:52:21 2012 -0400 &lt; at &gt;&lt; at &gt; -764,6 +764,7 &lt; at &gt;&lt; at &gt; rs.next(); rs.setOriginalRow(); applyUpdates(); + rs.deleteRow(); } catch (SQLException ex) { throw new SAXException(MessageFormat.format(resBundle.handleGetObject("xmlrch.errdel").toString() , ex.getMessage())); Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen-QHcLZuEGTsvQT0dZR+AlfA&lt; at &gt;public.gmane.org </pre> Lance Andersen - Oracle 2012-05-25T19:56:41 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10309 <pre>Attached is the fix for bug 171917 . The populate() method needs to check for a size of 0 for the map in case a webrowset xml file has an empty map tag, which would result in calling setobject specifying a map and not all databases/drivers support this. simple 1 line change: hg diff CachedRowSetImpl.java diff -r 4580652d9828 src/share/classes/com/sun/rowset/CachedRowSetImpl.java --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.javaFri May 04 16:00:47 2012 -0400 +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.javaFri May 25 15:45:29 2012 -0400 &lt; at &gt;&lt; at &gt; -659,7 +659,7 &lt; at &gt;&lt; at &gt; * us work with drivers that do not support * getObject with a map in fairly sensible way */ - if (map == null) { + if (map == null || map.size() == 0) { obj = data.getObject(i); } else { obj = data.getObject(i, map); Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen-QHcLZuEGTsvQT0dZR+AlfA&lt; at &gt;public.gmane.org </pre> Lance Andersen - Oracle 2012-05-25T19:50:39 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10304 <pre>Hi, Please review, changes has been internally reviewed by John. http://cr.openjdk.java.net/~ksrini/7168401/webrev.0/ Thanks Kumar </pre> Kumar Srinivasan 2012-05-25T15:31:03 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10255 <pre>Hi, This is a minor change to java_props_md.c to return "Windows 8" as the "os.name" for Windows version 6.2. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169 Webrev: http://cr.openjdk.java.net/~khazra/7170169/webrev.00/ Thanks, Kurchi </pre> Kurchi Hazra 2012-05-23T01:32:23 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10249 <pre>Just hit me now, from a utf-8 document http://closingbraces.net/2008/11/11/javastringtrim/ Anyway, any plans to deprecate trim() and add a new one? I for one would refactor all my projects with it. </pre> Paulo Levi 2012-05-21T07:13:04 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10247 <pre>Hi, Fixed CR reference in test. http://cr.openjdk.java.net/~ksrini/7170087/ The original changset for reference. http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f68c854fa584 Thanks in advance. Kumar </pre> Kumar Srinivasan 2012-05-18T22:04:14 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10237 <pre>Changeset: df33f5f750ec Author: dsamersoff Date: 2012-05-15 16:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df33f5f750ec 7164191: properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario Reviewed-by: dholmes, sla Contributed-by: Deven You &lt;youdwei-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8&lt; at &gt;public.gmane.org&gt; ! src/share/classes/sun/management/Agent.java + test/sun/management/AgentCMETest.java </pre> dmitriy.samersoff-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org 2012-05-15T12:49:20 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10226 <pre>Hi, This change aims at removing some rawtype usages in src/macosx/classes/java/util/prefs that were brought into jdk8 with the macport. I have added &lt; at &gt;Override tags too where applicable. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636 Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/ Thanks, Kurchi </pre> Kurchi Hazra 2012-05-11T21:46:21 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10203 <pre>Hello all; A benign but potentially expensive race condition was discovered in java.util.UUID. The initialization of numberGenerator may cause the creation of a number of SecureRandom instances if multiple threads are attempting to initialize the field at the same time. This can happen because creation of the SecureRandom instances, depending upon system configuration and state, may take a significant amount of time. Using a shared SecureRandom instance for the numberGenerator is an optimization--nothing bad happens as a result of each thread using it's own instance. However, creation of multiple SecureRandom instances, especially during system startup, may be expensive or have high latency if no previous SecureRandom instances have been created. Accordingly, a holder class is used to ensure that only a single SecureRandom instance is created. The holder also serves to defer initialization of numberGenerator until randomUUID() is first called. Webrev: http://cr.openjdk.java.net/~mduigou/7071826/0/webrev/ This issue will be proposed for backport to Java 7u6 once integrated into Java 8 Thanks, Mike </pre> Mike Duigou 2012-05-10T23:11:30 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10154 <pre>Hi All, There is a potential problem in jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp. (Maybe it is not suitable for posting this on core-lib, anyone could tell me which mailing list is prefer?) L85: JNI_GetCreatedJavaVMs(&amp;vm, 1, null) in which the 3rd parameter is a pointer to an integer. See[1], the latest JNI Invocation API spec does not say anything about allowing a null as the last parameter. I think it is more reasonable to change null to an integer variable. Here is my fix[2] [1] http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html#wp633 [2] http://cr.openjdk.java.net/~littlee/ojdk-432/webrev.00/ &lt;http://cr.openjdk.java.net/%7Elittlee/ojdk-432/webrev.00/&gt; Please review this mail! Thanks a lot! </pre> Deven You 2012-05-07T09:38:46 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10141 <pre>Please review this fix for making the jdk regression tests for rmi activation run faster. It brings a near to x2 speed factor on a Solaris/SPARC machine. The webrev for the fix is here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/ This is a speedup only fix that does not attempt to cleanup the rmi/testlibrary code and minimizes the changes. The fix consists in applying what is described as suggestedFix(Entry 1) in bug page(see http://monaco.sfbay.sun.com/detail.jsf?cr=7144861). It mainly reduces long (seconds) waiting times steps by several much shorter ones (second tenthes) that have been chosen to minimize and keep usefull the waiting loops. These waiting time values are hardcoded, as were before the fix. The additional possible fixes described in suggestFix/Entry2 (grouping jtreg &lt; at &gt;build tags, and reducing waiting time in tests) are *not* applied here. Below is the detailed list of changes. Thanks, Olivier. Here are the details of the changes I did: ---------------------------------------------b. - testlibrary/JavaVM.java : rather than waiting once for an "hopefully sufficient" time of 2secs at the end of start() method, a way to know when the vm is really started has been added with the help of redirected buffers in StreamPipe : in StreamPipe.run(), as soon as we have something to read in the vm output buffer, it means the distant vm can be considered started, and thus a synchronized JavaVM.started() method that sets-up a javaVM "started" status is called. We force such an output in the default case (most used one) by prepending "-showversion" flag in the command line running distant vm process. At the end of JavaVM.start(), we loop and wait by steps of 100msecs to check for the "started" status until the started status is set or max bound time is reached (keeping the initial max of 2secs bound). If bound is reached without seeing started flag set, vm is consiedered started anyway. We keep the previously existing way of starting the vm and using streamPipe for the cases where we don't want child vm to output anything or if we don't have any control of child process (when started without using JavaVM constructor/start). In a usual jtreg env, 3 loops are most often enough (300msecs), with a max of 700msecs seen from numerous trials. - testlibrary/StreamPipe : this is all described here above. - testlibray/RMID : start() method: the existing waiting time slices have been reduced to 100msecs, before calling rmidRunning(). These were/are useless since rmidRunning() also does such waiting loops, but the intention is not to cleanup testlibrary code to avoid confusion and mixing things. So just reduced the waiting time slices. Most of the times 1 such waiting step is enough, since rmidRunning does the same kind of loops. So we most often see rmid running after 300msecs most often, with an observed max of 1.1sec. shutdown() : suppressed useless sleep(5000) which is better handled in destroy() method. Provide additional status on communication status with distant rmid. destroy() : Added a waiting loop on process.exitvalue() (by steps of 200msecs) to have more chances to see distant rmid process terminates gracefully, while being faster. The max waiting time bound here is 60secs (300 steps). Observed needed time varies between 600msecs and 3secs. - testlibrary/ActivationLibrary : deactivate(): Waiting time steps reduced from 1000msecs to 100, enlarging the number of steps to 50 (kept total waiitng time of 5secs). In almost all cases 1 waiting step is enough, sometimes up to 5, and only for CheckImplClassLoader we occasionnally never see inactive call succeeding. rmidRunning() : Reduced the waiting time slice to 100msecs and added some communication/exception status info. Kept the max waiting time bound of 7.5secs. In most cases 300msecs (3 steps) is enough. - CheckUsage test: main() : suppressed useless sleep of 7secs. - NoConsoleOutput test: main() : the only observed test to expect no output from distant vm. Thus using previously existing method for instantiating/starting distant vm, with a fixed waiting time of 2secs. -----------------------------------------------------------e. </pre> Olivier Lagneau 2012-05-03T13:09:45 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10137 <pre>Hi guys, In the Implementation notes of WeakHashMap[1], says: /One way to deal with this is to wrap values themselves within WeakReferences before inserting, as in: m.put(key, new WeakReference(value)), and then unwrapping upon each get./ However, it is not concise and a little misleading. Because the value in the WeakReference can be GC'd if there are no strong reference to it. This behaviour surprises some customers. How about add a statement like [2]: /However, as the use of WeakReference in this manner will not prevent value objects from being GC'd, this approach is only useful when entries in the map are not relied upon for keeping the underlying value objects "live"./ [1]: http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ &lt;http://cr.openjdk.java.net/%7Elittlee/7166055/webrev.00/&gt; </pre> Charles Lee 2012-05-03T06:52:21 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10119 <pre>Hi all, I updated 2 files(src/share/classes/sun/font/StrikeCache.java, src/share/classes/sun/java2d/Disposer.java) to use generic type, but I'm not sure if I modified too much. Especially I changed the return type of Disposer.getQueue from ReferenceQueue to ReferenceQueue&lt;Object&gt; . The webrev is: http://cr.openjdk.java.net/~zhouyx/OJDK-389/webrev.00/ Please take a look. </pre> Sean Chou 2012-05-02T08:01:45 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10114 <pre>Hi all, Is there some reason for not using #valueOf-methods from wrapper classes in Unsafe-based FieldAccessors in sun.reflect-package (see the attached patch)? The main motivation for this patch is to reduce memory consumption in applications which make heavy use of reflection API (e.g. apps which use ORM solutions). The patch does not modify Unsafe-based FieldAccessors for double and float fields as the wrapper classes does not provide caching for fields of this types. Best regards Andrej Golovnin </pre> Andrej Golovnin 2012-05-01T19:33:52 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10113 <pre>Hi, This is a simple fix to enable AbstractPreferences.remove() to check for a null argument and throw a NullPointerException if required. I have also modified test/java/util/prefs/RemoveNullKeyCheck.java to cover this case. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165118 Webrev: http://cr.openjdk.java.net/~khazra/7165118/webrev.00/ Thanks, Kurchi </pre> Kurchi Hazra 2012-05-01T19:01:37 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10081 <pre>This enhancement proposal has a long history. The most recent attempt to get some String.join() methods was by Joe Darcy back in 2009 ( http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-October/002967.html) He started with the changes that Remi Forax had done 8 months prior to that, which Remi had attempted a year before that! I've taken the work that Remi and Joe did and am trying again. There was a lot of discussion that was generated and that is why this has died on the vine a number of times. I realize that the current proposal may also generate discussion, but I think this had merit 4 years ago and still does. We won't satisfy everyone. It may not be perfect (what is?!), but if we can look at it from the perspective that something is better than nothing, then we ought to attempt a quick review and get this in. Having said that, I ask that you please take a look at the http://cr.openjdk.java.net/~jgish/5015163/webrev/ &lt;http://cr.openjdk.java.net/%7Ejgish/5015163/webrev/&gt; Just a few words, based on the previous discussion, to set some context. * join() is (roughlty) intended to be the inverse of split() * example: "Hi there".join("-", "Bill", "Joe", "Zoe") will yield "Hi there-Bill-Joe-Zoe" * in the original proposal the delimiter character was what you started with, i.e. o "-".join( "Hi there", "Bill", "Joe", "Zoe") yielded the same result as above o it seemed awkward to have the delimiter be the String instance that the join was performed on. I agree and so have made the first parameter of the join be the delimiter. * there was a lot of discussion about the pros and cons of making join() a static method vs an instance method. The point was made then, and I concur, that given that split() is an instance method, it only makes sense that join() be one too. Certainly there are other perspectives on this and one could argue the merit of each and every one of them, but in the interests of progress, I think the the split()/join() similarity argument is the most compelling and natural. Thanks, Jim Gish </pre> Jim Gish 2012-04-27T22:21:57 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10056 <pre>Hi, While syncing user preferences, a BackingStoreException is not expected, since the current user should be able to read/write such preferences to the persistent storage (unlike system preferences, where current user needs to have admin rights). This fix aims at allowing a user preference node to sync any changes to the persistent storage. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118100 Webrev: http://cr.openjdk.java.net/~khazra/7118100/jdk8/webrev.00/ This webrev had been earlier code-reviewed for 7u4(but never committed) [1]. There are no additional changes required for jdk8. Thanks, Kurchi [1] http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003081.html </pre> Kurchi Hazra 2012-04-26T00:34:01 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10052 <pre>Hi All We have a command line tool that needs to print out date/time in a table. The current Date.toString() always has the same width and it's beautiful: 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf However, both the DOW and MON are English and might make non-English users unhappy. On the other hand, DateFormat.getDateTimeInstance() knows about locale but the output is not the same width. 76 Nov 10, 2009 8:57:54 AM bin/vbin/go 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf or when -Duser.language=fr 76 10 nov. 2009 08:57:54 bin/vbin/go 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans 170 20 nov. 2009 16:47:42 bin/vbin/syncdown 671 8 févr. 2012 20:11:22 bin/vbin/ssh.desktop 187 20 nov. 2009 16:47:34 bin/vbin/syncsf Is there a nice way to make the output same width and locale aware? I can wait for JDK 8. Thanks Max </pre> Weijun Wang 2012-04-25T10:05:38 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10041 <pre>Hi, Could you please review this, actually the launcher is a 2 line change, but when I was testing/experimenting with this, it was hard to inspect the .jtr file for test failure, the test framework is cleanup to help the reader quickly identify the failing test cases. http://cr.openjdk.java.net/~ksrini/7151434 Thanks Kumar </pre> Kumar Srinivasan 2012-04-24T15:24:43 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10031 <pre>Hi all, I am absolute new on OpenJDK forum. Intention: start a port to OpenVMS Itanium Question: which project has to be ported first, given that OpenVMS has a JDK 1.6.0_05 but does not have JDK 1.7.0_* Reason: It is unclear since Months, what HP's JAVA OpenVMS Roadmap will be. But we need to know where we have to go. Fact: Annotaions like &lt; at &gt;Requestwrapper or &lt; at &gt;Responsewrapper or &lt; at &gt;Addressing, used in Web Service Java Code i.e. Apache Axis2/JAXWS support, are having demand on JDK 7.0 / 8.0 which is not available for HP OpenVMS. Hence we can use Annotations only very limitted. Question 1: Where shall I start reading on OpenJDK? Question 2: Which OpenJDK project needs to be ported first to get on OpenVMS $ JAVA.EXE running? (i.e. executing i.e. older byte code) Any hints and redirections to the proper group / project / mailing list is very welcome. Josef.Stadelmann &lt; at &gt;axa-winterthur.ch </pre> Josef Stadelmann 2012-04-23T21:16:12 http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10026 <pre>Hi guys, I've found a case where assert is harmful because it doesn't play well with Hotspot inlining heuristic. I'm currently playing with a lambda modified implementation of java.util and as you see below Integer.valueOf is considered as too big by Hotspot to be inlined. 79 2 b lambda.perf.Iterables::filterMapReduce (72 bytes) &lt; at &gt; 4 java.util.AbstractList::iterator (10 bytes) inline (hot) &lt; at &gt; 6 java.util.AbstractList$Itr::&lt;init&gt; (6 bytes) unloaded signature classes &lt; at &gt; 61 java.util.AbstractList$Itr::hasNext (20 bytes) inline (hot) &lt; at &gt; 8 java.util.Arrays$ArrayList::size (6 bytes) inline (hot) ! &lt; at &gt; 16 java.util.AbstractList$Itr::next (45 bytes) inline (hot) &lt; at &gt; 1 java.util.AbstractList$Itr::checkForComodification (23 bytes) inline (hot) &lt; at &gt; 14 java.util.Arrays$ArrayList::get (7 bytes) inline (hot) &lt; at &gt; 29 lambda.perf.Test$1::accept (9 bytes) inline (hot) &lt; at &gt; 5 lambda.perf.Test$1::accept (13 bytes) inline (hot) &lt; at &gt; 1 java.lang.Integer::intValue (5 bytes) inline (hot) &lt; at &gt; 45 lambda.perf.Test$2::map (9 bytes) inline (hot) &lt; at &gt; 5 lambda.perf.Test$2::map (2 bytes) inline (hot) &lt; at &gt; 52 lambda.perf.Test$3::apply (13 bytes) inline (hot) &lt; at &gt; 9 lambda.perf.Test$3::apply (13 bytes) inline (hot) &lt; at &gt; 1 java.lang.Integer::intValue (5 bytes) inline (hot) &lt; at &gt; 5 java.lang.Integer::intValue (5 bytes) inline (hot) &lt; at &gt; 9 java.lang.Integer::valueOf (54 bytes) too big &lt; at &gt; 61 java.util.AbstractList$Itr::hasNext (20 bytes) inline (hot) &lt; at &gt; 8 java.util.Arrays$ArrayList::size (6 bytes) inline (hot) but the code of Integer.valueOf doesn't seem too big: public static Integer valueOf(int i) { assert IntegerCache.high &gt;= 127; if (i &gt;= IntegerCache.low &amp;&amp; i &lt;= IntegerCache.high) return IntegerCache.cache[i + (-IntegerCache.low)]; return new Integer(i); } The issue is that Hotspot also count the bytecodes related to assert in its inlining heuristic. If the assert is commented, the inlining tree is good. 88 2 b lambda.perf.Iterables::filterMapReduce (72 bytes) &lt; at &gt; 4 java.util.AbstractList::iterator (10 bytes) inline (hot) &lt; at &gt; 6 java.util.AbstractList$Itr::&lt;init&gt; (6 bytes) unloaded signature classes &lt; at &gt; 61 java.util.AbstractList$Itr::hasNext (20 bytes) inline (hot) &lt; at &gt; 8 java.util.Arrays$ArrayList::size (6 bytes) inline (hot) ! &lt; at &gt; 16 java.util.AbstractList$Itr::next (45 bytes) inline (hot) &lt; at &gt; 1 java.util.AbstractList$Itr::checkForComodification (23 bytes) inline (hot) &lt; at &gt; 14 java.util.Arrays$ArrayList::get (7 bytes) inline (hot) &lt; at &gt; 29 lambda.perf.Test$1::accept (9 bytes) inline (hot) &lt; at &gt; 5 lambda.perf.Test$1::accept (13 bytes) inline (hot) &lt; at &gt; 1 java.lang.Integer::intValue (5 bytes) inline (hot) &lt; at &gt; 45 lambda.perf.Test$2::map (9 bytes) inline (hot) &lt; at &gt; 5 lambda.perf.Test$2::map (2 bytes) inline (hot) &lt; at &gt; 52 lambda.perf.Test$3::apply (13 bytes) inline (hot) &lt; at &gt; 9 lambda.perf.Test$3::apply (13 bytes) inline (hot) &lt; at &gt; 1 java.lang.Integer::intValue (5 bytes) inline (hot) &lt; at &gt; 5 java.lang.Integer::intValue (5 bytes) inline (hot) &lt; at &gt; 9 java.lang.Integer::valueOf (32 bytes) inline (hot) &lt; at &gt; 28 java.lang.Integer::&lt;init&gt; (10 bytes) call site not reached &lt; at &gt; 61 java.util.AbstractList$Itr::hasNext (20 bytes) inline (hot) &lt; at &gt; 8 java.util.Arrays$ArrayList::size (6 bytes) inline (hot) Given that Integer.valueOf() is a method used very often and that if the inlining fails, the escape analysis will not remove the allocation, I think it's a good idea to comment this assert. cheers, Rémi </pre> Rémi Forax 2012-04-23T17:35:41 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.openjdk.core-libs.devel