Changeset: d52081a08d11
Author:mchung
Date: 2012-08-24 22:55 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d52081a08d11
7193339: Prepare system classes be defined by a non-null module loader
Reviewed-by: alanb, dholmes, dsamersoff, sspitsyn, psandoz
! src/share/classes/com/
Currently, jtreg incorrectly confuses the concept of the /directory/ in
which the test's class will be written with the /classpath/ used to
locate all of the test's classes, including any library classes. It
provides env variable TESTCLASSES and system property test.classes, and
tests use these
On 8/24/2012 3:44 PM, David Holmes wrote:
My other query with these changes is whether we are certain that using
the specified loader rather than the boot loader will always be correct.
Yes I'm to my best knowledge but I'm looking to the reviewers to tell me
otherwise :)
The class being loa
On 25/08/2012 1:53 AM, Mandy Chung wrote:
On 8/23/2012 6:27 PM, David Holmes wrote:
Another way to simplify this would be to add a new overload of
Class.forName():
public static Class forName(String name, boolean initialize)
That way the loader argument could be dropped completely from a numb
On 08/23/2012 09:43 PM, Stuart Marks wrote:
> However, there are several cases where the following occurs:
>
> SUBDIRS_MAKEFLAGS += JAVAC_WARNINGS_FATAL=true
>
> and this is **not** overridable on the command line.
But it is! Use:
make SUBDIRS_MAKEFLAGS=""
instead of
SUBDIRS_MAKEFLAGS=""
On 8/24/12 2:42 AM, Andrew Hughes wrote:
However, once the whole build is warning free, would it not be preferable
to remove these and just set JAVAC_WARNINGS_FATAL=true when doing development
builds?
The problem I see is someone new coming to OpenJDK and not being able to
simply build it (with
Oops, thanks for your correction, Phil.
Sorry, I wasn't aware about that difference.
-Ulf
Am 24.08.2012 21:40, schrieb Phil Race:
It may not be enforced by tools, but I don't think you can be listed as
a reviewer there unless you have the JDK 8 project reviewer attribute :-
Alan does - http://
It may not be enforced by tools, but I don't think you can be listed as
a reviewer there unless you have the JDK 8 project reviewer attribute :-
Alan does - http://openjdk.java.net/census#alanb
but you don't - http://openjdk.java.net/census#ulfzibis
Now maybe you should ask if you can be ..
-
Kurchi,
thanks for listing me.
BTW, my official openJDK ID is ulfzibis
-Ulf
Am 24.08.2012 20:49, schrieb kurchi.subhra.ha...@oracle.com:
Changeset: bd91a601265c
Author:khazra
Date: 2012-08-24 11:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd91a601265c
7168172: (fs
Hi David,
Please see my response below. Thanks!
On 08/23/2012 06:53 PM, David Holmes wrote:
Hi Dan,
On 24/08/2012 7:46 AM, Dan Xu wrote:
Please review the fix of CR 7193406 at
http://cr.openjdk.java.net/~dxu/7193406/webrev/.
It cleans up warnings in the following java files.
src/share/clas
On 08/23/2012 05:17 PM, Andrew Hughes wrote:
- Original Message -
- Original Message -
Please review the fix of CR 7193406 at
http://cr.openjdk.java.net/~dxu/7193406/webrev/.
snip...
And it enables fatal warning flag in the following make file.
make/java/jar/Makefil
Changeset: bd91a601265c
Author:khazra
Date: 2012-08-24 11:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd91a601265c
7168172: (fs) Files.isReadable slow on Windows
Summary: Remove DACL checking for read access, also reviewed by
ulf.zi...@cosoco.de, zhong.j...@gmail.com
R
Changeset: a7cdfd16e36e
Author:alanb
Date: 2012-08-24 19:35 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7cdfd16e36e
7193933: More ProblemList.txt updates (8/2012)
Reviewed-by: darcy, chegar
! test/ProblemList.txt
Changeset: faf4528aea4e
Author:naoto
Date: 2012-08-24 10:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/faf4528aea4e
7193601: Build breakage with the fix to 6336885 (build-infra build)
Reviewed-by: mduigou
! makefiles/CompileJavaClasses.gmk
Looks fine to me.
-Chris.
On 24/08/12 14:47, Alan Bateman wrote:
I need a reviewer to update the ProblemList to exclude a number of
tests, see attached.
Minimally I'd like to get
sun/management/jmxremote/startstop/JMXStartStopTest.sh excluded. It was
removed from the exclude list recently [1]
Hi,
Here is a modified patch:
http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
The factory finders contain some format changes, a NetBeans format work.
The real changes are as the follows:
1) In factory classes: reinstated the implementation resolution
mechanism, the 3rd step mainly
Looks good Alan; approved,
-Joe
On 8/24/2012 6:47 AM, Alan Bateman wrote:
I need a reviewer to update the ProblemList to exclude a number of
tests, see attached.
Minimally I'd like to get
sun/management/jmxremote/startstop/JMXStartStopTest.sh excluded. It
was removed from the exclude list r
On 8/23/2012 6:27 PM, David Holmes wrote:
Another way to simplify this would be to add a new overload of
Class.forName():
public static Class forName(String name, boolean initialize)
That way the loader argument could be dropped completely from a number
of the use-cases.
Paul and Remi als
On 24/08/2012 11:25, Rémi Forax wrote:
I also vote for adding this overload, a lot of the usage of
Class.forName with three parameters are in fact just a way to load a
class without initialize it.
Rémi
I think this is worth looking at too. It would only change two or three
usages in this patc
I need a reviewer to update the ProblemList to exclude a number of
tests, see attached.
Minimally I'd like to get
sun/management/jmxremote/startstop/JMXStartStopTest.sh excluded. It was
removed from the exclude list recently [1] but has been causing havoc on
Windows since its release. I belie
I figured you did, but wanted to check. :)
So the perf hit was with c2 compilation? Were you able to check the
assembly (or enable inlining printing in hotspot) and see that lack of
inlining (and whatever further opto that enabled) was the difference by
simply adding a local or two? I'm legitimate
Vitaly Davidovich wrote:
So it sounds like avoiding these locals is basically trying to work
around current compiler limitations, rather than something more fundamental.
If javac did even a smidgen of optimization, this problem would
also go away.
I'm also curious if someone has actually n
In response to a similar question a few months ago, Tom Rodriguez mentioned
that c2 is not really susceptible to these redundant stores when making
inlining decisions. I guess c1 (and interpreter of course) might be but
then in those cases one's not getting max optimization anyway.
John Rose ment
Rémi Forax wrote:
Hi Dan,
I'm not sure to like the fact that you introduce some local variables
just to get ride of some warnings given that Hotspot compilers are
sometimes sensitive to that.
I think this practice should be discussed on this list before committing
this changeset.
Yes. We
I also vote for adding this overload, a lot of the usage of
Class.forName with three parameters are in fact just a way to load a
class without initialize it.
Rémi
On 08/24/2012 07:21 AM, serguei.spit...@oracle.com wrote:
I was thinking about the same.
But a CCC request is needed for such a ch
Hi all,
> On 08/23/2012 11:46 PM, Dan Xu wrote:
>>
>> Please review the fix of CR 7193406 at
>> http://cr.openjdk.java.net/~dxu/7193406/webrev/.
>>
>> It cleans up warnings in the following java files.
>>
>>src/share/classes/java/io/FilePermission.java
>>src/share/classes/java/util/ArrayDe
On 08/23/2012 11:46 PM, Dan Xu wrote:
Please review the fix of CR 7193406 at
http://cr.openjdk.java.net/~dxu/7193406/webrev/.
It cleans up warnings in the following java files.
src/share/classes/java/io/FilePermission.java
src/share/classes/java/util/ArrayDeque.java
src/share/classes/
Hi Mandy,
--- old/src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java Thu Aug
23 12:29:01 2012
+++ new/src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java Thu Aug
23 12:29:00 2012
@@ -52,7 +52,7 @@
AccessController.doPrivileged(new PrivilegedAction() {
- Original Message -
> Hi Dan,
>
> On 24/08/2012 7:46 AM, Dan Xu wrote:
> > Please review the fix of CR 7193406 at
> > http://cr.openjdk.java.net/~dxu/7193406/webrev/.
> >
> > It cleans up warnings in the following java files.
> >
> > src/share/classes/java/io/FilePermission.java
>
> I'm
- Original Message -
> On 8/23/12 5:12 PM, Andrew Hughes wrote:
> > Dan Xu wrote:
> >> Please review the fix of CR 7193406 at
> >> http://cr.openjdk.java.net/~dxu/7193406/webrev/.
> >> And it enables fatal warning flag in the following make file.
> >>
> >> make/java/jar/Makefile
> >
>
30 matches
Mail list logo