On 11/05/2014 21:56, Seán Coffey wrote:
Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can
remove use of reflection in ORB code to access the applet context.
bug report : https://bugs.openjdk.java.net/browse/JDK-8042906
webrev :
I Seán,
I wonder whether it would be better to use a ConcurrentHashMap in
place of the plain HashMap and remove the synchronized lock
around putIfAbsent/computeIfAbsent?
best regards,
-- daniel
On 5/11/14 10:56 PM, Seán Coffey wrote:
Now that JDK 8 is the official build bootstrap JDK for JDK
Good tip Alan/Chris.
I'll make that change and push.
Regards,
Sean.
On 12 May 2014 07:17:04 GMT+01:00, Alan Bateman alan.bate...@oracle.com wrote:
On 11/05/2014 21:56, Seán Coffey wrote:
Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can
remove use of reflection in ORB code
Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05e9c9216e26
Thanks,
/Staffan
On 12 maj 2014, at 10:28, Yekaterina Kantserova
yekaterina.kantser...@oracle.com wrote:
Staffan,
could you please be my sponsor and push this fix?
I have discovered three more tests that should be changed:
Hi,
This is a request for review of Otavio's patch replacing StringBuffer with
StringBuilder within OpenJDK. (I also need to review it.)
It covers many areas and i have grouped the patches into such areas to aid
reviewing. When commenting please including core-libs.
Jtreg tests showed no
Wouldn't it be a little bit more efficient to replace a string
concatenation with yet another StringBuilder operation?
src/share/classes/com/sun/java/util/jar/pack/BandStructure.java
631 StringBuilder sb = new StringBuilder();
...
636 Utils.log.fine(
On 12/05/2014 11:03, Paul Sandoz wrote:
It covers many areas and i have grouped the patches into such areas to
aid reviewing. When commenting please including core-libs.
The groupings are a bit odd but I looked through the -core, -io,
-management and -rmi patches and don't see any issues.
On May 12, 2014, at 12:42 PM, Alan Bateman alan.bate...@oracle.com wrote:
On 12/05/2014 11:03, Paul Sandoz wrote:
It covers many areas and i have grouped the patches into such areas to aid
reviewing. When commenting please including core-libs.
The groupings are a bit odd
Yeah, definitely
src/share/classes/sun/misc/UUDecoder.java
126 StringBuilder x = new StringBuilder();
Is only filled, but doesn't seem to be used anyhow.
Maybe just delete it?
Sincerely yours,
Ivan
On 12.05.2014 14:03, Paul Sandoz wrote:
Hi,
This is a request for review of Otavio's patch replacing
- security
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/
Looks fine to me. Thanks for making this update.
Xuelei
On 5/12/2014 6:03 PM, Paul Sandoz wrote:
Hi,
This is a request for review of Otavio's patch replacing StringBuffer
with
If I read the javdoc correctly neither computeIfAbsent nor putIfAbsent
seem to match the
previous semantics of the if statement?
computeIfAbsent: If the value for the specified key is present and
non-null, attempts to compute a new mapping given the key and its
current mapped value.
or
If
On 12/05/14 12:33, Mark Sheppard wrote:
If I read the javdoc correctly neither computeIfAbsent nor putIfAbsent
seem to match the
previous semantics of the if statement?
computeIfAbsent: If the value for the specified key is present and
non-null, attempts to compute a new mapping given the key
Hi Mark,
AFAIKS computeIfAbsent does what we want:
http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#computeIfAbsent-K-java.util.function.Function-
It seems that putIfAbsent would not though. This is indeed confusing.
I wish putIfAbsent had been specified similarly to
OK thanks Chris and Daniel ... I see my misinterpretation now
regards
Mark
On 12/05/2014 13:46, Daniel Fuchs wrote:
Hi Mark,
AFAIKS computeIfAbsent does what we want:
http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#computeIfAbsent-K-java.util.function.Function-
It seems that
Hi Paul,
I looked at -management and the changes there look good.
There is just some two spaces vs four space formatting in
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/src/share/classes/com/sun/jndi/cosnaming/CNNameParser.java.frames.html
line 99.
Hi Remi -
Thank you for the fast response, I have indeed signed the OCA.
I shall work on the bug you suggested
(JDK-8037343https://bugs.openjdk.java.net/browse/JDK-8037343) over
the week and submit a patch. Note that my work on OpenJDK is outside of
work hours so will likely only get a chance
On 05/07/2014 11:04 PM, Martin Buchholz wrote:
Hi Peter,
Your last version version looks very good. Approved! I'm reduced to
asking you to fix ancient buglets of mine.
*I'd spell creat with an e.*
188 * Create a process. Depending on the mode flag, this is done by
*I'd spell
Great to see this getting in. Thanks Peter!
-Rob
On 12/05/14 16:51, Peter Levart wrote:
On 05/07/2014 11:04 PM, Martin Buchholz wrote:
Hi Peter,
Your last version version looks very good. Approved! I'm reduced to
asking you to fix ancient buglets of mine.
*I'd spell creat with an
Hi All,
As you all know, OFED's Socket Direct protocol is deprecated and OFED's 3.x
releases do not come with SDP at all. Hence, Java's SDP also fails to work. I
was wondering what is the proper method to
program infiniband in Java? Is there any portable solution other than
just writing JNI
On 05/12/2014 12:42 PM, Alan Bateman wrote:
On 12/05/2014 11:03, Paul Sandoz wrote:
It covers many areas and i have grouped the patches into such areas
to aid reviewing. When commenting please including core-libs.
The groupings are a bit odd but I looked through the -core, -io,
-management
On Apr 26, 2014, at 12:56 PM, Otávio Gonçalves de Santana otavioj...@java.net
wrote:
When a String has length just one, could be replaced by equivalent
character literals, gaining some performance enhancement.
I found 107 changes.
This looks good to me, just one small issue:
---
In JDK 8 we brought in a tiny XML parser to support the Properties
loadFromXML/storeToXML methods. We needed this for the Compact Profiles
work, specifically builds of compact1 as they do not have JAXP/XML APIs.
At the time we were a bit nervous about switching the XML parser for
anything
Hi Alan,
The webrev looks good to me.
On 5/12/2014 11:02 AM, Alan Bateman wrote:
In JDK 8 we brought in a tiny XML parser to support the Properties
loadFromXML/storeToXML methods. We needed this for the Compact
Profiles work, specifically builds of compact1 as they do not have
JAXP/XML
Please review and comment on this long requested addition to provide the
native process id of a spawned Process.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/
Issue: https://bugs.openjdk.java.net/browse/JDK-8003488
Thanks, Roger
On 12 May 2014, at 19:02, Alan Bateman alan.bate...@oracle.com wrote:
In JDK 8 we brought in a tiny XML parser to support the Properties
loadFromXML/storeToXML methods. We needed this for the Compact Profiles work,
specifically builds of compact1 as they do not have JAXP/XML APIs.
At
Hi Martin,
Alan mentioned this case but it seemed more difficult to use than the
primitive.
For the other parts of JEP 102, I expect to represent a process with a type
that can have additional methods. That type would provide stronger
typing and
a set of useful operations. It seems less
I was thinking about this ticket today. Regarding Alan Bateman's comment
that the pid may not be representable as an int/long, I was expecting some
sort of Pid-like-object to be returned. I'd rather see an abstraction that
*might* be able to convert into an int/long ... or even a String, as Martin
On 12/05/2014 20:44, roger riggs wrote:
Please review and comment on this long requested addition to provide the
native process id of a spawned Process.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/
Issue: https://bugs.openjdk.java.net/browse/JDK-8003488
I think the
On May 9, 2014, at 1:48 AM, Florian Weimer fwei...@redhat.com wrote:
On 05/06/2014 06:38 PM, Brian Burkhalter wrote:
Paul / Florian,
This is a combined response. I am making the corrections pointed out by
Florian. Unless I hear otherwise, I am going to assume that Paul’s
approval is still
On 5/12/14 11:02 AM, Alan Bateman wrote:
In JDK 8 we brought in a tiny XML parser to support the Properties
loadFromXML/storeToXML methods. We needed this for the Compact
Profiles work, specifically builds of compact1 as they do not have
JAXP/XML APIs.
At the time we were a bit nervous
30 matches
Mail list logo
