Looks good except that data changes keep requiring additional workaround
to the run-time code. We do need a fix for JDK-8014468.
Masayoshi
On 3/27/2015 12:47 AM, Aleksej Efimov wrote:
Hi,
Please review the fix for adding the latest tzdata2015b to JDK9.
The JTREG and JPRT tests were executed.
Please also describe the mapping of the original tests and the new ones
so that we are sure no test cases are lost in the transition.
Thanks,
Joe
On 3/26/2015 6:01 PM, huizhe wang wrote:
I second Lance. The Main of the original astro had Javadocs and
developer comments. Probably more important
I second Lance. The Main of the original astro had Javadocs and
developer comments. Probably more important is that you've completely
changed the main classes (TestDriver and Main), which looks good,
however, the original classes contained a lot of information on what
each test does and how it
Hi Aleksej,
Looks good.
Thanks,
Joe
On 3/26/2015 9:20 AM, Aleksej Efimov wrote:
Hello,
Please review the fix for XSLT 'substring' function that solves the
problem when string parameter contains supplementary characters.
The 'test/javax/xml/jaxp/transform/8062923/XslSubstringTest.java' test
w
On 3/25/2015 6:19 PM, Kumar Srinivasan wrote:
should we throttle/adapt the test on the number of processors available
using Runtime.availableProcessors() ?
Like this http://cr.openjdk.java.net/~mcherkas/8066985/webrev.07 ?
Hi Frank,
Overall these look fine. I would suggest adding a simple comment to describe
the tests that do not have one to give a basic intent of the test to make it
easier for someone to understand if they are new.
Best
Lance
On Mar 25, 2015, at 5:34 AM, Frank Yuan wrote:
> Hi, Joe and All
>
On 26/03/15 15:18, Peter Levart wrote:
On 03/26/2015 02:55 PM, Daniel Fuchs wrote:
On 26/03/15 14:43, Peter Levart wrote:
On 03/26/2015 01:28 PM, David Holmes wrote:
Hi Daniel,
On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
Please find below a trivial fix for
7113878: LogManager - namedLogger
On 3/25/15 11:55 PM, Srikanth wrote:
Greetings,
Please review this patch to remove the said unused internal API - this
has been
reviewed by a couple of engineers already and is now submitted now for
wider
review. I have built JDK on all platforms and ran the tests to make
sure this is safe.
Greetings,
Please review this patch to remove the said unused internal API - this
has been
reviewed by a couple of engineers already and is now submitted now for
wider
review. I have built JDK on all platforms and ran the tests to make sure
this is safe.
JBS:https://bugs.openjdk.java
I just tried another clean rebuild and jtreg on jar/zip and launcher tests
with -ignore:run - no problems on Linux x86.
On Thu, Mar 26, 2015 at 7:49 AM, Kumar Srinivasan <
kumar.x.sriniva...@oracle.com> wrote:
> Hi Martin,
>
> In case you have missed it, jdk/test/tools/launcher/BigJar.java
> has
Hello,
Please review the fix for XSLT 'substring' function that solves the
problem when string parameter contains supplementary characters.
The 'test/javax/xml/jaxp/transform/8062923/XslSubstringTest.java' test
was updated to include the test cases for fail behavior. Fixed function
utilizes the
Hi,
Please review the fix for adding the latest tzdata2015b to JDK9.
The JTREG and JPRT tests were executed.
No failures were observed, except one:
test/sun/util/calendar/zi/TestZoneInfo310.java
The failure was caused by the following tzdb rule addition to
make/data/tzdata/asia:
+Rule Palest
Hi,
Please review the fix for corrupted error messages in XML parser. When
the XML parser encounters illegal
character the message with incorrect data is generated:
An invalid XML character (Unicode: 0x{2}) was found in the value of
attribute "{1}" and element is "0".
But it should be like:
An
Hi Martin,
In case you have missed it, jdk/test/tools/launcher/BigJar.java
has a suppressed large file test, you might want to enable it
if not already done, I think this test originally came from google
not sure, nevertheless, a similar one also exists in:
langtools/test/tools/javac/file/zip/T6
On 26/03/15 14:32, Daniel Fuchs wrote:
The enumeration of keys returned from the map will be iterated
outside of any synchronized block.
ConcurrentHashMap makes this safe.
I'm happy to report that the test in the webrev [1] fails in
ConcurrentModificationException if HashMap is used instead
of
On 03/26/2015 02:55 PM, Daniel Fuchs wrote:
On 26/03/15 14:43, Peter Levart wrote:
On 03/26/2015 01:28 PM, David Holmes wrote:
Hi Daniel,
On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
Please find below a trivial fix for
7113878: LogManager - namedLoggers should be ConcurrentHashMap
On 26/03/15 14:42, Jason Mehrens wrote:
The snapshot enumeration is a welcomed change. ConcurrentHashMap has legacy
Hashtable methods so you can save a little bit by calling namedLoggers.keys()
instead of wrapping the key set.
Yes - but the enumeration returned by ConcurrentHashMap.keys
is i
On 26/03/15 14:43, Peter Levart wrote:
On 03/26/2015 01:28 PM, David Holmes wrote:
Hi Daniel,
On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
Please find below a trivial fix for
7113878: LogManager - namedLoggers should be ConcurrentHashMap
instead of Hashtable
As you say in the bug
On 03/26/2015 01:28 PM, David Holmes wrote:
Hi Daniel,
On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
Please find below a trivial fix for
7113878: LogManager - namedLoggers should be ConcurrentHashMap
instead of Hashtable
As you say in the bug report, now that the map is always acces
The snapshot enumeration is a welcomed change. ConcurrentHashMap has legacy
Hashtable methods so you can save a little bit by calling namedLoggers.keys()
instead of wrapping the key set.
Jason
> Date: Thu, 26 Mar 2015 14:32:23 +0100
> From: daniel.fu..
On 26/03/15 13:28, David Holmes wrote:
Hi Daniel,
On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
Please find below a trivial fix for
7113878: LogManager - namedLoggers should be ConcurrentHashMap
instead of Hashtable
As you say in the bug report, now that the map is always accessed w
Hi Daniel,
On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
Please find below a trivial fix for
7113878: LogManager - namedLoggers should be ConcurrentHashMap
instead of Hashtable
As you say in the bug report, now that the map is always accessed within
synchronized code this serves no
+1
On Mar 26, 2015, at 8:08 AM, Daniel Fuchs wrote:
> Please find below a trivial fix for
>
>
> 7113878: LogManager - namedLoggers should be ConcurrentHashMap
> instead of Hashtable
> https://bugs.openjdk.java.net/browse/JDK-7113878
>
> http://cr.openjdk.java.net/~dfuchs/webrev_7113878
Please find below a trivial fix for
7113878: LogManager - namedLoggers should be ConcurrentHashMap
instead of Hashtable
https://bugs.openjdk.java.net/browse/JDK-7113878
http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
best regards,
-- daniel
24 matches
Mail list logo
