Hi Mikael,
This all looks okay to me.
Thanks,
David
On 19/03/2015 9:18 AM, Mikael Vidstedt wrote:
Please review the following change which fixes a number of native
compilation warnings in the jdk.pack200 code.
Bug: https://bugs.openjdk.java.net/browse/JDK-8074839
Webrev:
http://cr.openjdk.ja
Please review the following change which fixes a number of native
compilation warnings in the jdk.pack200 code.
Bug: https://bugs.openjdk.java.net/browse/JDK-8074839
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8074839/webrev.03/webrev/
Testing: A slightly earlier version [1] has been t
Please review at your convenience. This a doc-only change.
Issue: https://bugs.openjdk.java.net/browse/JDK-8074937
Patch: http://cr.openjdk.java.net/~bpb/8074937/webrev.00/
This is in effect an amplification of extant javadoc suggested as an
enhancement by an external user. I performed some te
Hello Mikhail,
Hi all,
Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
The problem is that packer/unpacker changes global state( default time
zone ) without proper synchronization:
http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/uti
On 18/03/2015 11:06, Chris Hegarty wrote:
:
/**
* Checks that all final instance fields, declared by the class where
* the {@code readObject} callback is being invoked, have been set.
*
* This method is intended to be called as a final step after all
* final instance fields have been
Hi,
Please review my changes for 8071667 : "HashMap.computeIfAbsent() adds
entry that HashMap.get() does not find"
Bug:
https://bugs.openjdk.java.net/browse/JDK-8071667
Webrev+specdiff:
http://cr.openjdk.java.net/~bchristi/8071667/webrev.2/
The fix is to detect structural changes made by th
On 18/03/15 18:03, Roger Riggs wrote:
Hi,
I think its up to loadConfiguration to handle (and specify) exceptions
in methods that it calls.
IAE is not your ordinary RuntimeException.
IAE in calling Properties.load is an issue for loadConfiguration to
handle; seems like it should
be turned into IO
Hi,
I think its up to loadConfiguration to handle (and specify) exceptions
in methods that it calls.
IAE is not your ordinary RuntimeException.
IAE in calling Properties.load is an issue for loadConfiguration to
handle; seems like it should
be turned into IOException in this case because it is
On 18/03/15 14:56, Jason Mehrens wrote:
Daniel,
It occurred to me after reading Brian's patch for
https://bugs.openjdk.java.net/browse/JDK-8075362 that the
LogManager.readConfiguration methods do not document NPE or IAE that can be
triggered by Properties.load. Do we need to file a bug just
Hi,
The fix for https://bugs.openjdk.java.net/browse/JDK-8067969 (optimized
Stream.count()) caused a regression in the JCK tests.
A test exposed a known weakness in the way pipeline flags are prepared for
parallel execution. In certain cases the pipeline may report SIZED but the
source spliter
Daniel,
It occurred to me after reading Brian's patch for
https://bugs.openjdk.java.net/browse/JDK-8075362 that the
LogManager.readConfiguration methods do not document NPE or IAE that can be
triggered by Properties.load. Do we need to file a bug just against logging or
should larger bug be
Hi all,
Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
The problem is that packer/unpacker changes global state( default time
zone ) without proper synchronization:
http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerI
On 18/03/2015 9:46 PM, Lev Priima wrote:
On 03/18/2015 01:52 PM, David Holmes wrote:
On 18/03/2015 6:12 PM, Lev Priima wrote:
On 03/18/2015 04:46 AM, David Holmes wrote:
Hi Lev,
On 18/03/2015 9:07 AM, Lev Priima wrote:
Possible, by determining of disabled UseCompressedOops option and
forking
On 03/18/2015 01:52 PM, David Holmes wrote:
On 18/03/2015 6:12 PM, Lev Priima wrote:
On 03/18/2015 04:46 AM, David Holmes wrote:
Hi Lev,
On 18/03/2015 9:07 AM, Lev Priima wrote:
Possible, by determining of disabled UseCompressedOops option and
forking vm again with required minimum heap value
On 17/03/15 11:52, Peter Levart wrote:
On 03/17/2015 10:57 AM, Chris Hegarty wrote:
Peter, Alan,
After further thought I think that requiring all final fields to be set is
reasonable behaviour. Since there is no compile time checking, this is a
reasonable runtime effort to catch what is likel
On 17/03/15 13:42, Alan Bateman wrote:
On 17/03/2015 12:21, Peter Levart wrote:
Hi Alan,
I agree that not calling defaultReadObject() from readObject() and
having a final field is potentially a bug. But need not be in case
some other means of setting final fields was used (Unsafe or
reflection
On 18/03/2015 6:12 PM, Lev Priima wrote:
On 03/18/2015 04:46 AM, David Holmes wrote:
Hi Lev,
On 18/03/2015 9:07 AM, Lev Priima wrote:
Possible, by determining of disabled UseCompressedOops option and
forking vm again with required minimum heap value(-Xms).
Please review update:
http://cr.openj
On 03/18/2015 04:46 AM, David Holmes wrote:
Hi Lev,
On 18/03/2015 9:07 AM, Lev Priima wrote:
Possible, by determining of disabled UseCompressedOops option and
forking vm again with required minimum heap value(-Xms).
Please review update:
http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
18 matches
Mail list logo
