On 03/27/11 12:09, Alan Bateman wrote:
Mandy Chung wrote:
6381464: SimpleFormatter should use one single line format
This is a follow-up of the review for 7006814. I came up with a better
solution that allows a user to customize the output format for
SimpleFormatter.
You can specify
On 3/28/11 9:26 PM, Alan Bateman wrote:
Mandy Chung wrote:
:
This LoggingMXBean is needed to create a compliant MXBean; otherwise,
if PlatformLoggingImpl implements PlatformLoggingMXBean and
j.u.logging.LoggingMXBean directly, MBeanServer will throw a
NonCompliantMBeanException
On 3/28/11 9:45 PM, Alan Bateman wrote:
Mandy Chung wrote:
'\n' is a character added in the string created in L156 but not in a
format string in which %n is used to represents a newline.
I'm not sure about this one as \n might not be the line separator on
the platform. After creating
Changeset: 3e001dd50408
Author:mchung
Date: 2011-03-29 15:50 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3e001dd50408
7024172: Move BufferPoolMXBean and PlatformLoggingMXBean java.lang.management
Reviewed-by: alanb
+
Changeset: d2bbdd709307
Author:mchung
Date: 2011-03-29 15:58 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d2bbdd709307
6381464: SimpleFormatter should use one single line format
Summary: Define a new logging properties to support custom output format
Reviewed-by: alanb
!
Kumar,
This looks okay to me and the change in java_md.c is mostly bringing
back what you purged.
http://hg.openjdk.java.net/jdk7/jdk7/jdk/diff/de45eac5670e/src/solaris/bin/java_md.c
I briefly compared this fix with that changeset and a lot of testing to
verify this fix. Minor comment:
On 04/07/11 16:26, Joe Darcy wrote:
Revised webrev:
http://cr.openjdk.java.net/~darcy/6998871.3/
Looks good.
Mandy
Fix for 7032589: FileHandler leaking file descriptor of the file lock
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.00/
When a log file is currently being used, tryLock() will fail and it has
to close the file channel of the lock file
Thanks
Mandy
Hi Remi,
On 04/15/11 11:05, Rémi Forax wrote:
Hi Mandy,
if fc.close() throws an IOException , it goes wrong.
I think you need to put fc.close() in its own a try/catch(IOException).
That's a good point. I think it should throw IOException if anything
goes wrong with fc.close(). Revised the
On 04/15/11 13:41, Daniel D. Daugherty wrote:
On 4/15/2011 1:12 PM, Mandy Chung wrote:
Hi Remi,
On 04/15/11 11:05, Rémi Forax wrote:
Hi Mandy,
if fc.close() throws an IOException , it goes wrong.
I think you need to put fc.close() in its own a try/catch(IOException).
That's a good point
On 4/15/11 3:57 PM, Rémi Forax wrote:
Hi Mandy,
Minor nit, initializing available when declaring it is not necessary
because both
path (with or without exception) initialize it later.
Sure. Will fix that before the push.
otherwise, I'm Ok with the patch.
Thanks
Mandy
Changeset: 54d9513f87a4
Author:mchung
Date: 2011-04-15 23:42 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/54d9513f87a4
7032589: FileHandler leaking file descriptor of the file lock
Reviewed-by: forax, dcubed
! src/share/classes/java/util/logging/FileHandler.java
Hi Jing,
On 04/25/11 09:12, Jing LV wrote:
Hi Alan,
I have many trouble to find 7015589 - I thought it was on bugs.sun.com
but search never return a correct result. I guess it was the problem
of the system. However up to now I can find nothing. I aslo try it as
a CR number, but I don't find
On 3/7/11 10:10 PM, David Holmes wrote:
There was a glitch with the use of CTARGDIR (which isn't defined), so
now we check for the ergo file in LAUNCHER_PLATFORM_SRC. Webrev has
been updated - same location.
Looks good. Sorry I didn't catch that CTARGDIR isn't defined as it
exists in the
6381464: SimpleFormatter should use one single line format
This is a follow-up of the review for 7006814. I came up with a better
solution that allows a user to customize the output format for SimpleFormatter.
You can specify the format string using the java.util.Formatter syntax in
a new
Changeset: c3f5333e10e3
Author:mchung
Date: 2011-04-28 08:51 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c3f5333e10e3
7037081: Remove com.sun.tracing from NON_CORE_PKGS
Reviewed-by: ohair, jjg, jmasa
! make/docs/Makefile
! make/docs/NON_CORE_PKGS.gmk
Changeset: c7841bbe1227
Author:mchung
Date: 2011-04-28 08:46 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c7841bbe1227
7037081: Remove com.sun.tracing from NON_CORE_PKGS
Reviewed-by: ohair, jjg, jmasa
!
Changeset: 24ad188dc46c
Author:mchung
Date: 2011-04-29 08:51 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/24ad188dc46c
7039809: Remove @ConstructorProperties annotation from java.io.File class
Reviewed-by: alanb, malenkov
! src/share/classes/java/io/File.java
-
Alan,
The fix to remove the timeout value looks okay to me. While you're
there, I wonder if the test passes on Windows with Cygwin and looks like
this test might have a similar bug:
6981005: TEST BUG: java/lang/ClassLoader/TestCrossDelegate.sh
timeout on windows
that the cygwin path
On 6/20/11 9:15 PM, Alan Bateman wrote:
There is another bug asking that the ClassLoader tests be updated to
work with cygwin:
7036526: TEST_BUG: add cygwin support to tests in
test/closed/java/lang/ClassLoader
I don't really have time at the moment to fix these tests and the only
reason
Hi Chris,
On 6/20/11 8:54 PM, Chris Hegarty wrote:
java/lang/Thread/ThreadStateTest.java can fail with when
checkThreadState finds an unexpected state.
Exception in thread main java.lang.RuntimeException: MyThread
expected to have TERMINATED but got RUNNABLE
at
On 6/21/11 7:12 PM, Chris Hegarty wrote:
[...]
I'm not sure the extra check in checkThreadState that the thread must
be RUNNABLE is valid. What if you are transitioning the thread from a
blocked to non-blocked state, you may still see it blocked on the
first call to getState.
L130-116: I
David,
Thanks for taking a closer look. Really appreciate your detailed review.
On 6/23/11 1:33 PM, David Holmes wrote:
Sorry for the delay on this ...
I concur with Mandy that using arrive() the thread must always be
RUNNABLE or the expected next state. Hence the new check is ok.
With the
Simple fix on these tests to run on cygwin.
7036518: TEST_BUG: add cygwin support to
test/java/nio/charset/coders/CheckSJISMappingProp.sh
7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh
Webrev at:
http://cr.openjdk.java.net/~mchung/7036518/webrev.00/
Thanks
Mandy
PM, Mandy Chung wrote:
Simple fix on these tests to run on cygwin.
7036518: TEST_BUG: add cygwin support to
test/java/nio/charset/coders/CheckSJISMappingProp.sh
7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh
Webrev at:
http://cr.openjdk.java.net/~mchung/7036518/webrev.00
Changeset: 0f1b4b3bc833
Author:mchung
Date: 2011-08-08 16:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f1b4b3bc833
7036518: TEST_BUG: add cygwin support to
test/java/nio/charset/coders/CheckSJISMappingProp.sh
7036519: TEST_BUG: add cygwin support to
Looks good.
Mandy
On 8/9/11 6:05 AM, Chris Hegarty wrote:
Hi,
This test creates temporary directories in the scratch area with
spaces in their names. It fails on Cygwin because jtreg cannot cleanup
after it. Easiest to just have the test cleanup (minimally) after itself.
Webrev:
On 08/11/11 12:07, Alexandre Boulgakov wrote:
Please review the attached patch to fix a build break.
The fix changes new Class[] to new Class?[] in two places.
The patch looks good to me.
Mandy
Thumbs up from me. Are you going to include this change with another
CR that you have a fix to be pushed?
Mandy
On 8/17/11 3:45 PM, Sebastian Sickelmann wrote:
Hi while searching if i created warnings with an change i have seen
that there are 2 warnings in rmic that are easy to remove.
On 8/17/11 9:46 PM, Sebastian Sickelmann wrote:
Are you going to include this change with another CR that you have a
fix to be pushed?
Is the CR to small, or what is the reason for your question?
I was just curious which CR this change is going into since it's not
mentioned in your email.
Looks okay.
Mandy
On 8/22/11 3:30 AM, Alan Bateman wrote:
It's whack-a-testmole time again and I'd like to update the
ProblemList to add several tests that fail for various reasons. In
some cases it's shell tests that need updating to work with Cygwin, in
other cases it's tests that make
to Mandy Chung and John Coomes for advice and for
earlier reviews; and to Mandy for additional testing help.
Thanks for any other reviews or comments.
-- ramki
Changeset: be949e12cab0
Author:mchung
Date: 2011-09-07 13:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be949e12cab0
7078024: Update JDK service tag for JDK 8
Reviewed-by: paulk
! make/com/sun/servicetag/Makefile
! src/share/classes/com/sun/servicetag/Installer.java
+
6915797: Remove sun.tools.jar.JarImageSource that is not used
7090178: Move java.util.XMLUtils to another package to avoid split package
Webrev at:
http://cr.openjdk.java.net/~mchung/6915797/webrev.00/
The synopsis says it all.
Thanks
Mandy
Changeset: ca2e2b85f437
Author:mchung
Date: 2011-09-13 16:37 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ca2e2b85f437
7090297: Remove com.sun.tools.javac.Launcher from tools.jar
Reviewed-by: jjg
- src/share/classes/com/sun/tools/javac/Launcher.java
Changeset: 04672e957da0
Author:mchung
Date: 2011-09-14 08:33 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04672e957da0
6915797: Remove sun.tools.jar.JarImageSource that is not used
7090178: Move java.util.XMLUtils to another package to avoid split package
Reviewed-by:
On 10/24/11 10:27 AM, Seán Coffey wrote:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7099658
Simple fix where loadFromXML method should call into the standard API
and use the getDocumentElement() call to obtain the properties Element.
http://cr.openjdk.java.net/~coffeys/webrev.7099658/
Gary,
Thanks for picking up this bug and fixing this intermittent issue.
PlatformLoggingMXBeanTest.java in the same directory has the same
issue. It'd be good to fix that with the same CR. These tests were
copied from test/java/util/logging/LoggingMXBeanTest.java. I haven't
looked in
On 11/9/2011 1:18 PM, Alan Bateman wrote:
On 09/11/2011 19:26, Gary Adams wrote:
Here's an updated diff :
- added current CR# to the @bug tag
- made logger1 and logger2 instance variables
- renamed test instance variable lmxbeantest
- removed excessive diagnostic print outs
Looks
On 11/15/11 10:20 AM, Gary Adams wrote:
Added PlatformLoggingMXBeanTest to the 7067691 bug fix,
e.g. instance variables for Logger variables to prevent premature
weak reference collection.
http://cr.openjdk.java.net/~gadams/7067691/
Gary,
I have pushed your changeset:
Changeset: 98502d7a3f98
Author:mchung
Date: 2011-12-02 16:29 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98502d7a3f98
7117585: Eliminate java.lang.instrument, java.lang.management warnings
Reviewed-by: mchung
Contributed-by: Jon VanAlten jon.vanal...@redhat.com
!
On 12/2/2011 5:57 AM, Frederic Parain wrote:
http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/
ManagementPermission.java
The diagnostic command is not part of the platform.
It doesn't seem right to add this new diagnosticCommand
ManagementPermission. Are the existing control
On 12/7/2011 2:04 PM, Mandy Chung wrote:
On 12/7/2011 1:30 PM, Frederic Parain wrote:
The execute method doesn't throw any exception other than
IAE. What happens if the specified command execution fails
in the target VM? If no exception is thrown, how does the
caller detect if the command
I18NJarTest.java
L29: Is -XDignore.symbol.file really needed? As far as I see,
the test only uses the public APIs.
L79: should it check if the returned value is false?
Otherwise, looks good.
Mandy
On 1/10/2012 1:06 PM, Kumar Srinivasan wrote:
sorry I pasted the wrong webrev
On 1/10/2012 1:44 PM, Kumar Srinivasan wrote:
I18NJarTest.java
L29: Is -XDignore.symbol.file really needed? As far as I see,
the test only uses the public APIs.
This is needed, since TestHelper uses javac and tar apis
behind the scenes.
Ah. I missed its reference to
Looks good.
Mandy
On 1/10/2012 5:20 PM, Joe Darcy wrote:
Hello,
Please review this simple fix to the javadoc of java.lang.Throwable;
use of and rather than lt; and gt; currently causes
malformed HTML to be generated.
--- a/src/share/classes/java/lang/Throwable.javaTue Jan 10
reviewed it and I think it looks OK. I tried looking at the code
in MacosxOperatingSystem.c relative to the Linux version, but I think
it is easily possible to miss something subtle here.
You might try a direct ping to Mandy Chung since MM was her area.
You might also try a direct ping to Mike
On 4/11/2012 12:36 AM, Deven You wrote:
Hi core-libs-devs,
I am not sure if sun.management.Agent belongs to jmx-dev mailing list,
if so please anyone tell me.
serviceability-dev (cc'ed) is the mailing list for this patch.
This issue is that the
On 04/23/2012 02:36 PM, David Holmes wrote:
Except of course that Properties is a Hashtable and synchronizes on
'this' for all public methods. So locking the properties object in the
client code will guarantee exclusive access to it.
David, thanks for looking at this closer. I missed that
Looks good to me.
Mandy
On 4/24/2012 8:24 AM, Kumar Srinivasan wrote:
Hi,
Could you please review this, actually the launcher is a 2 line change,
but when I was testing/experimenting with this, it was hard to inspect
the .jtr file for test failure, the test framework is cleanup to help the
7164376 Replace use of sun.security.action.LoadLibraryAction
with direct call of System.loadLibrary
Webrev:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7164376/webrev.00/
This change is required for jdk modularization. High level summary:
it replaces the use of LoadLibraryAction:
/classes/sun/management/FileSystemImpl.java
src/windows/classes/sun/management/FileSystemImpl.java
- line-break coding style is different from all others; probably
better to be consistent
--Sean
On 04/26/2012 02:49 PM, Mandy Chung wrote:
7164376 Replace use
to check all those are still the same.
-phil.
On 4/26/2012 2:20 PM, Mandy Chung wrote:
Thanks, Sean. I have fixed the 3 files per your comment.
Mandy
On 4/26/2012 1:59 PM, Sean Mullan wrote:
Looks fine, just a couple of nits.
src/macosx/classes/com/apple/concurrent/LibDispatchNative.java
Changeset: 46e0bd218fcc
Author:mchung
Date: 2012-05-01 19:45 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46e0bd218fcc
7164376: Replace use of sun.security.action.LoadLibraryAction with
System.loadLibrary
Reviewed-by: alanb, mullan, prr
!
PM, Mandy Chung wrote:
7164376 Replace use of sun.security.action.LoadLibraryAction
with direct call of System.loadLibrary
Webrev:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7164376/webrev.00/
This change is required for jdk modularization. High level summary:
it replaces the use
Looks good. It's a good clean up.
Mandy
On 6/7/2012 11:47 AM, Lance Andersen - Oracle wrote:
Hi all,
Another review request (to go with the others that are outstanding).
This is change is for jigsaw, where we are removing the native code used by
DriverManager. The webrev can be found at:
Changeset: fd563c5dd750
Author:mchung
Date: 2008-04-10 10:47 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd563c5dd750
6610094: Add generic support for platform MXBeans of any type (also fixed
6681031)
Summary: Add new methods in ManagementFactory class to obtain platform
Changeset: 18eed13fe9f6
Author:mchung
Date: 2008-04-11 10:26 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/18eed13fe9f6
6687508: Update test/sun/management jtreg tests due to
sun.management.ManagementFactory class rename
Summary: Modified the jtreg tests to use
Changeset: 87170fc5a587
Author:mchung
Date: 2008-12-05 10:28 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/87170fc5a587
6764062: Revise usage of java.io.*.close
Summary: Handle closing multiple open I/O streams in case close() throws
IOException
Reviewed-by: ksrini
!
Changeset: 1f751a9f7052
Author:mchung
Date: 2009-01-20 13:02 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f751a9f7052
6793429: Use compiled properties instead of plain properties for resource file
Summary: Rename the variables in Resources.gmk to make compiled properties
Changeset: de1d02ad2d1d
Author:mchung
Date: 2009-02-27 13:43 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de1d02ad2d1d
6799689: Make sun.misc.FloatingDecimal.hexFloatPattern static field initialized
lazily
Summary: Lazily initialize the hexFloatPattern static field
Changeset: 0da45c759116
Author:mchung
Date: 2009-02-27 16:34 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0da45c759116
6809504: Remove enctype=text/xml from the offline registration page
Summary: Remove enctype=text/xml from register.html and other localized
versions
6799230: Lazily load java.lang.annotation.Annotation class
Webrev at:
http://cr.openjdk.java.net/~mchung/6799230/webrev.00/
java.lang.annotation.Annotation class is always loaded when loading
java.lang.Class, java.lang.reflect.Constructor,
java.lang.reflect.Method, and
Changeset: 07d2550f5c84
Author:mchung
Date: 2009-03-03 19:26 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07d2550f5c84
6799230: Lazily load java.lang.annotation.Annotation class
Summary: Remove the static EMPTY_ANNOTATION_ARRAY field; add
AnnotationParser.toArray method
Thanks Alan. This is a good approach that avoids using reflection and
addresses David's concern. I was a bit aggressive to lazily instantiate
Java*Access objects as many as I can. I'll revise the fix and send out
a new webrev.
Thanks
Mandy
Alan Bateman wrote:
Mandy Chung wrote:
6810254
Changeset: 392cd358db5d
Author:mchung
Date: 2009-03-18 17:37 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/392cd358db5d
6817246: Redundant call to set InetAddressCachePolicy to FOREVER if not set
during initialization
Summary: Remove InetAddressCachePolicy.setIfNotSet call
throws IllegalStateException since the files
field is never null as it is initialized in the static initializer.
I'll fix this bug.
Mandy
Alan Bateman wrote:
Mandy Chung wrote:
Hi Martin,
Thanks for catching the regression. I created a Sun bug # 6829503
for bug 2.
With the fix for 6829503
6829503: addShutdownHook fails if called after shutdown has commenced.
Webrev at:
http://cr.openjdk.java.net/~mchung/6829503/webrev.00/
I change the Shutdown#add method to take the registerShutdownInProgress
parameter. If set to true, the specified shutdown hook is allowed to be
registered
a research problem.
-
the last shutdown hook to invoke.
=
the last shutdown hook to be invoked.
Martin
On Fri, Apr 17, 2009 at 15:05, Mandy Chung mandy.ch...@sun.com wrote:
6829503: addShutdownHook fails if called after shutdown has commenced.
Webrev at:
http://cr.openjdk.java.net/~mchung
).
David
Mandy Chung said the following on 04/18/09 08:05:
6829503: addShutdownHook fails if called after shutdown has commenced.
Webrev at:
http://cr.openjdk.java.net/~mchung/6829503/webrev.00/
I change the Shutdown#add method to take the
registerShutdownInProgress parameter. If set to true
Alan,
Thanks for the review and comments. Here is the revised webrev
incorporating your comments. See below for my inlined reply.
http://cr.openjdk.java.net/~mchung/6829503/webrev.01/
Alan Bateman wrote:
Good work! It mostly looks good to me and I've only a few comments:
1. I see that
Thanks Alan.
Mandy
Alan Bateman wrote:
Mandy Chung wrote:
Alan,
Thanks for the review and comments. Here is the revised webrev
incorporating your comments. See below for my inlined reply.
http://cr.openjdk.java.net/~mchung/6829503/webrev.01/
Alan Bateman wrote:
Good work! It mostly
Changeset: 164ce9ff8b58
Author:mchung
Date: 2009-04-27 12:08 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/164ce9ff8b58
6829503: addShutdownHook fails if called after shutdown has commenced.
Summary: allow shutdown hook to be added during shutdown and handle properly if
it
Changeset: 7772d77bd7c2
Author:mchung
Date: 2009-05-26 17:47 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7772d77bd7c2
6829636: test/java/util/logging/LoggingDeadlock2.java is flaky
Summary: remove @ignore
Reviewed-by: swamyv
!
Alan,
Looks good. Thanks for making the change. I'll fix java.util.logging
to eliminate such dependency.
Mandy
Alan Bateman wrote:
Mandy - you do mind reviewing this change to eliminate the dependency
in java.nio on javax.management.ObjectName that we've chatted about.
The changes move
Alan Bateman wrote:
Mandy,
I see in ClassLoader#loadClass that you still allow
findBootstrapClassOrNull to throw CNF. I assume this is needed until
there is a promoted build with the updated
JVM_FindClassFromBootLoader, after which you will go back to clean it
up - do I have this right?
I
This is related to 6857194: Add hotspot new perf counters to aid class
loading performance measurement.
It's useful to add performance counters in the library code so that perf
data from the JDK and VM can be collected and output in a unified way
(written in the jvmstat shared memory buffer).
Alan Bateman wrote:
Andrew John Hughes wrote:
:
The use of synchronized at present seems flawed as only the set
methods are protected and not the get. So lb.get could be called
while in an lb.put call. I don't see the reason for using a
LongBuffer either, as only index 0 is ever used. Why
Alan Bateman wrote:
Mandy Chung wrote:
This is related to 6857194: Add hotspot new perf counters to aid
class loading performance measurement.
It's useful to add performance counters in the library code so that
perf data from the JDK and VM can be collected and output in a
unified way
David Holmes - Sun Microsystems wrote:
Hi Mandy,
Mandy Chung said the following on 09/03/09 05:25:
This is related to 6857194: Add hotspot new perf counters to aid
class loading performance measurement.
It's useful to add performance counters in the library code so that
perf data from
Changeset: fdf11ce72e8e
Author:mchung
Date: 2009-08-06 11:25 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fdf11ce72e8e
4917309: (cl) Reduce internal usage of ClassNotFoundExceptions during
class-loading
Summary: Change findBootstrapClass to return null instead of throwing
. In either case,
more
samples would be needed to detect an actual difference in sample
means.
Thanks
Mandy
Mandy Chung wrote:
This is related to 6857194: Add hotspot new perf counters to aid class
loading performance measurement.
It's useful to add performance counters in the library code so
Alan, David,
Thanks for the review. Comments inlined below.
Alan Bateman wrote:
Minor nit but I assume you can initialize perf as:
private static final Perf perf =
AccessController.doPrivileged(new Perf.GetPerfAction());
Fixed.
David Holmes wrote:
Just to add 2c to Alan's method
Oleg Sukhodolsky wrote:
On Mon, Sep 14, 2009 at 5:32 AM, Mandy Chung mandy.ch...@sun.com wrote:
6879044: Eliminate the dependency of logging from the JRE core/awt/swing
classes
Webrev:
http://cr.openjdk.java.net/~mchung/6879044/webrev.00/
Summary:
1. A new sun.util.logging.PlatformLogger
you confirm?
At the very least consider using the lazy holder idiom over volatile.
Good point.
Mandy
Andrew John Hughes wrote:
2009/9/14 Mandy Chung mandy.ch...@sun.com:
I'm curious as to why some of the initialisations are lazy and some
are eager. Notably AWTEvent is changed from eager to lazy
Oleg Sukhodolsky wrote:
On Mon, Sep 14, 2009 at 9:19 PM, Mandy Chung mandy.ch...@sun.com wrote:
I thought that it is possible to log int a file using default logger,
Not the default logging configuration.
thus I was surprised that
description of PlatformLogger says about System.err. I'd
Oleg, Anthony,
You all raise good questions and we shall focus on the problem we want
to fix by 6879044 and 6882376. It's important to separate the
discussion for this fix vs the startup performance improvement. I hope
below clears up some confusion and this review request is for
Hi Oleg,
A better question to ask is who and how the logging information AWT is
used for. The AWT team confirms that the AWT loggers are for debugging
purpose used by the awt developers. As specified in the Requirements
chapter for the Java Logging Spec (JSR-47) [1], the central goal of
Changeset: d3281fa8e46c
Author:mchung
Date: 2009-09-17 14:24 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3281fa8e46c
6882376: Add internal support for JRE implementation to eliminate the
dependency on logging
Summary: Added sun.util.logging.PlatformLogger for JRE
Hi Rob,
Rob Leland wrote:
..Mandy,
Three questions.
-import java.util.logging.Logger;
+import sun.util.logging.PlatformLogger;
It seems counter intuitive that a dependency would be change
from a java.* - sun.* since this the OpenJDK ,why not add it to
java.util.log.* ?
Alan answered this
Alan, Karen,
Can you review the fix for:
6612680: Remove classloader dependency on jkernel
Webrev at:
http://cr.openjdk.java.net/~mchung/6612680/
java.lang.ClassLoader and sun.misc.Launcher have explicit dependencies
on the jkernel code. While the performance impact of this is minimal
Alan, Rémi,
Thanks for the review. The revised webrev is at:
http://cr.openjdk.java.net/~mchung/6612680/jdk-webrev.01/
http://cr.openjdk.java.net/~mchung/6612680/hotspot-webrev.01/
Alan Bateman wrote:
Good to see this dependency going away. A couple of comments:
- In thread.cpp, do you
Changeset: 1b81fc851b20
Author:mchung
Date: 2009-10-06 15:14 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1b81fc851b20
602: sun.misc.BootClassLoaderHook.getBootstrapPaths stack overflow
Summary: Fixed sun.misc.BootClassLoaderHook.getBootstrapPaths calls
Alan, Sean,
Can you review the fix for:
6891707: Eliminate the java.io.FilePermission dependency on PolicyFile
Webrev:
http://cr.openjdk.java.net/~mchung/6891707/webrev.00/
FilePermission and PolicyFile are the two callers to the
sun.security.provider.PolicyFile.canonPath method. Adding a
Changeset: 16b33372af1c
Author:mchung
Date: 2009-10-14 20:16 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16b33372af1c
6891701: test/java/lang/management/RuntimeMXBean/GetSystemProperties should
restore the system property
Summary: Restore the system properties when the
Changeset: 16e4bbb7488d
Author:mchung
Date: 2009-10-15 17:36 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16e4bbb7488d
6891707: Eliminate the java.io.FilePermission dependency on PolicyFile
Summary: Replace call to PolicyFile.canonPath with its own implementation
Fixed 6895456: Eliminate dependency on java.io.ObjectStreamClass during boot
Webrev at:
http://cr.openjdk.java.net/~mchung/6895456/webrev.00/
java.io.ObjectStreamClass is not needed if not doing serialization.
Move getSignatureClass static method to java.io.ObjectStreamField
class.
Alan Bateman wrote:
I agree it would be good to avoid loading/initializing
ObjectStreamClass (as you say, we have to load ObjectStreamField as
the serialPersistentFields is part of Class, String, and other APIs).
My only concern is that ObjectStreamField doesn't seem to be the
right place
Duplicating this method may be a better option for this case (that I
typically try to avoid). I can make this change.
The new webrev at:
http://cr.openjdk.java.net/~mchung/6895456/webrev.01/
Mandy
Sherman,
I modified src/windows/classes/java/util/prefs/WindowsPreferences.java
to use sun.util.logging.PlatformLogger in the fix for 6882376 but missed
src/solaris/classes/java/util/prefs/FileSystemPreferences.java.
This fix is to update java.util.prefs.FileSystemPreferences to use
601 - 700 of 3165 matches
Mail list logo
