Hi,
I've reported this last week on the build-dev list (Build error on
Mac with 7u51 boot jdk because JObjC.jar was removed from 7u51,
http://mail.openjdk.java.net/pipermail/build-dev/2014-January/011566.html),
but didn't get any answer yet.
The only workaround seems to be to use an older boot
On 23.01.2014 3:53, Vladimir Kozlov wrote:
I need help.
I am trying to do control build in JPRT after I merged latest jdk9
source:
http://hg.openjdk.java.net/jdk9/jdk9
Looks like the problem is that 8032348 is not pushed to the master
workspace of jdk9, but the bootjdk have this fix.
to
On 2014-01-23 09:32, Sergey Bylokhov wrote:
On 23.01.2014 3:53, Vladimir Kozlov wrote:
I need help.
I am trying to do control build in JPRT after I merged latest jdk9
source:
http://hg.openjdk.java.net/jdk9/jdk9
Looks like the problem is that 8032348 is not pushed to the master
workspace
Hi Miran, did you get any response on this yet?
MartiNG
On 17/01/14 10:57, Miroslav Kos wrote:
Hi Steve and Alan,
I just reminding this issue - I have no response from anybody yet and
it would really simplify our integration if I could handle copyright
years inconsistencies this way - I see
On 23 Jan 2014, at 08:53, Martin Grebac martin.gre...@oracle.com wrote:
Hi Miran, did you get any response on this yet?
MartiNG
On 17/01/14 10:57, Miroslav Kos wrote:
Hi Steve and Alan,
I just reminding this issue - I have no response from anybody yet and it
would really simplify our
On 12/03/2013 11:21 PM, Mike Duigou wrote:
There's been a discussion on the lambda spec experts list
(http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about adding a
notice to the Optional classes about implications of their likely future as
values. This discussion recently
Changeset: 68eb0c55a8c0
Author:psandoz
Date: 2014-01-21 10:49 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68eb0c55a8c0
8032190: Specifications of stream flatMap methods should require mapped streams
to be closed
Reviewed-by: chegar, alanb
!
On 22 Jan 2014, at 15:14, Florian Weimer fwei...@redhat.com wrote:
On 01/22/2014 03:47 PM, Chris Hegarty wrote:
On 22/01/14 13:57, Florian Weimer wrote:
On 01/14/2014 01:26 AM, mark.reinh...@oracle.com wrote:
Posted: http://openjdk.java.net/jeps/187
There's another aspect of the current
Hi David,
This is a nice summary of how object deserialization is working today, and some
interesting ideas around serialisation-aware constructors.
It seems there is just too much magic in the construction of deserialized
objects. All the field values required to fully construct the object
On 22/01/2014 21:48, Brent Christian wrote:
Hi,
I would like to backport this fix from 8 to 7u.
https://bugs.openjdk.java.net/browse/JDK-7199674
The source code changes apply cleanly to 7u from the 8 changeset,
however the makefile changes needed to be tweaked.
Florian, it's an idea I also broached but did not receive any feedback:
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-December/002585.html
The only downside to adding the annotation is that it makes it the
official way to denote a value type. Based on some JEPs and Lambda
A future version of Java will hopefully have value types. The disclaimers
about value-based are intended as a stake in the ground, to preserve the
option to migrate these specific new-to-Java-8 types to value types in the
future. (Older sort-of-valueish-like-but-not-quite types, like Integer,
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because the r is used later in the code and must not be assigned
pending unless it is not null(this was as is earlier). The new webrev is
posted
https://bugs.openjdk.java.net/browse/JDK-8031043
http://cr.openjdk.java.net/~twisti/8031043/webrev.00
8031043: ClassValue's backing map should have a smaller initial size
Reviewed-by:
The current initial size for ClassValue's backing WeakHashMap (ClassValueMap)
is:
private static
Hello!
This is a simple backport from 8 to 7.
Looking for a review of this even though it only requires a testcase
change due to the use of lambda expressions.
Since this is the first of these I've encountered I thought I better
play it safe, but generally speaking, are we ok
to skip the
Hi Peter/David, we have 2000 runs without a single failure.
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/23/14, 12:10 PM, srikalyan wrote:
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because
On 24/01/2014 6:10 AM, srikalyan wrote:
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because the r is used later in the code and must not be assigned
pending unless it is not null(this was as is
Hi David, yes thats right, only benefit i see is we can avoid assignment
to 'r' if pending is null.
--
Thanks
kalyan
On 1/23/14 4:33 PM, David Holmes wrote:
On 24/01/2014 6:10 AM, srikalyan wrote:
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
On 24/01/2014 11:53 AM, srikalyan chandrashekar wrote:
Hi David, yes thats right, only benefit i see is we can avoid assignment
to 'r' if pending is null.
I'm okay with either version.
David
--
Thanks
kalyan
On 1/23/14 4:33 PM, David Holmes wrote:
On 24/01/2014 6:10 AM, srikalyan wrote:
Hi All
Could you review the bug fix for JDK-8032050.
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/
Description:
This rare happened failure caused because when RMID starts. It don't
guarantee sun.rmi.server.Activation.startActivation finishes.
Fix by adding a iterative getSystem with
Hi Stuart,
Thanks for the suggestion! sorry for reply this mail late as i was busy
on other tasks
The webrev has been in the internal review process. Based on the
suggestion, here is a summary of changes:
1. Add othervm options to tests:
java/rmi/Naming/DefaultRegistryPort.java
21 matches
Mail list logo
