<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.java.openjdk.core-libs.devel">
    <title>gmane.comp.java.openjdk.core-libs.devel</title>
    <link>http://blog.gmane.org/gmane.comp.java.openjdk.core-libs.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10342"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10310"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10309"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10304"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10255"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10249"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10247"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10237"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10226"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10203"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10154"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10141"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10137"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10119"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10114"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10113"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10081"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10056"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10052"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10041"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10342">
    <title>[PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field,keeping a reference to the original Map</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10342</link>
    <description>&lt;pre&gt;Hello,

I have reported a bug in the implementation of the clone method of the
EnumMap class.
The instance field entrySet is not being cleared, so the entrySet field of
the new instance references to the original EnumMap.

I am providing a simple patch for review. It adds one line to the clone
method that sets the entrySet field to null.

This is my first contribution to the OpenJDK, so let me know if I am
missing some step of the process.

Thanks,
Diego Belfer
[muralx]
&lt;/pre&gt;</description>
    <dc:creator>Diego Belfer</dc:creator>
    <dc:date>2012-05-26T19:30:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10310">
    <title>Review request CR 7171918 XmlReaderContentHandler.endElement does nothandle a Delete Tag properly</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10310</link>
    <description>&lt;pre&gt;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
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -764,6 +764,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;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.203&lt;/pre&gt;</description>
    <dc:creator>Lance Andersen - Oracle</dc:creator>
    <dc:date>2012-05-25T19:56:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10309">
    <title>Review request for CR 171917 CachedRowSetImpl.populate does nothandle map properly</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10309</link>
    <description>&lt;pre&gt;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
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -659,7 +659,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;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.7&lt;/pre&gt;</description>
    <dc:creator>Lance Andersen - Oracle</dc:creator>
    <dc:date>2012-05-25T19:50:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10304">
    <title>Please review: 7168401: pack200 does not produce a compatible packfile</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10304</link>
    <description>&lt;pre&gt;Hi,

Please review, changes has been internally reviewed by John.

http://cr.openjdk.java.net/~ksrini/7168401/webrev.0/

Thanks
Kumar


&lt;/pre&gt;</description>
    <dc:creator>Kumar Srinivasan</dc:creator>
    <dc:date>2012-05-25T15:31:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10255">
    <title>Code Review Request: 7170169: (props) System.getProperty("os.name")should return "Windows 8" when run on Windows 8</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10255</link>
    <description>&lt;pre&gt;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


&lt;/pre&gt;</description>
    <dc:creator>Kurchi Hazra</dc:creator>
    <dc:date>2012-05-23T01:32:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10249">
    <title>Long standing String.trim() bug</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10249</link>
    <description>&lt;pre&gt;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.

&lt;/pre&gt;</description>
    <dc:creator>Paulo Levi</dc:creator>
    <dc:date>2012-05-21T07:13:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10247">
    <title>Please review (EZ): 7170087: tools/launcher/Arrghs.java test haswrong bugID for 7151434</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10247</link>
    <description>&lt;pre&gt;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


&lt;/pre&gt;</description>
    <dc:creator>Kumar Srinivasan</dc:creator>
    <dc:date>2012-05-18T22:04:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10237">
    <title>hg: jdk8/tl/jdk: 7164191: properties.putAll API may fail withConcurrentModifcationException on multi-thread scenario</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10237</link>
    <description>&lt;pre&gt;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 &amp;lt;youdwei-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8&amp;lt; at &amp;gt;public.gmane.org&amp;gt;

! src/share/classes/sun/management/Agent.java
+ test/sun/management/AgentCMETest.java


&lt;/pre&gt;</description>
    <dc:creator>dmitriy.samersoff-QHcLZuEGTsvQT0dZR+AlfA&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-15T12:49:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10226">
    <title>Code Review Request: 7164636: (prefs) Cleanupsrc/macosx/classes/java/util/prefs</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10226</link>
    <description>&lt;pre&gt;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 &amp;lt; at &amp;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


&lt;/pre&gt;</description>
    <dc:creator>Kurchi Hazra</dc:creator>
    <dc:date>2012-05-11T21:46:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10203">
    <title>Review Request : 7071826 : Avoid benign race condition ininitialization of UUID</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10203</link>
    <description>&lt;pre&gt;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/webre&lt;/pre&gt;</description>
    <dc:creator>Mike Duigou</dc:creator>
    <dc:date>2012-05-10T23:11:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10154">
    <title>Pass a pointer  to  JNI_GetCreatedJavaVMs() instead of null</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10154</link>
    <description>&lt;pre&gt;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;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/ 
&amp;lt;http://cr.openjdk.java.net/%7Elittlee/ojdk-432/webrev.00/&amp;gt;


Please review this mail!

Thanks a lot!

&lt;/pre&gt;</description>
    <dc:creator>Deven You</dc:creator>
    <dc:date>2012-05-07T09:38:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10141">
    <title>Review Request for CR : 7144861 RMI activation tests are too slow</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10141</link>
    <description>&lt;pre&gt;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 &amp;lt; at &amp;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:
--------------------------------&lt;/pre&gt;</description>
    <dc:creator>Olivier Lagneau</dc:creator>
    <dc:date>2012-05-03T13:09:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10137">
    <title>[doc]Small modification on the WeakHashMap doc</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10137</link>
    <description>&lt;pre&gt;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/ 
&amp;lt;http://cr.openjdk.java.net/%7Elittlee/7166055/webrev.00/&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>Charles Lee</dc:creator>
    <dc:date>2012-05-03T06:52:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10119">
    <title>Request for review: updated 2 files to use generic type</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10119</link>
    <description>&lt;pre&gt;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&amp;lt;Object&amp;gt; .


The webrev is: http://cr.openjdk.java.net/~zhouyx/OJDK-389/webrev.00/

    Please take a look.

&lt;/pre&gt;</description>
    <dc:creator>Sean Chou</dc:creator>
    <dc:date>2012-05-02T08:01:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10114">
    <title>[PATCH] Use #valueOf()-methods in Unsafe-based FieldAccessors</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10114</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Andrej Golovnin</dc:creator>
    <dc:date>2012-05-01T19:33:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10113">
    <title>Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null)does not throw NPE</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10113</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Kurchi Hazra</dc:creator>
    <dc:date>2012-05-01T19:01:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10081">
    <title>RFR: 5015163 "(str) String merge/join that is the inverse ofString.split()" into JDK 8</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10081</link>
    <description>&lt;pre&gt;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/ 
&amp;lt;http://cr.openjdk.java.net/%7Ejgish/5015163/webrev/&amp;gt;

Just&lt;/pre&gt;</description>
    <dc:creator>Jim Gish</dc:creator>
    <dc:date>2012-04-27T22:21:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10056">
    <title>Code Review Request: 7118100: Inconsistency when using system anduser preference on OSX Lion</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10056</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Kurchi Hazra</dc:creator>
    <dc:date>2012-04-26T00:34:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10052">
    <title>A nice cross-locale same-width DateTime.toString()?</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10052</link>
    <description>&lt;pre&gt;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&lt;/pre&gt;</description>
    <dc:creator>Weijun Wang</dc:creator>
    <dc:date>2012-04-25T10:05:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10041">
    <title>Please review: 7151434: java -jar -XX crashes java launcher</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10041</link>
    <description>&lt;pre&gt;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



&lt;/pre&gt;</description>
    <dc:creator>Kumar Srinivasan</dc:creator>
    <dc:date>2012-04-24T15:24:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10031">
    <title>Port to HP Itanium OpenVMS</title>
    <link>http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/10031</link>
    <description>&lt;pre&gt;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 &amp;lt; at &amp;gt;Requestwrapper or &amp;lt; at &amp;gt;Responsewrapper or &amp;lt; at &amp;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
&amp;lt; at &amp;gt;axa-winterthur.ch

&lt;/pre&gt;</description>
    <dc:creator>Josef Stadelmann</dc:creator>
    <dc:date>2012-04-23T21:16:12</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.java.openjdk.core-libs.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.java.openjdk.core-libs.devel</link>
  </textinput>
</rdf:RDF>

