Hi, Volker.
Just wanted to say that in addition to preparing for JavaOne (next week!),
we're also busy fixing bugs in anticipation of JDK 8 ZBB milestone on 24 Oct
[1].
Thanks,
iris
[1]: http://openjdk.java.net/projects/jdk8/milestones
-Original Message-
From: Phil Race
Sent: Wednesd
Changeset: 0ef7ddef9de0
Author:psandoz
Date: 2013-09-19 20:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ef7ddef9de0
8024405: Spliterators.spliterator should support CONCURRENT characteristic
Reviewed-by: martin
! src/share/classes/java/util/Spliterator.java
! src/share
Changeset: f954d3f4d192
Author:sundar
Date: 2013-09-19 13:34 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f954d3f4d192
8025048: true as case label results in ClassCastException
Reviewed-by: lagergren
! src/jdk/nashorn/internal/codegen/Attr.java
+ test/script/basic/JDK-
Changeset: 9a75bdb249a2
Author:jjg
Date: 2013-09-19 19:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9a75bdb249a2
8025110: TreeCopier does not correctly copy LabeledStatementTree
Reviewed-by: jjg
Contributed-by: Werner Dietl
! src/share/classes/com/sun/tools/javac
Changeset: f36714707c38
Author:psandoz
Date: 2013-09-18 10:49 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f36714707c38
8025002: "".codePoints().sorted().iterator().hasNext() causes
NegativeArraySizeException
Reviewed-by: henryjen, alanb
! src/share/classes/java/lang/Char
Hi Alex,
The class can be compiled into the current directory (scratch), this
will eliminate:
a. the deletion of the files and allow jtreg to clean out the scratch
directory
b. uses of TEST_CLASSES_DIR.getAbsolutePath().
Thanks
Kumar
Hi,
please review my fix for 8025076: Fix for JDK-
Thanks for checking. Looks good to me.
Naoto
On 9/19/13 3:12 PM, Alexander Zuev wrote:
Hi Naoto,
I've checked that it works in C locale - since I'm setting LC_CTYPE to UTF-8
before calling both javac and java everything works as expected.
With best regards,
/Alex
20.09.2013, в 1:34, Naot
Hi,
Please help review the change for #6233323.
http://cr.openjdk.java.net/~sherman/6233323/webrev
Background info:
ZipFile.getEntry() is implemented the way that it first tries to find the entry
with the exactly matched name. If failed, it then tries to see if the specified
name ends with a s
The webrev has been updated with Joe's comments addressed.
On 09/19/13 00:11, David Holmes wrote:
> On 19/09/2013 9:59 AM, Eric McCorkle wrote:
>> This still needs to be reviewed.
>
> You seem to have ignored Joe's comments regarding the change to Modifier
> being incorrect.
>
> David
>
>> On 0
Hi Naoto,
I've checked that it works in C locale - since I'm setting LC_CTYPE to UTF-8
before calling both javac and java everything works as expected.
With best regards,
/Alex
20.09.2013, в 1:34, Naoto Sato написал(а):
> Hi Alex,
>
> Should the test case also check the encoding of the pl
On 09/19/2013 09:55 PM, David M. Lloyd wrote:
Imagine:
// this throws IllegalAccessException. If it didn't...
MethodHandle mh = MethodHandles.lookup()
.in(String.class)
.findVirtual(
Field.class,
"get",
Hi Aleksej,
Looks like the getLength() method has the same problem.
Joe
On 9/17/2013 5:01 AM, Aleksej Efimov wrote:
Hi Everyone,
There is a bug [1] in JAXP about transformation of one-item sized node
list:
When the length of nodelist which is passed to a XSLT extension
function is 1, the no
On Sep 12, 2013, at 7:24 PM, John Rose wrote:
> Please review this change for a change to the JSR 292 implementation:
>
> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
>
> Summary: Align MH semantic with bytecode behavior of constructor and static
> member accesses, regarding invocatio
Hi Alex,
Should the test case also check the encoding of the platform? Does it
work under the environment where the encoding is, say US-ASCII?
Naoto
On 9/19/13 9:43 AM, Alexander Zuev wrote:
Hi,
please review my fix for 8025076: Fix for JDK-8017248 breaks jprt
submission for non-unicode
On Sep 18, 2013, at 5:05 PM, Christian Thalinger
wrote:
> src/share/classes/java/lang/invoke/MethodHandles.java:
>
> + * methods as if they were normal methods, but the JVM verifier rejects
> them.
>
> I think you should say "JVM byte code verifier" here.
Done. s/byte code/bytecode/.
On Sep 17, 2013, at 6:03 PM, Remi Forax wrote:
> On 09/18/2013 02:08 AM, Brian Burkhalter wrote:
>> The proposed patch has been updated at the same location:
>>
>> http://cr.openjdk.java.net/~bpb/8024331/.
>>
>> Thanks,
>>
>> Brian
>
> looks good.
>
> Rémi
Thanks, Rémi
JDK 8 Reviewers: This
Changeset: 2375ce96e80d
Author:vromero
Date: 2013-09-19 20:57 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2375ce96e80d
8024437: Inferring the exception thrown: sometimes fails to compile
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/
On 09/19/2013 07:03 AM, Peter Levart wrote:
On 09/18/2013 05:21 PM, David M. Lloyd wrote:
On 09/03/2013 12:16 PM, Peter Levart wrote:
[...]
*AND* that Reflection.getCallerClass() can only be called from within
methods annotated with @CallerSensitive.
Now for that part, the public API equivale
Looks good.
Best regards,
Vladimir Ivanov
On 9/13/13 5:02 AM, John Rose wrote:
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001109/webrev.00/
The change is mostly to javadoc and unit tests, documenting and testing some
corner cases
On 9/19/2013 1:52 AM, Alan Bateman wrote:
On 18/09/2013 20:45, Xueming Shen wrote:
OK, how about this one? I'm even using lambda:-)
http://cr.openjdk.java.net/~sherman/8023113/webrev/
-Sherman
Looks okay except that Files.list returns a stream that needs to be closed to
avoid leaking resour
Recommended changes made:
http://cr.openjdk.java.net/~drchase/8022701/webrev.04/
Test with jtreg (for pass and for induced failure) on MacOS,
not sure what additional other testing is desired since it is entirely in the
libraries.
I included code to handle the case of a broken field-referencing
Changeset: 278873b2b3f8
Author:sherman
Date: 2013-09-19 10:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/278873b2b3f8
8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
Summary: updated the test case
Reviewed-by: alanb
! test/tools/jar/ChangeDir.java
Hi,
please review my fix for 8025076: Fix for JDK-8017248 breaks jprt
submission for non-unicode locales
The idea of the fix is to replace test case with the complex file
name in it by the
test that generates and compiles such file at the run time.
The webrev can be found at:
http://
Changeset: 7557062d2dd2
Author:plevart
Date: 2013-09-19 16:14 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7557062d2dd2
8011940: java.lang.Class.getAnnotations() always enters synchronized method
Reviewed-by: jfranck, chegar, psandoz, shade
! src/share/classes/java/lang/Cl
Changeset: 0cfd5baa7154
Author:ohrstrom
Date: 2013-09-19 08:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0cfd5baa7154
8024609: sjavac assertion fails during call to BuildState.collectArtifacts
Reviewed-by: jjg
! src/share/classes/com/sun/tools/sjavac/BuildState.ja
Thanks Joel,
I will push this now.
Regards, Peter
On 09/18/2013 11:28 AM, Joel Borggrén-Franck wrote:
Looks good Peter,
cheers
/Joel
On 2013-09-15, Peter Levart wrote:
Hi,
I rebased the changes and added @bug tag to test. Here's new webrev:
http://cr.openjdk.java.net/~plevart/jdk8-tl/Anno
Hi Phil,
I'm open to any good ideas.
The current solution is pragmatic, simple and it has no impact on
existing platforms.
The other possibility I see is to put the 'dladdr' implantation into
its own library (something equivalent to "libjli") and link that
library to "libawt". But I currently do
Hi,
w.r.t the one issue below : is the awt load library code the only place you
need/are doing this ? If someone else (hotspot, core-libs) already
assented to this
then I guess I could too but I'd like to hear for sure that hotspot and
core-libs
teams both agree to this approach and whether th
Changeset: 22e9f0067b5a
Author:kizune
Date: 2013-09-19 17:04 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22e9f0067b5a
8017248: Compiler Diacritics Issue
Reviewed-by: naoto
! src/share/classes/sun/launcher/LauncherHelper.java
+ test/tools/launcher/8017248/ClassAÌ.java
+ t
Changeset: 36e342dd57e2
Author:kizune
Date: 2013-09-19 17:05 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/36e342dd57e2
8017248: Compiler Diacritics Issue
Reviewed-by: naoto
! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java
Sorry for the late reply,
On 8/25/2013 7:03 AM, Kasper Nielsen wrote:
>
>> Hi,
>>
>> just 2 short questions/commons on java.lang.reflect.Parameter
>>
>> 1)
>> I was wondering if there is any reason for java.lang.reflect.Parameter not
>> to expose the index field?
>>
>
> "Not sure what you mean by
On 09/18/2013 05:21 PM, David M. Lloyd wrote:
On 09/03/2013 12:16 PM, Peter Levart wrote:
[...]
*AND* that Reflection.getCallerClass() can only be called from within
methods annotated with @CallerSensitive.
Now for that part, the public API equivalent
(StackTraceFrame.getCallerClass() or whate
Hi Phil,
thank you for looking at the changes. Please find my answers inline:
On Thu, Sep 19, 2013 at 12:22 AM, Phil Race wrote:
> Volker,
>
> I've skimmed the client related changes - mostly based on the descriptions.
> I'll look in more detail as soon as I can after JavaOne. We also have som
Hi,
the HashSet used for the script engine factories caused the random
behaviour.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8011697
Webrev:
http://cr.openjdk.java.net/~arieber/8011697/webrev.01/
Please review and sponsor required...
thanks
Andreas
On 19.09.2013 08:55, Andreas Rieber w
On 18/09/2013 20:45, Xueming Shen wrote:
OK, how about this one? I'm even using lambda:-)
http://cr.openjdk.java.net/~sherman/8023113/webrev/
-Sherman
Looks okay except that Files.list returns a stream that needs to be
closed to avoid leaking resources.
As a side note, as cleanup is attempti
On 18/09/2013 19:27, Paul Sandoz wrote:
Hi,
Please review a fix for CharSequence.codePoints:
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e040a0dda7e4
(That change set should apply cleanly to tl.)
The incorrect spliterator characteristics were being reported when constructing
the stre
On 09/19/2013 09:27 AM, Florian Weimer wrote:
On 09/19/2013 01:00 AM, Henry Jen wrote:
Class names can contain '\' and other characters which are problematic
on Windows.
Thanks for reviewing, I suspect you are pointing out a potential issue
to look at, not that the problem exists in current
On 09/19/2013 01:00 AM, Henry Jen wrote:
Class names can contain '\' and other characters which are problematic
on Windows.
Thanks for reviewing, I suspect you are pointing out a potential issue
to look at, not that the problem exists in current implementation.
According to JLS 3.8, the clas
38 matches
Mail list logo
