Hi David,
your change causes build problems with ubuntu 12.04. Result is:
make[2]: Entering directory `/usr/local/src/jdk8tl/jdk/makefiles'
make[2]: *** No rule to make target
`/usr/local/src/jdk8tl/build/linux-x86-normal-server-release/images/lib/jfr.jar',
needed by `all'. Stop.
make[2]: Le
On 21/08/2013 01:04, Dan Xu wrote:
Hi,
MaxPathLength.java testcase failed intermittently. And File.mkdirs()
does not throw any exceptions when it fails, which makes it even
harder for the diagnosis. As Alan suggested, I'd like to change it to
Files.createDirectories to get detailed exceptions
On 21/08/2013 01:04, Mike Duigou wrote:
:
The root repo test targets currently trigger off the repo name in order to know
which/test/Makefile to run. ie. jdk_util triggers running the
jdk/test/Makefile. Would it be possible to retain the repo prefix for the meta group
names? ie. jdk_core jdk_s
Changeset: c8da1b6a9762
Author:mduigou
Date: 2013-08-20 17:44 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/c8da1b6a9762
8023433: Improve 'make help'
Reviewed-by: tbell
! NewMakefile.gmk
Hi,
MaxPathLength.java testcase failed intermittently. And File.mkdirs()
does not throw any exceptions when it fails, which makes it even harder
for the diagnosis. As Alan suggested, I'd like to change it to
Files.createDirectories to get detailed exceptions once a failure
happens. Thanks!
On Aug 20 2013, at 05:13 , Alan Bateman wrote:
>
> For some time now we have been chipping away at the make files that are used
> to run the jdk tests. Mike has his wielded his axe on several occasions
> recently to remove logic and rules that are no longer needed.
I've started to sharpen my
Changeset: 720992953d43
Author:jjg
Date: 2013-08-20 15:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/720992953d43
8013887: In class use, some tables are randomly unsorted
Reviewed-by: bpatel
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
Changeset: 79e341614c50
Author:jjg
Date: 2013-08-20 14:55 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79e341614c50
8022080: javadoc generates invalid HTML in Turkish locale
Reviewed-by: bpatel
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.jav
On Aug 20 2013, at 04:57 , Paul Sandoz wrote:
> [resending unsigned, sorry if a dup arrives later on]
>
> On Aug 19, 2013, at 9:04 PM, Mike Duigou wrote:
>
>> Looks pretty good. Two points concern me:
>>
>> - Every source of non-crypto quality randoms should explicitly document that
>> it sh
Changeset: 0f88e3d3d250
Author:ksrini
Date: 2013-08-20 14:15 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0f88e3d3d250
7179455: tools/javac/processing/model/testgetallmembers/Main.java fails against
JDK 7 and JDK 8
Reviewed-by: jjg
! test/tools/javac/processing/mode
Changeset: a76dc1b4c299
Author:jjg
Date: 2013-08-20 14:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a76dc1b4c299
8020663: Restructure some properties to facilitate better translation
Reviewed-by: darcy
!
src/share/classes/com/sun/tools/doclets/internal/toolkit/re
On 08/20/2013 12:58 PM, Jonathan Gibbons wrote:
> Henry,
>
> I think you should sort out the issues you are having with jtreg.
> It is not yet clear to me that this is a jtreg issue as much as a test
> or library issue.
>
Thanks Jon for the help on jtreg issue, the test can be easily fixed by
a
Just check with JPRT, the test passes on both 64 and 32 bit platforms.
Was meant: I've just checked with JPRT, and the test passes on both 64
and 32 bit platforms.
Sincerely yours,
Ivan
On 08/20/2013 04:09 PM, Eamonn McManus wrote:
> It might occur to me to look at valueOf(Class, String) if I was
> looking for a method to convert a string to an enum constant, but I
> don't think it would occur to me to look there if I was looking for a
> method to get all the values of an enum. I'
FWIW. From the maven artifacts I looked at last year (essentially ran
jdeps), there is only one reference to these 2 sun.misc classes:
http://grepcode.com/file/repo1.maven.org/maven2/net.sf.ingenias/iaf/1.3/ingenias/jade/EventPanelLogger.java
Mandy
On 8/20/2013 12:33 PM, Alan Bateman wrote:
It might occur to me to look at valueOf(Class, String) if I was
looking for a method to convert a string to an enum constant, but I
don't think it would occur to me to look there if I was looking for a
method to get all the values of an enum. I'm sure plenty of people end
up using MyEnum.class.getE
Changeset: 58da1296c6b3
Author:darcy
Date: 2013-08-20 12:15 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58da1296c6b3
8011043: Warn about use of 1.5 and earlier source and target values
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
!
On 07/24/2013 09:14 AM, Alan Bateman wrote:
> On 16/07/2013 12:05, Henry Jen wrote:
>> Hi,
>>
>> Please review the webrev at,
>>
>> http://cr.openjdk.java.net/~henryjen/tl/8016846/0/webrev/
>>
>> The test is mostly contributed by Ben Evans.
>>
>> Cheers,
>> Henry
>>
> It looks okay to me, just a co
Eamonn,
See
http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#valueOf(java.lang.Class,%20java.lang.String)
Note that for a particular enum type T, the implicitly declared public
static T valueOf(String) method on that enum may be used instead of
this method to map from a name to t
On 20/08/2013 19:07, Mike Duigou wrote:
Hello all;
This is a proposal to deprecate (Any votes for outright removal?)
No objection to deprecating it but I assume anyone compiling against it
is seeing a warning already (because it's a JDK internal class).
We've historically being cautious about
On 20/08/2013 19:54, Mike Duigou wrote:
Paul Sandoz pointed out (again) that I let synchronized slip back into the
split out patch.
http://cr.openjdk.java.net/~mduigou/JDK-8023306/1/webrev/
Corrects this error.
Mike
Looks okay to me, I guess I would Entry e rather than p but that's just
a p
On 08/20/2013 07:54 PM, Mike Duigou wrote:
Paul Sandoz pointed out (again) that I let synchronized slip back into the
split out patch.
http://cr.openjdk.java.net/~mduigou/JDK-8023306/1/webrev/
Yes, the sycn free versions look better.
-Chris.
Corrects this error.
Mike
On Aug 20 2013, at
Paul Sandoz pointed out (again) that I let synchronized slip back into the
split out patch.
http://cr.openjdk.java.net/~mduigou/JDK-8023306/1/webrev/
Corrects this error.
Mike
On Aug 20 2013, at 11:11 , Mike Duigou wrote:
> Hello all;
>
> This is a small changeset I have split out from the
+1
On Aug 20, 2013, at 11:11 AM, Mike Duigou wrote:
> This is a small changeset I have split out from the mostly unrelated
> JDK-8021591. This changeset adds Map.replace(key,value) and
> Map.replace(key,oldValue,newValue) implementations to TreeMap that are more
> efficient that that provided
On 08/20/2013 11:07 AM, Mike Duigou wrote:
Hello all;
This is a proposal to deprecate (Any votes for outright removal?)
Yes; take them out!
-Joe
+1
On Aug 20, 2013, at 11:07 AM, Mike Duigou wrote:
> Any votes for outright removal?
Hello all;
This is a small changeset I have split out from the mostly unrelated
JDK-8021591. This changeset adds Map.replace(key,value) and
Map.replace(key,oldValue,newValue) implementations to TreeMap that are more
efficient that that provided by the defaults in Map.
webrev: http://cr.openjdk
Hello all;
This is a proposal to deprecate (Any votes for outright removal?) two classes
in the private sun.misc package. These are ancient vestigial classes who's
usage has long been eliminated in the JDK in favour of
java.util.Arrays.sort(T[], Comparator) and java.util.Arrays.sort(T[], int
s
As I mentioned earlier in the thread, it's kind of user-hostile for
the Enum javadoc to send the user to the JLS instead of just saying,
even briefly, what the methods are. Even more so since it doesn't
actually link to the relevant section of the JLS or in fact to the JLS
at all. This is not a com
Looks very good!
On Aug 20 2013, at 05:13 , Alan Bateman wrote:
>
> For some time now we have been chipping away at the make files that are used
> to run the jdk tests. Mike has his wielded his axe on several occasions
> recently to remove logic and rules that are no longer needed. One of the
Changeset: 1ccc7bbee0bb
Author:attila
Date: 2013-08-20 11:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ccc7bbee0bb
8023250: Update JavaScript code in JDK for changes in iteration over Java arrays
Reviewed-by: sundar, sla
! src/share/classes/com/sun/tools/hat/resources/
Hi,
not sure about mailing group, but here is a test i wrote
https://gist.github.com/artkoshelev/6256684.
Review please and add it to testbase.
Artem
Changeset: c17d6543b30f
Author:psandoz
Date: 2013-08-20 17:36 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c17d6543b30f
8023367: Collections.emptyList().sort((Comparator)null) throws NPE
Reviewed-by: alanb, mduigou
! src/share/classes/java/util/Collections.java
! test/java
I think this look OK Alan
Best
Lance
On Aug 20, 2013, at 8:13 AM, Alan Bateman wrote:
>
> For some time now we have been chipping away at the make files that are used
> to run the jdk tests. Mike has his wielded his axe on several occasions
> recently to remove logic and rules that are no long
Looks OK to me.
On Aug 20 2013, at 08:39 , Paul Sandoz wrote:
> Hi,
>
> Please see below for a simple fix to stop throwing an NPE on
> Collections.emptyList().sort(null);
>
> Paul.
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/67e00b862126
>
> diff -r 3647aab7b1d5 src/share/classes/ja
On 20/08/2013 16:39, Paul Sandoz wrote:
Hi,
Please see below for a simple fix to stop throwing an NPE on
Collections.emptyList().sort(null);
Paul.
Looks okay to me.
-Alan
Thank you Alan!
The update to BufferedInputStream looks okay to me. I guess we don't
actually need to check the size in the constructor, OOME will be
thrown anyway. Usually constants are in uppercase and maybe we should
just do this while we are here (so this means rename defaultBufferSize
to
Hi,
Please see below for a simple fix to stop throwing an NPE on
Collections.emptyList().sort(null);
Paul.
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/67e00b862126
diff -r 3647aab7b1d5 src/share/classes/java/util/Collections.java
--- a/src/share/classes/java/util/Collections.java Tue
Changeset: e811fb09a1dc
Author:jfranck
Date: 2013-08-20 17:21 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e811fb09a1dc
8019243: AnnotationTypeMismatchException instead of MirroredTypeException
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/code/Attribute.j
Changeset: 961cdea684b5
Author:sla
Date: 2013-08-20 16:53 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/961cdea684b5
8016727: test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently
Reviewed-by: alanb
! test/com/sun/jdi/sde/TemperatureTableTest.java
Well, I presume other learning materials for Java (tutorials, ... for
dummies, etc) will explain the existence of these methods as part of the
language feature that is "enum"s.
Quite where the bytecodes for the methods comes from is implementation
detail that should not need to be documented i
Thanks Martin!
New webrev:
http://cr.openjdk.java.net/~shade/8023234/webrev.01/
On 08/20/2013 03:06 AM, Martin Buchholz wrote:
> Thanks. Looks good.
>
> Style suggestions for the test:
>
> +while(!isDone && !isInterrupted()) {
> SPC after keywords.
Fixed.
> I think it's more rea
So are you recommending not to alter the Javadoc of Enum to mention this
fact? Going to the JLS is great for compiler developers, but it's not the
first place for the end user.
On Tue, Aug 20, 2013 at 8:48 AM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:
> Paul,
>
> Enums are well cov
Paul,
Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2,
Enum Body Declarations, beginning at the line
"In addition, if E is the name of an enum type, then that type has the
following implicitly declared static methods:"
-- Jon
On 08/20/2013 06:27 AM, Paul Benedict wro
Changeset: 55da6b3a6940
Author:kizune
Date: 2013-08-20 17:34 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55da6b3a6940
7182350: Regression in wording of unchecked warning message
Reviewed-by: mcimadamore, jjg
! src/share/classes/com/sun/tools/javac/comp/Check.java
!
[resending unsigned, sorry if a dup arrives later on]
On Aug 19, 2013, at 9:17 PM, Mike Duigou wrote:
> - documentation of "bound" should mention that it is exclusive rather than
> relying on the return documentation.
>
I have updated both webrevs and the spec diff to be consistent when refer
Jon, it's not a problem with the method docs, per se. The issue is about
how the generation isn't documented. My questioning started because I was
using several enums without javadoc available, but I did have the source
available, and couldn't figure out how the method came to be. Since I've
asked,
[resending unsigned, sorry if a dup arrives later on]
On Aug 20, 2013, at 1:46 PM, Doug Lea wrote:
> On 08/19/2013 07:07 AM, Paul Sandoz wrote:
>> Hi,
>>
>> This patch updates Random and ThreadLocalRandom to have functional
>> consistency (for the most part) across Random, ThreadLocalRandom an
[resending unsigned, sorry if a dup arrives later on]
On Aug 19, 2013, at 9:18 PM, Henry Jen wrote:
> Hi,
>
> Please review the webrev at
> http://cr.openjdk.java.net/~henryjen/tl/8023275/0/webrev/
>
> The patch adds override on default methods for a couple wrapping classed
> and delegate thos
[resending unsigned, sorry if a dup arrives later on]
On Aug 19, 2013, at 9:04 PM, Mike Duigou wrote:
> Looks pretty good. Two points concern me:
>
> - Every source of non-crypto quality randoms should explicitly document that
> it should not be used for generating keys or other crypto purpose
Paul.
For some time now we have been chipping away at the make files that are
used to run the jdk tests. Mike has his wielded his axe on several
occasions recently to remove logic and rules that are no longer needed.
One of the next steps needs to be to remove the definitions of the test
targets fr
On 08/19/2013 07:07 AM, Paul Sandoz wrote:
Hi,
This patch updates Random and ThreadLocalRandom to have functional consistency
(for the most part) across Random, ThreadLocalRandom and SplittableRandom:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/
A couple
On 20/08/2013 07:23, Miroslav Kos wrote:
Hi everybody,
I prepared a new changeset containing no copyright changes so we can
get further: http://cr.openjdk.java.net/~mkos/8022885/webrev.01/
We will discuss rngom changes separately and if necessary, it will be
updated with a new integration.
Changeset: e17da8b09f5e
Author:dholmes
Date: 2013-08-20 03:18 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e17da8b09f5e
8023311: Clean up profile-includes.txt
Reviewed-by: alanb
! makefiles/profile-includes.txt
On 20/08/2013 5:02 PM, Alan Bateman wrote:
On 20/08/2013 00:33, David Holmes wrote:
http://cr.openjdk.java.net/~dholmes/8023311/webrev/
Patch inlined below
This is a trivial cleanup following on from an earlier change under
8017570. JFR was moved from profile compact3 to the full JRE but not
a
On 20/08/2013 00:33, David Holmes wrote:
http://cr.openjdk.java.net/~dholmes/8023311/webrev/
Patch inlined below
This is a trivial cleanup following on from an earlier change under
8017570. JFR was moved from profile compact3 to the full JRE but not
all the variables in profile-includes.txt w
Changeset: 53ea4b5cef9b
Author:sla
Date: 2013-08-20 08:59 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53ea4b5cef9b
8022071: Some vm/jvmti tests fail because cannot attach to the Java virtual
machine
Reviewed-by: erikj, sspitsyn
! makefiles/CompileNativeLibraries.gmk
+ ma
58 matches
Mail list logo
