http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8033278
The fix for 8032585 [1] introduced a regression: in some cases access
check on a reference class is omitted.
The fix is to ensure that access check on a reference class is always
performed
On 01/27/2014 12:31 PM, Philip Hodges wrote:
I did not predict that it would be a "sprintf". It's not going to be
consistently misused anything like so frequently.
I compared it to the unescaped XML generation antipattern.
I have not seen any technical justifications whatsoever so far, just
i
On 1/30/14 3:13 AM, Paul Sandoz wrote:
On Jan 30, 2014, at 3:57 AM, Stuart Marks wrote:
Then, awaitInitialized seems straightforward until you see that the
condition is waiting for the value of a final variable to change! JLS sec
17.5 [1] allows all sorts of optimizations for final fields
Changeset: 11b83c913cca
Author:attila
Date: 2014-01-30 20:14 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/11b83c913cca
8032681: Issues with Nashorn
Reviewed-by: ahgross, jlaskey, sundar
+ src/jdk/internal/dynalink/linker/GuardedTypeConversion.java
! src/jdk/internal/dy
On 1/30/14 1:09 AM, Daniel Fuchs wrote:
I wonder whether you should replace the assert in the
constructor by an explicit null check:
- assert systemStub != null
+ if (systemStub == null) throw new NullPointerException();
The reason I see is that before your change, an object constructed
with a
On 1/30/14 2:35 AM, David Holmes wrote:
On 30/01/2014 5:34 PM, Tristan Yan wrote:
Hi Stuart
I didn’t make my comment clear. You set interrupted as true when thread
gets interrupted. Here it's still going to wait until systemStub is not
null. Why do you still need interrupt current thread in th
Hotspot questions belong on hotspot lists. cc'ing hotspot-dev and
(trying to) bcc core-libs-dev.
David
On 23/01/2014 9:37 AM, Remi Forax wrote:
On 01/22/2014 11:37 PM, Robert Stupp wrote:
Is there any documentation available which optimizations Hotspot can
perform and what "collecting a garba
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 revie
Am 22.01.2014 um 17:33 schrieb "David M. Lloyd" :
> The concept of explicit deserialization constructors is interesting and is
> something I've explored a little bit in the context of JBoss Marshalling.
...
> The idea with a serialization-aware constructor is that each serializable
> class cons
Please please please drop StringJoiner from Java 1.8 before it is too late.
It is not needed. It does not add value. It is an embarrassment.
We did without it for years. It is not long long overdue. We do not need it now.
It does not need to be in the very first Java 1.8 release.
Try leaving it ou
I did not predict that it would be a "sprintf". It's not going to be
consistently misused anything like so frequently.
I compared it to the unescaped XML generation antipattern.
I have not seen any technical justifications whatsoever so far, just
inexplicable enthusiasm.
It is like giving young
Hi Rémi,
> With latest jdk8, it's not true anymore.
> (and most of the time the iterator object is not created anymore at least
> with jdk7+).
Could you please explain it a little bit more? When is that optimization
applied,
e.g. what conditions are required for this optimization, since which v
Looks good to me too.
thanks,
-michael
On 14年01月29日 10:14 下午, Masayoshi Okutsu wrote:
Looks good.
Masayoshi
On 1/30/2014 5:31 AM, Aleksej Efimov wrote:
Masayoshi, Sean,
Thank you for the review and your comments.
I have prepared a second version of the fix [1] without the
.properties file
On 30/01/2014 15:36, Miroslaw Niemiec wrote:
Hi Alan,
I have corrected the test file according to your suggestions
The new webrev:
http://cr.openjdk.java.net/~miroslawzn/8011944/webrev.03/
Looks good, thanks for this.
This backport reminds me that maybe it is time to consider removing the
me
On 30/01/2014 14:51, Peter Levart wrote:
I Just commited the version with no change to ReferenceQueue
line to jdk9/dev. If there is a bug in javac and the code would not
compile as is, the change to this line should be committed as part of
javac fix, right?
It's good to get this change in.
On 1/30/2014 5:46 AM, Alan Bateman wrote:
On 30/01/2014 02:34, Miroslaw Niemiec wrote:
The copyright header added to
test/java/util/Arrays/TimSortStackSize.java:
http://cr.openjdk.java.net/~miroslawzn/8011944/webrev.02/
- Miroslaw
Thanks, just a few minor nits to look at before you push this:
Changeset: c59fb10cb0b5
Author:sundar
Date: 2014-01-30 19:45 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c59fb10cb0b5
8032949: Nashorn linkages awry
Reviewed-by: jlaskey, attila, ahgross
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/r
On 01/30/2014 03:46 PM, Alan Bateman wrote:
On 29/01/2014 19:10, Mandy Chung wrote:
On 1/29/2014 5:09 AM, Peter Levart wrote:
Since I don't know what should be the correct behaviour of javac, I
can leave the Reference.java changes as proposed since it compiles
in both cases. Or should I rev
On 29/01/2014 19:10, Mandy Chung wrote:
On 1/29/2014 5:09 AM, Peter Levart wrote:
Since I don't know what should be the correct behaviour of javac, I
can leave the Reference.java changes as proposed since it compiles in
both cases. Or should I revert the change to declaration of local
varia
On 30/01/2014 09:09, Daniel Fuchs wrote:
Hi Stuart,
I wonder whether you should replace the assert in the
constructor by an explicit null check:
- assert systemStub != null
+ if (systemStub == null) throw new NullPointerException();
The reason I see is that before your change, an object const
On 30/01/2014 02:34, Miroslaw Niemiec wrote:
The copyright header added to
test/java/util/Arrays/TimSortStackSize.java:
http://cr.openjdk.java.net/~miroslawzn/8011944/webrev.02/
- Miroslaw
Thanks, just a few minor nits to look at before you push this:
- The import at L30 is mis-aligned.
- The
Changeset: eca774d33fa4
Author:sundar
Date: 2014-01-30 19:04 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/eca774d33fa4
8032954: Nashorn: extend Java.extend
Reviewed-by: attila, jlaskey, ahgross
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! test/sc
Changeset: a43c125b03dc
Author:sundar
Date: 2014-01-30 18:34 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a43c125b03dc
8032944: Improve reflection in Nashorn
Reviewed-by: jlaskey, attila, ahgross
! src/jdk/nashorn/internal/objects/NativeObject.java
+ test/script/sandbo
On Jan 30, 2014, at 3:57 AM, Stuart Marks wrote:
>
> Then, awaitInitialized seems straightforward until you see that the condition
> is waiting for the value of a final variable to change! JLS sec 17.5 [1]
> allows all sorts of optimizations for final fields, but they all are
> qualified with
On 30/01/2014 5:34 PM, Tristan Yan wrote:
Hi Stuart
I didn’t make my comment clear. You set interrupted as true when thread
gets interrupted. Here it's still going to wait until systemStub is not
null. Why do you still need interrupt current thread in this case.
Because the golden rule of inter
Hi Stuart,
I wonder whether you should replace the assert in the
constructor by an explicit null check:
- assert systemStub != null
+ if (systemStub == null) throw new NullPointerException();
The reason I see is that before your change, an object constructed
with a null systemStub would have s
26 matches
Mail list logo
