Thank you Martin for looking at this!
On 27.05.2015 17:30, Martin Buchholz wrote:
Thanks.
Your methods like ofArrayList declare that they
throw ReflectiveOperationException, but also have a try/catch to
prevent that from ever happening.
Fixed!
The assertions e.g.
Please review 3 editorial issues in the java.time package:
Issues:
8075678 https://bugs.openjdk.java.net/browse/JDK-8075678: java.time
javadoc error in DateTimeFormatter::parsedLeapSecond
8075676 https://bugs.openjdk.java.net/browse/JDK-8075676: java.time
package javadoc typos
8068276
Changes seem reasonable Roger
Best
Lance
On May 28, 2015, at 4:14 PM, Roger Riggs roger.ri...@oracle.com wrote:
Please review 3 editorial issues in the java.time package:
Issues:
8075678 https://bugs.openjdk.java.net/browse/JDK-8075678: java.time javadoc
error in
Fine by me
Stephen
On 28 May 2015 at 21:14, Roger Riggs roger.ri...@oracle.com wrote:
Please review 3 editorial issues in the java.time package:
Issues:
8075678 https://bugs.openjdk.java.net/browse/JDK-8075678: java.time
javadoc error in DateTimeFormatter::parsedLeapSecond
8075676
On 28 maj 2015, at 20:06, Mandy Chung mandy.ch...@oracle.com wrote:
On 05/28/2015 07:35 AM, Peter Levart wrote:
Hi Mandy,
On 05/27/2015 03:32 PM, Mandy Chung wrote:
Taking it further - is it simpler to return String[] of all classnames
including the duplicated ones and have the VM do
On 05/28/2015 07:35 AM, Peter Levart wrote:
Hi Mandy,
On 05/27/2015 03:32 PM, Mandy Chung wrote:
Taking it further - is it simpler to return String[] of all
classnames including the duplicated ones and have the VM do the
count? Are you concerned with the size of the String[]?
Yes, the
Hi,
Did you know that the following simple loop:
public class FinalizableBottleneck {
static boolean no;
@Override
protected void finalize() throws Throwable {
// empty finalize() method does not make the object finalizable
// (it is not even registered on the
Got it, thanks.
Can we ignore errors caused by code cache overflow for now?
Best regards,
Vladimir Ivanov
On 5/28/15 12:03 PM, Konstantin Shefov wrote:
Vladimir,
This fix is not for timeout issue, this fix is for
java.lang.VirtualMachineError: out of space in CodeCache for adapters.
Timeout
looks OK Joe
On May 28, 2015, at 1:38 AM, joe darcy joe.da...@oracle.com wrote:
Hello,
As the venerable URL
http://bugreport.sun.com/bugreport/
has been retired and replaced with
http://bugreport.java.com/bugreport/
Occurrences of the old URL in the source base should be
On 29/05/2015 2:08 AM, Ulf Zibis wrote:
Hi all,
in the Javadoc of notify(), notifyAll() and wait(...) I read, that this
methods should only be used with synchronisation on it's instance.
So I'm wondering, why they don't have the synchronized modifier out of
the box in Object class.
Because,
Approved.
On Thu, May 28, 2015 at 3:43 PM, Ivan Gerasimov ivan.gerasi...@oracle.com
wrote:
Good naming is one of the most difficult part of coding IMO.
The chosen names were meant to be read literally: optimal capacity of
ArrayList, etc.
I agree, 'assert' would tell more about these methods'
Hi Peter,
I guess I'm very concerned about the premise that finalization should
scale to millions of objects and be performed highly concurrently. To me
that's sending the wrong message about finalization. It also isn't the
most effective use of cpu resources - most people would want to do
On 28/05/2015 06:47, joe darcy wrote:
Hello,
The latest HotSpot integration into JDK 9 dev introduced a test
failure in
java/lang/invoke/8022701/MHIllegalAccess.java.MHIllegalAccess.java
Please review the change below to problem list the test until such
time as the fix for the test
On 27/05/2015 20:09, Xueming Shen wrote:
Hi,
Please help review the change of changing the hard-wired extended
charsets loading mechanism
to ServiceLoader.loadInstalled(), for the module system. With the fix
for JDK-8069588 in JDK 9 all
charsets needed to startup in supported environments
On 28/05/2015 06:07, Mandy Chung wrote:
An update to this patch:
Updated patch looks good to me.
I assume that Alexander Kulyakhtin and others will follow up at some
point to also add @modules to aid test selection.
-Alan
On 27/05/2015 17:01, Xueming Shen wrote:
I'm aware of converting the options to internal flags in unix fs, but
thought that is for the convenience...
We are not saving the options for any future/internal use, simply
checking its value on the spot. Just wonder
really need to make the
Vladimir,
This fix is not for timeout issue, this fix is for
java.lang.VirtualMachineError: out of space in CodeCache for adapters.
Timeout issue is other bug and should be filed separately.
I do not know why SQE added RULES with timeout to this bug.
By the way, if -Xcomp is set on JDK 8u,
Hello all,
encouraged by your responses I did a simple implementation and performed
some JMH experiments. Details below.
Webrev [1] contains my changes. I deliberately wanted to do minimal code
changes. The gist of it is implementing indexOf that works on CharSequence
instead of String's
Your code makes the native app inherit native stdout/err process
descriptors, you need to pipe the output from your native app to Java
and then redirect the output to wherever you wish (byte array for
example).
In other words, Redirect.PIPE + pipe code.
Dawid
On Thu, May 28, 2015 at 12:43 PM,
Hi,
I more would like:
2199 return (s instanceof String)
2200 ? indexOf((String) s) = 0;
2201 : indexOf(value, 0, value.length, s, 0, s.length(), 0) =
0;
or:
2199 return (s instanceof String
2200 ? indexOf((String) s)
2201
Hi,
thank you for taking time to read my proposal. Is this a matter of some
OpenJDK coding conventions? I myself never use ternary operator and always
use if with braces. My experience is that it improves code readability. If
I have to apply one of proposed changes I would choose first or third.
I am writing something like this
ByteArrayOutputStream bout = new ByteArrayOutputStream();
System.setOut(out);
System.out.println(Hello);
ProcessBuilder pb1 = new ProcessBuilder(./native-app);
pb1.redirectOutput(ProcessBuilder.Redirect.INHERIT);
pb1.start();
Now Hello
Hi Joe,
+1 to add to the problem list.
Looks fine.
Roger
On 5/28/2015 1:47 AM, joe darcy wrote:
Hello,
The latest HotSpot integration into JDK 9 dev introduced a test
failure in
java/lang/invoke/8022701/MHIllegalAccess.java.MHIllegalAccess.java
Please review the change below to problem
On 05/28/2015 04:44 PM, Jason Mehrens wrote:
Peter,
Have we considered just embracing CharBuffer.wrap(CharSequence, int, int) work
as way to support the old substring behavior? If you dig through the code, that
creates a java.nio.StringCharBuffer which is a view of the wrapped string. We
What would synchronized on that method help with? Typically you do
something while holding the lock and then notify while still holding the
lock.
sent from my phone
On May 28, 2015 12:09 PM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Hi all,
in the Javadoc of notify(), notifyAll() and wait(...) I
On 05/28/2015 07:08 PM, Ulf Zibis wrote:
Hi all,
in the Javadoc of notify(), notifyAll() and wait(...) I read, that this
methods should only be used with synchronisation on it's instance.
So I'm wondering, why they don't have the synchronized modifier out of
the box in Object class.
Well,
Since most of the time you have to hold the lock anyway for other
reasons, I think this would generally be an unwelcome change since I
expect the cost of recursive lock acquisition is nonzero.
On 05/28/2015 11:08 AM, Ulf Zibis wrote:
Hi all,
in the Javadoc of notify(), notifyAll() and
On 05/28/2015 08:53 AM, Xueming Shen wrote:
http://cr.openjdk.java.net/~sherman/8069588_8038310/webrev
This change looks okay. This code optimizes for space and assumes one
single installed provider which I am not sure if it buys us much -
List.toArray might be another alternative rather
Hi all,
in the Javadoc of notify(), notifyAll() and wait(...) I read, that this methods should only be used
with synchronisation on it's instance.
So I'm wondering, why they don't have the synchronized modifier out of the box
in Object class.
Also I think, the following note should be moved
On 28/05/2015 16:53, Xueming Shen wrote:
Alan,
Thanks for the comments. Webrev has been updated accordingly.
http://cr.openjdk.java.net/~sherman/8069588_8038310/webrev
Looks good.
-Alan.
Hi,
Please, review JDK9 fix [1] for a bug [2] in 'getNodeValue' JAXP function:
According to w3c [3] getNodeValue should return 'null' value for
Element nodes. This behavior was changed by JDK-8032908 [4] fix - in
current implementation the node content is returned.
To address this issue the
On 5/28/15 12:46 AM, Alan Bateman wrote:
On 27/05/2015 20:09, Xueming Shen wrote:
Hi,
Please help review the change of changing the hard-wired extended
charsets loading mechanism
to ServiceLoader.loadInstalled(), for the module system. With the fix
for JDK-8069588 in JDK 9 all
charsets
On 05/28/2015 09:05 AM, Mandy Chung wrote:
On 05/28/2015 08:53 AM, Xueming Shen wrote:
http://cr.openjdk.java.net/~sherman/8069588_8038310/webrev
This change looks okay. This code optimizes for space and assumes one single
installed provider which I am not sure if it buys us much -
Hi Aleksej,
Thanks for the quick action! The changes are good to me.
Best,
Joe
On 5/28/2015 8:33 AM, Aleksej Efimov wrote:
Hi,
Please, review JDK9 fix [1] for a bug [2] in 'getNodeValue' JAXP
function:
According to w3c [3] getNodeValue should return 'null' value for
Element nodes. This
Hi,
I have already reviewed it, contributed by Staffan Larsen.
This is an fyi, I will push this changeset if no one has any
objections.
https://bugs.openjdk.java.net/browse/JDK-8080991
http://cr.openjdk.java.net/~ksrini/8080991/webrev/
Thanks
Kumar
35 matches
Mail list logo
