From yuri.nesterenko at sun.com  Fri Sep  4 04:01:30 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Fri, 04 Sep 2009 11:01:30 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6871299: Shift+Tab no longer generates
	a KEY_TYPED	event; used to with JRE 1.5
Message-ID: <20090904110226.2769012C0E@hg.openjdk.java.net>

Changeset: d755ace580b2
Author:    yan
Date:      2009-09-04 14:50 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/d755ace580b2

6871299: Shift+Tab no longer generates a KEY_TYPED event; used to with JRE 1.5
Summary: Add XK_ISO_Left_Tab -> VK_TAB rule
Reviewed-by: dcherepanov

! src/solaris/classes/sun/awt/X11/XKeysym.java
! src/solaris/classes/sun/awt/X11/keysym2ucs.h


From mjw at redhat.com  Fri Sep 11 00:01:04 2009
From: mjw at redhat.com (Mark Wielaard)
Date: Fri, 11 Sep 2009 09:01:04 +0200
Subject: <AWT Dev> [OpenJDK 2D-Dev] Request to backport fix for 6708392
 to openjdk6
In-Reply-To: <1ccfd1c10909101801j7e98f82fv1dfc6899a057d7b9@mail.gmail.com>
References: <1ccfd1c10909101801j7e98f82fv1dfc6899a057d7b9@mail.gmail.com>
Message-ID: <1252652464.17906.61.camel@springer.wildebeest.org>

On Thu, 2009-09-10 at 18:01 -0700, Martin Buchholz wrote:
> Hi SunToolkit.setOverrideRedirect team,

Hi Martin,

> Google engineers have found that
> 6708392: Provide internal API to create OverrideRedirect windows, XToolkit
> is a showstopper bug,
> (for folks using NX on Windows or Mac)
> and that the fix in openjdk7 fixes it,
> when trivially backported to openjdk6.
> 
> Many thanks to Brian Duff for the hard work of
> testing and debugging.
> 
> I'd like to commit this fix to openjdk6.
> 
> Webrev:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/SunToolkit.setOverrideRedirect/

This is a rewrite of a similar fix I made:
http://mail.openjdk.java.net/pipermail/awt-dev/2008-May/000248.html
It fixes some issues with MetaCity and solves some TCK failures.

It has been in IcedTea for a long time.
http://icedtea.classpath.org/hg/icedtea6/file/tip/patches/icedtea-override-redirect-metacity.patch

The difference with the IcedTea patch rewrite is discussed here:
http://mail.openjdk.java.net/pipermail/awt-dev/2008-August/000309.html

Cheers,

Mark


From gnu_andrew at member.fsf.org  Fri Sep 11 06:50:28 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 11 Sep 2009 14:50:28 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] Request to backport fix for 6708392
	to openjdk6
In-Reply-To: <1252652464.17906.61.camel@springer.wildebeest.org>
References: <1ccfd1c10909101801j7e98f82fv1dfc6899a057d7b9@mail.gmail.com>
	<1252652464.17906.61.camel@springer.wildebeest.org>
Message-ID: <17c6771e0909110650x3db5f013sa3c33aca716e7d17@mail.gmail.com>

2009/9/11 Mark Wielaard <mjw at redhat.com>:
> On Thu, 2009-09-10 at 18:01 -0700, Martin Buchholz wrote:
>> Hi SunToolkit.setOverrideRedirect team,
>
> Hi Martin,
>
>> Google engineers have found that
>> 6708392: Provide internal API to create OverrideRedirect windows, XToolkit
>> is a showstopper bug,
>> (for folks using NX on Windows or Mac)
>> and that the fix in openjdk7 fixes it,
>> when trivially backported to openjdk6.
>>
>> Many thanks to Brian Duff for the hard work of
>> testing and debugging.
>>
>> I'd like to commit this fix to openjdk6.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/SunToolkit.setOverrideRedirect/
>
> This is a rewrite of a similar fix I made:
> http://mail.openjdk.java.net/pipermail/awt-dev/2008-May/000248.html
> It fixes some issues with MetaCity and solves some TCK failures.
>
> It has been in IcedTea for a long time.
> http://icedtea.classpath.org/hg/icedtea6/file/tip/patches/icedtea-override-redirect-metacity.patch
>
> The difference with the IcedTea patch rewrite is discussed here:
> http://mail.openjdk.java.net/pipermail/awt-dev/2008-August/000309.html
>
> Cheers,
>
> Mark
>
>

We're also still carrying the patch in IcedTea7 despite it presumably
now being made redundant by this other patch.  I guess I missed the
discussion Mark referenced, presumably because I wasn't subscribed to
awt-dev back then.

Martin, thanks for bringing this up and please commit the patch to jdk6.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From martinrb at google.com  Sat Sep 12 16:44:20 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 12 Sep 2009 16:44:20 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] Request to backport fix for 6708392
	to openjdk6
In-Reply-To: <17c6771e0909110650x3db5f013sa3c33aca716e7d17@mail.gmail.com>
References: <1ccfd1c10909101801j7e98f82fv1dfc6899a057d7b9@mail.gmail.com>
	<1252652464.17906.61.camel@springer.wildebeest.org>
	<17c6771e0909110650x3db5f013sa3c33aca716e7d17@mail.gmail.com>
Message-ID: <1ccfd1c10909121644l2fc4f3f0m673457e162c307c3@mail.gmail.com>

[Trying to correct the email addresses of original patch authors/reviewers]

The consensus seems to be that the fix for
6708392: Provide internal API to create OverrideRedirect windows, XToolkit
belongs in openjdk6 and that it supersedes a similar patch that is now
in icedtea.

I am committing it to openjdk6 now.

Presumably icedtea maintainers will do likewise.

Martin

On Fri, Sep 11, 2009 at 06:50, Andrew John
Hughes<gnu_andrew at member.fsf.org> wrote:
> 2009/9/11 Mark Wielaard <mjw at redhat.com>:
>> On Thu, 2009-09-10 at 18:01 -0700, Martin Buchholz wrote:
>>> Hi SunToolkit.setOverrideRedirect team,
>>
>> Hi Martin,
>>
>>> Google engineers have found that
>>> 6708392: Provide internal API to create OverrideRedirect windows, XToolkit
>>> is a showstopper bug,
>>> (for folks using NX on Windows or Mac)
>>> and that the fix in openjdk7 fixes it,
>>> when trivially backported to openjdk6.
>>>
>>> Many thanks to Brian Duff for the hard work of
>>> testing and debugging.
>>>
>>> I'd like to commit this fix to openjdk6.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/SunToolkit.setOverrideRedirect/
>>
>> This is a rewrite of a similar fix I made:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2008-May/000248.html
>> It fixes some issues with MetaCity and solves some TCK failures.
>>
>> It has been in IcedTea for a long time.
>> http://icedtea.classpath.org/hg/icedtea6/file/tip/patches/icedtea-override-redirect-metacity.patch
>>
>> The difference with the IcedTea patch rewrite is discussed here:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2008-August/000309.html
>>
>> Cheers,
>>
>> Mark
>>
>>
>
> We're also still carrying the patch in IcedTea7 despite it presumably
> now being made redundant by this other patch. ?I guess I missed the
> discussion Mark referenced, presumably because I wasn't subscribed to
> awt-dev back then.
>
> Martin, thanks for bringing this up and please commit the patch to jdk6.
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8
>

From gnu_andrew at member.fsf.org  Sat Sep 12 16:46:16 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 13 Sep 2009 00:46:16 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] Request to backport fix for 6708392
	to openjdk6
In-Reply-To: <1ccfd1c10909121644l2fc4f3f0m673457e162c307c3@mail.gmail.com>
References: <1ccfd1c10909101801j7e98f82fv1dfc6899a057d7b9@mail.gmail.com>
	<1252652464.17906.61.camel@springer.wildebeest.org>
	<17c6771e0909110650x3db5f013sa3c33aca716e7d17@mail.gmail.com>
	<1ccfd1c10909121644l2fc4f3f0m673457e162c307c3@mail.gmail.com>
Message-ID: <17c6771e0909121646i18411d55l38d19e58b00f004a@mail.gmail.com>

2009/9/13 Martin Buchholz <martinrb at google.com>:
> [Trying to correct the email addresses of original patch authors/reviewers]
>
> The consensus seems to be that the fix for
> 6708392: Provide internal API to create OverrideRedirect windows, XToolkit
> belongs in openjdk6 and that it supersedes a similar patch that is now
> in icedtea.
>
> I am committing it to openjdk6 now.
>
> Presumably icedtea maintainers will do likewise.
>

IcedTea doesn't include a copy of OpenJDK.  We just no longer apply
our patch when this changeset becomes available in a build drop (which
should be soon if you do it now - b17).

> Martin
>
> On Fri, Sep 11, 2009 at 06:50, Andrew John
> Hughes<gnu_andrew at member.fsf.org> wrote:
>> 2009/9/11 Mark Wielaard <mjw at redhat.com>:
>>> On Thu, 2009-09-10 at 18:01 -0700, Martin Buchholz wrote:
>>>> Hi SunToolkit.setOverrideRedirect team,
>>>
>>> Hi Martin,
>>>
>>>> Google engineers have found that
>>>> 6708392: Provide internal API to create OverrideRedirect windows, XToolkit
>>>> is a showstopper bug,
>>>> (for folks using NX on Windows or Mac)
>>>> and that the fix in openjdk7 fixes it,
>>>> when trivially backported to openjdk6.
>>>>
>>>> Many thanks to Brian Duff for the hard work of
>>>> testing and debugging.
>>>>
>>>> I'd like to commit this fix to openjdk6.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/SunToolkit.setOverrideRedirect/
>>>
>>> This is a rewrite of a similar fix I made:
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2008-May/000248.html
>>> It fixes some issues with MetaCity and solves some TCK failures.
>>>
>>> It has been in IcedTea for a long time.
>>> http://icedtea.classpath.org/hg/icedtea6/file/tip/patches/icedtea-override-redirect-metacity.patch
>>>
>>> The difference with the IcedTea patch rewrite is discussed here:
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2008-August/000309.html
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>>
>>
>> We're also still carrying the patch in IcedTea7 despite it presumably
>> now being made redundant by this other patch. ?I guess I missed the
>> discussion Mark referenced, presumably because I wasn't subscribed to
>> awt-dev back then.
>>
>> Martin, thanks for bringing this up and please commit the patch to jdk6.
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8
>>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From Mandy.Chung at Sun.COM  Sun Sep 13 18:32:29 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Sun, 13 Sep 2009 18:32:29 -0700
Subject: <AWT Dev> Review Request for 6879044
Message-ID: <4AAD9D2D.6000502@sun.com>

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 class that will handle the log messages in a similar way as Logger but it will only delegate to java.util.logging only when it is enabled.  LogManager and LogRecord are modified to support the platform loggers.  The users of PlatformLogger will continue to run if java.util.logging classes do not exist.

2. AWT, 2D, Swing, and a few java.util classes are modified to use PlatformLogger instead of Logger.  Although many files are modified, the change is mostly replacement with classname.

AWT statically creates a number of loggers. Running a simple AWT Framer application with JDK 7 b71 creates 79 loggers on solaris-i586 and 34 loggers on windows-i586. SwingSet2 creates a total of 85 loggers including a few non-awt ones on solaris-i586 and 35 on windows-i586). 

Although the memory usage might not be very high (especially with this fix), I don't see the need of having many fine-grained loggers.  This fix doesn't address this the number of AWT loggers. I file a separate CR (6880089) to revisit it.

Startup Performance:
This change does not have significant startup performance improvement, as expected.  However, it does reduce the number of loaded classes (Framer app loads 16 fewer classes and jedit loads 13 fewer classes).


Thanks
Mandy



From son.two at gmail.com  Sun Sep 13 20:44:27 2009
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Mon, 14 Sep 2009 07:44:27 +0400
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AAD9D2D.6000502@sun.com>
References: <4AAD9D2D.6000502@sun.com>
Message-ID: <271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>

On Mon, Sep 14, 2009 at 5:32 AM, Mandy Chung <Mandy.Chung at 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 class that will handle the log
> messages in a similar way as Logger but it will only delegate to
> java.util.logging only when it is enabled. ?LogManager and LogRecord are
> modified to support the platform loggers. ?The users of PlatformLogger will
> continue to run if java.util.logging classes do not exist.

evaluation for 6879044 says:

Add a PlatformLogger class that mimics the default logging behavior
(output the log message to System.err with simple formatting) and
creates a java.util.logging.Logger only when the logging facility is
used by the application or a user-defined configuration is supplied.

which of two descriptions is correct one?

Also I wonder if it is ok to get possible better modularization by
adding dependency to Sun's internal API into public packages.

> 2. AWT, 2D, Swing, and a few java.util classes are modified to use
> PlatformLogger instead of Logger. ?Although many files are modified, the
> change is mostly replacement with classname.

Well, at least in AWTEvent you have changed static initialization of
logger to lazy one.
Perhaps it is better to keep a static one to minimize your changes.

Oleg.
>
> AWT statically creates a number of loggers. Running a simple AWT Framer
> application with JDK 7 b71 creates 79 loggers on solaris-i586 and 34 loggers
> on windows-i586. SwingSet2 creates a total of 85 loggers including a few
> non-awt ones on solaris-i586 and 35 on windows-i586).
> Although the memory usage might not be very high (especially with this fix),
> I don't see the need of having many fine-grained loggers. ?This fix doesn't
> address this the number of AWT loggers. I file a separate CR (6880089) to
> revisit it.
>
> Startup Performance:
> This change does not have significant startup performance improvement, as
> expected. ?However, it does reduce the number of loaded classes (Framer app
> loads 16 fewer classes and jedit loads 13 fewer classes).
>
>
> Thanks
> Mandy
>
>
>

From Alan.Bateman at Sun.COM  Mon Sep 14 02:17:07 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Mon, 14 Sep 2009 10:17:07 +0100
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AAD9D2D.6000502@sun.com>
References: <4AAD9D2D.6000502@sun.com>
Message-ID: <4AAE0A13.3080709@sun.com>

Mandy Chung wrote:
> 6879044: Eliminate the dependency of logging from the JRE 
> core/awt/swing classes
>
> Webrev:
>   http://cr.openjdk.java.net/~mchung/6879044/webrev.00/
The approach seems reasonable to me. It is a bit strange to redirect the 
platform logging to j.u.logging if something up the stack starts logging 
but I think we can live with this because these loggers are for 
debugging purposes.

The changes to the AWT code are mostly mechanical, so I've only skimmed 
these (assuming that someone from the AWT team with do a detailed check).

Have you tested this with a security manager set? I'm just wondering if 
PlatformLogger's static initializer should do the property lookup in a 
doPrivileged block. Also in the LoggerProxy for the line separator (BTW: 
lineSeparator can be final).

Is isLoggingEnabled() used anywhere? I can't see it and wonder if it 
should be removed. If it is used, then I assume it needs to be 
synchronized with redirectPlatformLoggers.

You allow the PlatformLoggers to be GC'ed but the entries will remain in 
the loggers map. I don't think this is a big deal because the AWT 
classes will not be unloaded but might be worth putting a note in a 
comment to re-visit this some time.

The static initializer in the forwarding proxy seems a bit messy. It 
might look neater if changed to something like:
    private static final Class<?> loggerClass = 
getClass("java.lang.Logger");                       
    private static final Method getLoggerMethod = getMethod(loggerClass, 
"getLogger", String.class);
where getClass does the Class.forName, returning null if CNF, getMethod 
returns null if passed a null class, etc.

Minor nit but there are a few style/formatting issues in PlatformLogger. 
For example, in JavaLogger there isn't a blank line between methods. It 
might be worthing taking a pass over this to have it as neat as possible.

Do you have a bugID to track updating the http protocol handler? Jessie 
did push some changes to eliminate the static dependency on logging and 
it would be good if that code used PlatformLogger.

-Alan.

From Artem.Ananiev at Sun.COM  Mon Sep 14 03:08:55 2009
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Mon, 14 Sep 2009 14:08:55 +0400
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AAD9D2D.6000502@sun.com>
References: <4AAD9D2D.6000502@sun.com>
Message-ID: <4AAE1637.70005@sun.com>


Mandy Chung 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 class that will handle the log 
> messages in a similar way as Logger but it will only delegate to 
> java.util.logging only when it is enabled.  LogManager and LogRecord are 
> modified to support the platform loggers.  The users of PlatformLogger 
> will continue to run if java.util.logging classes do not exist.
> 
> 2. AWT, 2D, Swing, and a few java.util classes are modified to use 
> PlatformLogger instead of Logger.  Although many files are modified, the 
> change is mostly replacement with classname.

I have quickly looked through AWT/2D changes and haven't found anything 
suspicious. A funny typo is noticed in X11 key logging (see XToolkit or 
XWindow for examples): logger name is sun.awt.X11.kye instead of 
sun.awt.X11.key - but anyway it's not your fault :)

> AWT statically creates a number of loggers. Running a simple AWT Framer 
> application with JDK 7 b71 creates 79 loggers on solaris-i586 and 34 
> loggers on windows-i586. SwingSet2 creates a total of 85 loggers 
> including a few non-awt ones on solaris-i586 and 35 on windows-i586).
> Although the memory usage might not be very high (especially with this 
> fix), I don't see the need of having many fine-grained loggers.  This 
> fix doesn't address this the number of AWT loggers. I file a separate CR 
> (6880089) to revisit it.

Thanks.

> Startup Performance:
> This change does not have significant startup performance improvement, 
> as expected.  However, it does reduce the number of loaded classes 
> (Framer app loads 16 fewer classes and jedit loads 13 fewer classes).
> 
> 
> Thanks
> Mandy

Thanks,

Artem

From Yuri.Nesterenko at Sun.COM  Mon Sep 14 03:22:09 2009
From: Yuri.Nesterenko at Sun.COM (Yuri Nesterenko)
Date: Mon, 14 Sep 2009 14:22:09 +0400
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AAE1637.70005@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AAE1637.70005@sun.com>
Message-ID: <4AAE1951.6040907@sun.com>

Artem Ananiev wrote:
> 
> Mandy Chung wrote:
>> 6879044: Eliminate the dependency of logging from the JRE 
>> core/awt/swing classes
>
...

> I have quickly looked through AWT/2D changes and haven't found anything 
> suspicious. A funny typo is noticed in X11 key logging (see XToolkit or 
> XWindow for examples): logger name is sun.awt.X11.kye instead of 
> sun.awt.X11.key - but anyway it's not your fault :)

It's not a typo, it's a decision!!! I forgot why I did it though but
there was a good reason.
...Oh, there it is: it's extremely easy to find
in the code full of everything "key".

-yan

From Anthony.Petrov at Sun.COM  Mon Sep 14 04:37:43 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Mon, 14 Sep 2009 15:37:43 +0400
Subject: <AWT Dev> sun.awt.disableMixing
In-Reply-To: <4f9903f0908311002o1c1efc5dr3b7b9eef9bda8fdc@mail.gmail.com>
References: <4f9903f0908311002o1c1efc5dr3b7b9eef9bda8fdc@mail.gmail.com>
Message-ID: <4AAE2B07.9000409@sun.com>

Hi Chris,

Unfortunately, the only way to make the property have an effect is to 
set it before running any GUI-related code. That's because the value of 
the property is being cached (see 
sun.awt.SunToolkit.getSunAwtDisableMixing()).

This is made intentionally because the mixing-related code frequently 
calls the Component.isMixingNeeded() method that in turn calls the 
SunToolkit's one. Re-reading the property each time would introduce a 
significant performance degradation.

--
best regards,
Anthony

On 8/31/2009 9:02 PM Christopher Deckers wrote:
> I have an issue with the "sun.awt.disableMixing" property: when my
> code is reached, I have no way to tell whether setting it to true
> would have an effect.
> 
> I have such a code:
>     if(System.getProperty("sun.awt.disableMixing") == null) {
>       System.setProperty("sun.awt.disableMixing", "true");
>     }
> but the problem is that if some Swing UI was already loaded, then
> setting this property would note have any effect (that my code assumes
> it worked...). I had this problem with WebStart for example, or some
> other cases where some user UI was loaded before setting it. Would it
> be possible that sun.awt.disableMixing be set when the Swing code
> caches the value?
> 
> Better would be that setting the value would actually have an effect
> instead of being ignored, but I doubt this is possible :)

From chrriis at gmail.com  Mon Sep 14 04:53:09 2009
From: chrriis at gmail.com (Christopher Deckers)
Date: Mon, 14 Sep 2009 13:53:09 +0200
Subject: <AWT Dev> sun.awt.disableMixing
In-Reply-To: <4AAE2B07.9000409@sun.com>
References: <4f9903f0908311002o1c1efc5dr3b7b9eef9bda8fdc@mail.gmail.com>
	<4AAE2B07.9000409@sun.com>
Message-ID: <4f9903f0909140453r59f60fcj6828c028cdfe68d3@mail.gmail.com>

Hi Anthony,

> Unfortunately, the only way to make the property have an effect is to set it
> before running any GUI-related code. That's because the value of the
> property is being cached (see sun.awt.SunToolkit.getSunAwtDisableMixing()).

I understand that it is cached. But conceptually, I don't see why
there would be a problem of updating that cached value (propagating
the change) rather than imposing users to add this property to the
JNLP.

At least, would it be possible that the system property be set to
"true" or "false" once the value was decided and cached rather than
staying null? That way, I would know that the property caching
happened and take appropriate action (continue, or message to the user
about setting that property, etc.)

I can understand that eventually the whole issue would vanish when
HW/LW mixing works properly (revalidation et al), but there does not
seem to be much activity on that front at the moment.

Cheers,
-Christopher

From Anthony.Petrov at Sun.COM  Mon Sep 14 05:31:19 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Mon, 14 Sep 2009 16:31:19 +0400
Subject: <AWT Dev> sun.awt.disableMixing
In-Reply-To: <4f9903f0909140453r59f60fcj6828c028cdfe68d3@mail.gmail.com>
References: <4f9903f0908311002o1c1efc5dr3b7b9eef9bda8fdc@mail.gmail.com>
	<4AAE2B07.9000409@sun.com>
	<4f9903f0909140453r59f60fcj6828c028cdfe68d3@mail.gmail.com>
Message-ID: <4AAE3797.5010406@sun.com>

On 9/14/2009 3:53 PM Christopher Deckers wrote:
> I understand that it is cached. But conceptually, I don't see why
> there would be a problem of updating that cached value (propagating
> the change) rather than imposing users to add this property to the
> JNLP.
> 
> At least, would it be possible that the system property be set to
> "true" or "false" once the value was decided and cached rather than
> staying null? That way, I would know that the property caching
> happened and take appropriate action (continue, or message to the user
> about setting that property, etc.)

I doubt if either is possible technically: the System.get/setProperty() 
API does not (and should not) know anything about AWT and its 
properties. Therefore, unless the property is explicitly set, the getter 
returns null according to its specification. On the other hand, the 
setter doesn't know where this exact property is cached, and we do not 
get notified when someone sets a property, and hence are unable to 
update the cached value.


> I can understand that eventually the whole issue would vanish when
> HW/LW mixing works properly (revalidation et al), but there does not
> seem to be much activity on that front at the moment.

I guess only patience might help us. The 6u16 is probably going to be 
able to work with the property correctly. And currently we don't have an 
intention of introducing new APIs that might become unnecessary one day 
(which is why, btw, the property is at sun.awt., not at java.awt.)

--
best regards,
Anthony

From chrriis at gmail.com  Mon Sep 14 07:12:51 2009
From: chrriis at gmail.com (Christopher Deckers)
Date: Mon, 14 Sep 2009 16:12:51 +0200
Subject: <AWT Dev> sun.awt.disableMixing
In-Reply-To: <4AAE3797.5010406@sun.com>
References: <4f9903f0908311002o1c1efc5dr3b7b9eef9bda8fdc@mail.gmail.com>
	<4AAE2B07.9000409@sun.com>
	<4f9903f0909140453r59f60fcj6828c028cdfe68d3@mail.gmail.com>
	<4AAE3797.5010406@sun.com>
Message-ID: <4f9903f0909140712x1aeb0bbbo1d70e93eb44a3db9@mail.gmail.com>

> I doubt if either is possible technically: the System.get/setProperty() API
> does not (and should not) know anything about AWT and its properties.

Yes, but when AWT reads that property (to eventually cache it), finds
that it is null and decides to enabled HW/LW mixing, it could set the
property to true. Or am I missing anything?

-Christopher

From Mandy.Chung at Sun.COM  Mon Sep 14 10:19:14 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Mon, 14 Sep 2009 10:19:14 -0700
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
Message-ID: <4AAE7B12.5000403@Sun.com>

Oleg Sukhodolsky wrote:
> On Mon, Sep 14, 2009 at 5:32 AM, Mandy Chung <Mandy.Chung at 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 class that will handle the log
>> messages in a similar way as Logger but it will only delegate to
>> java.util.logging only when it is enabled.  LogManager and LogRecord are
>> modified to support the platform loggers.  The users of PlatformLogger will
>> continue to run if java.util.logging classes do not exist.
> 
> evaluation for 6879044 says:
> 
> Add a PlatformLogger class that mimics the default logging behavior
> (output the log message to System.err with simple formatting) and
> creates a java.util.logging.Logger only when the logging facility is
> used by the application or a user-defined configuration is supplied.
> 
> which of two descriptions is correct one?

Both are correct.  Can you elaborate what issue;/confusion you see 
between the descriptions?

The class description of sun.util.logging.PlatformLogger has the details:
http://cr.openjdk.java.net/~mchung/6879044/webrev.00/src/share/classes/sun/util/logging/PlatformLogger.java.html

> Also I wonder if it is ok to get possible better modularization by
> adding dependency to Sun's internal API into public packages.

This fix is to eliminate the dependency to logging API.   This internal 
PlatformLogger class is an implementation class only used by the JRE and 
always be present.  Does this answer your question?

>> 2. AWT, 2D, Swing, and a few java.util classes are modified to use
>> PlatformLogger instead of Logger.  Although many files are modified, the
>> change is mostly replacement with classname.
> 
> Well, at least in AWTEvent you have changed static initialization of
> logger to lazy one.
> Perhaps it is better to keep a static one to minimize your changes.

This fix shows one way of lazy initializing an AWT logger to be 
referenced when fixing 6880089.  The AWTEvent log messages are only 
output in the error conditions.  In the normal cases, no message will be 
logged in this logger is not needed.   I would expect that the fix for 
6880089 may make some AWT loggers to be initialized lazily as this one.

Thanks for the review.
Mandy

> Oleg.
>> AWT statically creates a number of loggers. Running a simple AWT Framer
>> application with JDK 7 b71 creates 79 loggers on solaris-i586 and 34 loggers
>> on windows-i586. SwingSet2 creates a total of 85 loggers including a few
>> non-awt ones on solaris-i586 and 35 on windows-i586).
>> Although the memory usage might not be very high (especially with this fix),
>> I don't see the need of having many fine-grained loggers.  This fix doesn't
>> address this the number of AWT loggers. I file a separate CR (6880089) to
>> revisit it.
>>
>> Startup Performance:
>> This change does not have significant startup performance improvement, as
>> expected.  However, it does reduce the number of loaded classes (Framer app
>> loads 16 fewer classes and jedit loads 13 fewer classes).
>>
>>
>> Thanks
>> Mandy
>>
>>
>>

From gnu_andrew at member.fsf.org  Mon Sep 14 13:19:35 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 14 Sep 2009 21:19:35 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] Review Request for 6879044
In-Reply-To: <4AAD9D2D.6000502@sun.com>
References: <4AAD9D2D.6000502@sun.com>
Message-ID: <17c6771e0909141319w433d93bfma77cdb695cc8abb@mail.gmail.com>

2009/9/14 Mandy Chung <Mandy.Chung at sun.com>:
> 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 class that will handle the log
> messages in a similar way as Logger but it will only delegate to
> java.util.logging only when it is enabled. ?LogManager and LogRecord are
> modified to support the platform loggers. ?The users of PlatformLogger will
> continue to run if java.util.logging classes do not exist.
>
> 2. AWT, 2D, Swing, and a few java.util classes are modified to use
> PlatformLogger instead of Logger. ?Although many files are modified, the
> change is mostly replacement with classname.
>
> AWT statically creates a number of loggers. Running a simple AWT Framer
> application with JDK 7 b71 creates 79 loggers on solaris-i586 and 34 loggers
> on windows-i586. SwingSet2 creates a total of 85 loggers including a few
> non-awt ones on solaris-i586 and 35 on windows-i586).
> Although the memory usage might not be very high (especially with this fix),
> I don't see the need of having many fine-grained loggers. ?This fix doesn't
> address this the number of AWT loggers. I file a separate CR (6880089) to
> revisit it.
>
> Startup Performance:
> This change does not have significant startup performance improvement, as
> expected. ?However, it does reduce the number of loaded classes (Framer app
> loads 16 fewer classes and jedit loads 13 fewer classes).
>
>
> Thanks
> Mandy
>
>
>

I'm curious as to why some of the initialisations are lazy and some
are eager.  Notably AWTEvent is changed from eager to lazy:

 public abstract class AWTEvent extends EventObject {
-    private static final Logger log = Logger.getLogger("java.awt.AWTEvent");
+    private static volatile PlatformLogger log;
+
...
+
+    // log fine message to the java.awt.AWTEvent logger
+    private static void fine(String msg, Throwable t) {
+        if (log == null) {
+            log = PlatformLogger.getLogger("java.awt.AWTEvent");
+        }
+        if (log.isLoggable(PlatformLogger.FINE)) {
+            log.fine(msg, t);
+        }
+    }
+


Although the use of volatile should ensure the correct ordering of
operations, there is still the possibility of a minor race here as the
if condition and its body are not atomic; thus there could be multiple
calls to PlatformLogger.getLogger should a thread be interrupted
between the check and the assignment.

Why not just use a straightforward static assignment to a final
variable as before?  Is it really that unlikely that fine() will be
called that we need not initialise this early?.  At the very least
consider using the lazy holder idiom over volatile.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From son.two at gmail.com  Mon Sep 14 20:04:10 2009
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Tue, 15 Sep 2009 07:04:10 +0400
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AAE7B12.5000403@Sun.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
	<4AAE7B12.5000403@Sun.com>
Message-ID: <271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>

On Mon, Sep 14, 2009 at 9:19 PM, Mandy Chung <Mandy.Chung at sun.com> wrote:
> Oleg Sukhodolsky wrote:
>>
>> On Mon, Sep 14, 2009 at 5:32 AM, Mandy Chung <Mandy.Chung at 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 class that will handle the log
>>> messages in a similar way as Logger but it will only delegate to
>>> java.util.logging only when it is enabled. ?LogManager and LogRecord are
>>> modified to support the platform loggers. ?The users of PlatformLogger
>>> will
>>> continue to run if java.util.logging classes do not exist.
>>
>> evaluation for 6879044 says:
>>
>> Add a PlatformLogger class that mimics the default logging behavior
>> (output the log message to System.err with simple formatting) and
>> creates a java.util.logging.Logger only when the logging facility is
>> used by the application or a user-defined configuration is supplied.
>>
>> which of two descriptions is correct one?
>
> Both are correct. ?Can you elaborate what issue;/confusion you see between
> the descriptions?

I thought that it is possible to log int a file using default logger,
thus I was surprised that
description of PlatformLogger says about System.err.  I'd expect
PlatformLogger to be a wrapper around the default logger,
and as far as I can see from provided sources it is.

> The class description of sun.util.logging.PlatformLogger has the details:
> http://cr.openjdk.java.net/~mchung/6879044/webrev.00/src/share/classes/sun/util/logging/PlatformLogger.java.html
>
>> Also I wonder if it is ok to get possible better modularization by
>> adding dependency to Sun's internal API into public packages.
>
> This fix is to eliminate the dependency to logging API. ? This internal
> PlatformLogger class is an implementation class only used by the JRE and
> always be present. ?Does this answer your question?

internal PlatformLogger is present in Sun's implementation of JRE
only, so such changes will
complicate porting JRE implementation.  Also I wonder how big logging
module is, what advantage we do receive
by removing dependency on it?  How many Mb we do not need to load in this case?

>>> 2. AWT, 2D, Swing, and a few java.util classes are modified to use
>>> PlatformLogger instead of Logger. ?Although many files are modified, the
>>> change is mostly replacement with classname.
>>
>> Well, at least in AWTEvent you have changed static initialization of
>> logger to lazy one.
>> Perhaps it is better to keep a static one to minimize your changes.
>
> This fix shows one way of lazy initializing an AWT logger to be referenced
> when fixing 6880089. ?The AWTEvent log messages are only output in the error
> conditions. ?In the normal cases, no message will be logged in this logger
> is not needed. ? I would expect that the fix for 6880089 may make some AWT
> loggers to be initialized lazily as this one.

I'd suggest to keep all logger's initialization as is to simplify the fix.

Oleg.

>
> Thanks for the review.
> Mandy
>
>> Oleg.
>>>
>>> AWT statically creates a number of loggers. Running a simple AWT Framer
>>> application with JDK 7 b71 creates 79 loggers on solaris-i586 and 34
>>> loggers
>>> on windows-i586. SwingSet2 creates a total of 85 loggers including a few
>>> non-awt ones on solaris-i586 and 35 on windows-i586).
>>> Although the memory usage might not be very high (especially with this
>>> fix),
>>> I don't see the need of having many fine-grained loggers. ?This fix
>>> doesn't
>>> address this the number of AWT loggers. I file a separate CR (6880089) to
>>> revisit it.
>>>
>>> Startup Performance:
>>> This change does not have significant startup performance improvement, as
>>> expected. ?However, it does reduce the number of loaded classes (Framer
>>> app
>>> loads 16 fewer classes and jedit loads 13 fewer classes).
>>>
>>>
>>> Thanks
>>> Mandy
>>>
>>>
>>>
>

From anthony.petrov at sun.com  Tue Sep 15 05:16:29 2009
From: anthony.petrov at sun.com (anthony.petrov at sun.com)
Date: Tue, 15 Sep 2009 12:16:29 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6868255: Requirements for correct
	operating of the	HW/LW Mixing feature need to be specified
Message-ID: <20090915121712.626E4121BC@hg.openjdk.java.net>

Changeset: 317ac0bf2285
Author:    anthony
Date:      2009-09-15 16:15 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/317ac0bf2285

6868255: Requirements for correct operating of the HW/LW Mixing feature need to be specified
Summary: The specification is updated
Reviewed-by: art, dcherepanov

! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java


From Anthony.Petrov at Sun.COM  Tue Sep 15 05:31:09 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Tue, 15 Sep 2009 16:31:09 +0400
Subject: <AWT Dev> sun.awt.disableMixing
In-Reply-To: <4f9903f0909140712x1aeb0bbbo1d70e93eb44a3db9@mail.gmail.com>
References: <4f9903f0908311002o1c1efc5dr3b7b9eef9bda8fdc@mail.gmail.com>
	<4AAE2B07.9000409@sun.com>
	<4f9903f0909140453r59f60fcj6828c028cdfe68d3@mail.gmail.com>
	<4AAE3797.5010406@sun.com>
	<4f9903f0909140712x1aeb0bbbo1d70e93eb44a3db9@mail.gmail.com>
Message-ID: <4AAF890D.1010406@sun.com>

On 09/14/2009 06:12 PM, Christopher Deckers wrote:
>> I doubt if either is possible technically: the System.get/setProperty() API
>> does not (and should not) know anything about AWT and its properties.
> 
> Yes, but when AWT reads that property (to eventually cache it), finds
> that it is null and decides to enabled HW/LW mixing, it could set the
> property to true. Or am I missing anything?

Frankly speaking, when a getter (especially, an internal one) sets what 
it tries reading, that looks wrong. This does not seem to be the right 
thing to do.
This looks like a complicated work-around that is difficult to document, 
and that might seem useful for a relatively small number of applications.

--
best regards,
Anthony

From Alan.Bateman at Sun.COM  Tue Sep 15 06:54:57 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Tue, 15 Sep 2009 14:54:57 +0100
Subject: <AWT Dev> 6854954: Eliminate static dependency on
	java.awt.AWTPermission
Message-ID: <4AAF9CB1.5000505@sun.com>


Sean, Mandy - can you review this? I also need someone from the AWT team.

This patch eliminates the static dependency on java.awt.AWTPermission 
from the security code, needed for the SecurityManager and default 
policy code to work in the event that the permission class is not 
present (in gui-less profile for example). The changes are relatively 
simple. Creation of the AWTPermissions is deferred until needed. If 
sun.awt.AWTPermissionFactory is present then it is used to create the 
AWTPermission instances. If not present, but somehow one the security 
manager's checkTopLevelWindow, checkSystemClipboardAccess, etc. methods 
is invoked then "fake" permissions are used. The reason for the approach 
is to keep the reflection usage to a minimum (usually we use the shared 
secrets mechanism to avoid reflection completely but for this case, 
there isn't one place to setup the secret).

The webrev is here:
  http://cr.openjdk.java.net/~alanb/6854954/webrev.00/

Thanks,

Alan.

From Mandy.Chung at Sun.COM  Tue Sep 15 11:43:55 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Tue, 15 Sep 2009 11:43:55 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] Review Request for 6879044
In-Reply-To: <17c6771e0909141319w433d93bfma77cdb695cc8abb@mail.gmail.com>
References: <4AAD9D2D.6000502@sun.com>
	<17c6771e0909141319w433d93bfma77cdb695cc8abb@mail.gmail.com>
Message-ID: <4AAFE06B.5080000@Sun.com>

Hi Andrew,

 > Why not just use a straightforward static assignment to a final
 > variable as before?

A simple AWT app creates 79 loggers on solaris-i586 and 34 loggers on 
windows-i586.  SwingSet2 creates a total of 85 loggers on solaris-i586 
and 35 on windows-i586.

Improvement on client startup performance and memory footprint has 
always been one of our top features in the past releases.

As I noted in CR 6880089 (Revisit the number of AWT loggers to reduce 
the memory usage), there is no strong reason why we need such 
fine-grained loggers.

I fixed AWTEvent since it's one obvious candidate for lazy 
initialization. With my fix, I reduced the number of loggers by 4.  Alex 
Potochkin also brought up a consistency issue that will be addressed by 
6880089 or a new CR.

 > Is it really that unlikely that fine() will be
 > called that we need not initialise this early?

AWT team, can 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.Chung at 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:
> 
>  public abstract class AWTEvent extends EventObject {
> -    private static final Logger log = Logger.getLogger("java.awt.AWTEvent");
> +    private static volatile PlatformLogger log;
> +
> ...
> +
> +    // log fine message to the java.awt.AWTEvent logger
> +    private static void fine(String msg, Throwable t) {
> +        if (log == null) {
> +            log = PlatformLogger.getLogger("java.awt.AWTEvent");
> +        }
> +        if (log.isLoggable(PlatformLogger.FINE)) {
> +            log.fine(msg, t);
> +        }
> +    }
> +
> 
> 
> Although the use of volatile should ensure the correct ordering of
> operations, there is still the possibility of a minor race here as the
> if condition and its body are not atomic; thus there could be multiple
> calls to PlatformLogger.getLogger should a thread be interrupted
> between the check and the assignment.
> 
> Why not just use a straightforward static assignment to a final
> variable as before?  Is it really that unlikely that fine() will be
> called that we need not initialise this early?.  At the very least
> consider using the lazy holder idiom over volatile.

From Mandy.Chung at Sun.COM  Tue Sep 15 12:13:08 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Tue, 15 Sep 2009 12:13:08 -0700
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
	<4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
Message-ID: <4AAFE744.4050009@Sun.com>



Oleg Sukhodolsky wrote:
> On Mon, Sep 14, 2009 at 9:19 PM, Mandy Chung <Mandy.Chung at 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 expect
> PlatformLogger to be a wrapper around the default logger,
> and as far as I can see from provided sources it is.

System.err is the default configuration that ConsoleHandler will output 
to.  The default handler specified in <JRE>/lib/logging.properties is:

# By default we only configure a ConsoleHandler, which will only
# show messages at the INFO and above levels.
handlers= java.util.logging.ConsoleHandler

# To also add the FileHandler, use the following line instead.
#handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler

If you want to log to a file, you need to supply a logging.properties to 
alter the handles property.   If you specify 
-Djava.util.logging.config.file=<your logging.properties>, all log 
messages will go to the file as described by your logging.properties. 
The only difference with the fix is that the platform loggers doesn't 
check if the <JRE>/lib/logging.properties is modified.

> internal PlatformLogger is present in Sun's implementation of JRE
> only, so such changes will
> complicate porting JRE implementation.  

How does it complicate the porting?

The issue we are dealing with is that the JDK is big and deeply 
interconnected [1].  A command-line hello program loads 300 classes and 
a Framer (awt version of helloworld) loads 834 classes running with JDK 
7 b71.

Without module support  (JSR 294 + jigsaw) - like we are today, 
continual JDK development could cause startup of a simple awt app to 
load over 1000 classes very easily (I actually recalled that one point 
in time it was over 1000 classes but we put a fix to reduce the number 
of loaded classes).

> Also I wonder how big logging
> module is, what advantage we do receive
> by removing dependency on it?  How many Mb we do not need to load in this case?

Not only the MB of the java.util.logging classes but the classes they 
pull in at runtime.

> I'd suggest to keep all logger's initialization as is to simplify the fix.

My goal is to reduce the number of logger instances created at startup. 
  In addition, I think the fix is very simple.  As I mentioned in my 
reply to Andrew, Alex Potochkin also brought up a consistency issue that 
will be addressed by 6880089 or a new CR.

I'm ok to take out the lazy initialization of AWT loggers in my fix as 
long as the AWT team is going to fix 6880089 soon.  Artem, Alex, what do 
you think?

Thanks
Mandy

[1] http://blogs.sun.com/mr/entry/massive_monolithic_jdk

From Sean.Mullan at Sun.COM  Tue Sep 15 14:23:52 2009
From: Sean.Mullan at Sun.COM (Sean Mullan)
Date: Tue, 15 Sep 2009 17:23:52 -0400
Subject: <AWT Dev> [security-dev 01209]: 6854954: Eliminate static
 dependency on java.awt.AWTPermission
In-Reply-To: <4AAF9CB1.5000505@sun.com>
References: <4AAF9CB1.5000505@sun.com>
Message-ID: <4AB005E8.7070803@sun.com>

Looks good to me.

Super small nit in SecurityConstants:

120                        try {

indentation is off by one space with rest of code.

--Sean

Alan Bateman wrote:
> 
> Sean, Mandy - can you review this? I also need someone from the AWT team.
> 
> This patch eliminates the static dependency on java.awt.AWTPermission 
> from the security code, needed for the SecurityManager and default 
> policy code to work in the event that the permission class is not 
> present (in gui-less profile for example). The changes are relatively 
> simple. Creation of the AWTPermissions is deferred until needed. If 
> sun.awt.AWTPermissionFactory is present then it is used to create the 
> AWTPermission instances. If not present, but somehow one the security 
> manager's checkTopLevelWindow, checkSystemClipboardAccess, etc. methods 
> is invoked then "fake" permissions are used. The reason for the approach 
> is to keep the reflection usage to a minimum (usually we use the shared 
> secrets mechanism to avoid reflection completely but for this case, 
> there isn't one place to setup the secret).
> 
> The webrev is here:
>  http://cr.openjdk.java.net/~alanb/6854954/webrev.00/
> 
> Thanks,
> 
> Alan.


From Mandy.Chung at Sun.COM  Tue Sep 15 15:51:01 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Tue, 15 Sep 2009 15:51:01 -0700
Subject: <AWT Dev> 6854954: Eliminate static dependency on
	java.awt.AWTPermission
In-Reply-To: <4AAF9CB1.5000505@sun.com>
References: <4AAF9CB1.5000505@sun.com>
Message-ID: <4AB01A55.80104@Sun.com>

Alan,

Looks good.  Minor nit in SecurityConstants.java
line 148 - good to add a blank line to separate the two fields

Mandy

Alan Bateman wrote:
> 
> Sean, Mandy - can you review this? I also need someone from the AWT team.
> 
> This patch eliminates the static dependency on java.awt.AWTPermission 
> from the security code, needed for the SecurityManager and default 
> policy code to work in the event that the permission class is not 
> present (in gui-less profile for example). The changes are relatively 
> simple. Creation of the AWTPermissions is deferred until needed. If 
> sun.awt.AWTPermissionFactory is present then it is used to create the 
> AWTPermission instances. If not present, but somehow one the security 
> manager's checkTopLevelWindow, checkSystemClipboardAccess, etc. methods 
> is invoked then "fake" permissions are used. The reason for the approach 
> is to keep the reflection usage to a minimum (usually we use the shared 
> secrets mechanism to avoid reflection completely but for this case, 
> there isn't one place to setup the secret).
> 
> The webrev is here:
>  http://cr.openjdk.java.net/~alanb/6854954/webrev.00/
> 
> Thanks,
> 
> Alan.

From Mandy.Chung at Sun.COM  Tue Sep 15 16:26:40 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Tue, 15 Sep 2009 16:26:40 -0700
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AAE0A13.3080709@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AAE0A13.3080709@sun.com>
Message-ID: <4AB022B0.5080901@Sun.com>

Alan, Thanks for the review.  I'll send out a new webrev to incorporate 
your feedback. Yes, I file a CR for the http protocol handler:
    6882384: Update http protocol handler to use PlatformLogger

Several 2D and sun.font classes are refactored in the 2D repository that 
will be integrated for b74.  Some classes I modified in the 2D repo are 
not in TL repo.  To simplify the integration, I file a new CR 6882376 
for the core-libs changes including changes in java.util classes that 
will go in TL repo that I think I can make b73.  The AWT/2D/Swing 
changes will go in 2D repo as a fix for 6879044.

I'll generate two new webrevs to separate the core-libs and awt/2d/swing 
stuff for the review.

Thanks
Mandy

Alan Bateman wrote:
> Mandy Chung wrote:
>> 6879044: Eliminate the dependency of logging from the JRE 
>> core/awt/swing classes
>>
>> Webrev:
>>   http://cr.openjdk.java.net/~mchung/6879044/webrev.00/
> The approach seems reasonable to me. It is a bit strange to redirect the 
> platform logging to j.u.logging if something up the stack starts logging 
> but I think we can live with this because these loggers are for 
> debugging purposes.
> 
> The changes to the AWT code are mostly mechanical, so I've only skimmed 
> these (assuming that someone from the AWT team with do a detailed check).
> 
> Have you tested this with a security manager set? I'm just wondering if 
> PlatformLogger's static initializer should do the property lookup in a 
> doPrivileged block. Also in the LoggerProxy for the line separator (BTW: 
> lineSeparator can be final).
> 
> Is isLoggingEnabled() used anywhere? I can't see it and wonder if it 
> should be removed. If it is used, then I assume it needs to be 
> synchronized with redirectPlatformLoggers.
> 
> You allow the PlatformLoggers to be GC'ed but the entries will remain in 
> the loggers map. I don't think this is a big deal because the AWT 
> classes will not be unloaded but might be worth putting a note in a 
> comment to re-visit this some time.
> 
> The static initializer in the forwarding proxy seems a bit messy. It 
> might look neater if changed to something like:
>    private static final Class<?> loggerClass = 
> getClass("java.lang.Logger");                          private static 
> final Method getLoggerMethod = getMethod(loggerClass, "getLogger", 
> String.class);
> where getClass does the Class.forName, returning null if CNF, getMethod 
> returns null if passed a null class, etc.
> 
> Minor nit but there are a few style/formatting issues in PlatformLogger. 
> For example, in JavaLogger there isn't a blank line between methods. It 
> might be worthing taking a pass over this to have it as neat as possible.
> 
> Do you have a bugID to track updating the http protocol handler? Jessie 
> did push some changes to eliminate the static dependency on logging and 
> it would be good if that code used PlatformLogger.
> 
> -Alan.

From Anthony.Petrov at Sun.COM  Wed Sep 16 03:22:37 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 16 Sep 2009 14:22:37 +0400
Subject: <AWT Dev> 6854954: Eliminate static dependency
	on	java.awt.AWTPermission
In-Reply-To: <4AAF9CB1.5000505@sun.com>
References: <4AAF9CB1.5000505@sun.com>
Message-ID: <4AB0BC6D.4030604@sun.com>

Hi Alan,

To contribute a little to the small nit picking process :) :

1. src/share/classes/javax/swing/JPopupMenu.java
Line 415 might be realigned to keep standard indentation.

2. The copyright notices might be updated to indicate that 2009 is the 
year of last modification of the files.

The rest looks good. Please consider that approved by the AWT team.

--
best regards,
Anthony


On 09/15/2009 05:54 PM, Alan Bateman wrote:
> 
> Sean, Mandy - can you review this? I also need someone from the AWT team.
> 
> This patch eliminates the static dependency on java.awt.AWTPermission 
> from the security code, needed for the SecurityManager and default 
> policy code to work in the event that the permission class is not 
> present (in gui-less profile for example). The changes are relatively 
> simple. Creation of the AWTPermissions is deferred until needed. If 
> sun.awt.AWTPermissionFactory is present then it is used to create the 
> AWTPermission instances. If not present, but somehow one the security 
> manager's checkTopLevelWindow, checkSystemClipboardAccess, etc. methods 
> is invoked then "fake" permissions are used. The reason for the approach 
> is to keep the reflection usage to a minimum (usually we use the shared 
> secrets mechanism to avoid reflection completely but for this case, 
> there isn't one place to setup the secret).
> 
> The webrev is here:
>  http://cr.openjdk.java.net/~alanb/6854954/webrev.00/
> 
> Thanks,
> 
> Alan.

From Anthony.Petrov at Sun.COM  Wed Sep 16 03:38:15 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 16 Sep 2009 14:38:15 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] Review Request for 6879044
In-Reply-To: <4AAFE06B.5080000@Sun.com>
References: <4AAD9D2D.6000502@sun.com>
	<17c6771e0909141319w433d93bfma77cdb695cc8abb@mail.gmail.com>
	<4AAFE06B.5080000@Sun.com>
Message-ID: <4AB0C017.8040203@sun.com>

Hi Mandy,

On 09/15/2009 10:43 PM, Mandy Chung wrote:
>  > Is it really that unlikely that fine() will be
>  > called that we need not initialise this early?
> 
> AWT team, can you confirm?

I didn't examine this particular AWTEvent class. I can confirm that in 
many places we call the fine() method directly. In most cases we only 
wrap the call with an if (logger.isLoggable(...)) when the string that 
we log contains some expressions (obviously, for performance reasons.)

--
best regards,
Anthony

From Anthony.Petrov at Sun.COM  Wed Sep 16 06:55:09 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 16 Sep 2009 17:55:09 +0400
Subject: <AWT Dev> Review request #1: 6689983 (reevaluate our
 inset-related code in XAWT)
In-Reply-To: <4A819026.9060109@sun.com>
References: <4A819026.9060109@sun.com>
Message-ID: <4AB0EE3D.7060204@sun.com>

It looks like the fix is awaiting a review for about a month by now. 
Would anyone take a look please?

--
best regards,
Anthony


On 08/11/2009 07:37 PM, Anthony Petrov wrote:
> Looks like the fix is quite belated. Here is the latest version.
> Changes include:
> 
> 1. Suggestions expressed by the reviewers of the fix.
> 
> 2. Critical tests now pass when executed on the Cygwin X server with 
> their "native" window manager (specifically, the NetBeans IDE runs fine).
> 
> 3. Added enough logging for debugging purposes.
> 
> 4. Various insignificant improvements and clean-ups.
> 
> Please review at:
> 
> http://cr.openjdk.java.net/~anthony/7-16-insets-6689983.1/
> 
> -- 
> best regards,
> Anthony

From Alan.Bateman at Sun.COM  Wed Sep 16 09:21:48 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 16 Sep 2009 17:21:48 +0100
Subject: <AWT Dev> 6854954: Eliminate static dependency
	on	java.awt.AWTPermission
In-Reply-To: <4AB0BC6D.4030604@sun.com>
References: <4AAF9CB1.5000505@sun.com> <4AB0BC6D.4030604@sun.com>
Message-ID: <4AB1109C.8040906@sun.com>

Anthony Petrov wrote:
> Hi Alan,
>
> To contribute a little to the small nit picking process :) :
>
> 1. src/share/classes/javax/swing/JPopupMenu.java
> Line 415 might be realigned to keep standard indentation.
>
> 2. The copyright notices might be updated to indicate that 2009 is the 
> year of last modification of the files.
>
> The rest looks good. Please consider that approved by the AWT team.
Thanks (and thanks Sean and Mandy). I'll fix the alignment in JPopupMenu 
(it pre-dates my proposed change of course). I could update the date 
range in the header but I don't think we have to do that (I'm pretty 
sure Xiomara runs a script that periodically updates these).

-Alan.



From Anthony.Petrov at Sun.COM  Wed Sep 16 10:08:13 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 16 Sep 2009 21:08:13 +0400
Subject: <AWT Dev> 6854954: Eliminate static dependency
	on	java.awt.AWTPermission
In-Reply-To: <4AB1109C.8040906@sun.com>
References: <4AAF9CB1.5000505@sun.com> <4AB0BC6D.4030604@sun.com>
	<4AB1109C.8040906@sun.com>
Message-ID: <4AB11B7D.4090200@sun.com>

On 9/16/2009 8:21 PM Alan Bateman wrote:
>> 2. The copyright notices might be updated to indicate that 2009 is the 
>> year of last modification of the files.
>>
...
> (it pre-dates my proposed change of course). I could update the date 
> range in the header but I don't think we have to do that (I'm pretty 
> sure Xiomara runs a script that periodically updates these).

Xiomara, could you confirm that?

--
best regards,
Anthony

From Xiomara.Jayasena at Sun.COM  Wed Sep 16 10:17:01 2009
From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena)
Date: Wed, 16 Sep 2009 10:17:01 -0700
Subject: <AWT Dev> 6854954: Eliminate static dependency
	on	java.awt.AWTPermission
In-Reply-To: <4AB11B7D.4090200@sun.com>
References: <4AAF9CB1.5000505@sun.com> <4AB0BC6D.4030604@sun.com>
	<4AB1109C.8040906@sun.com> <4AB11B7D.4090200@sun.com>
Message-ID: <4AB11D8D.8000304@sun.com>



Anthony Petrov wrote:
> On 9/16/2009 8:21 PM Alan Bateman wrote:
>>> 2. The copyright notices might be updated to indicate that 2009 is 
>>> the year of last modification of the files.
>>>
> ...
>> (it pre-dates my proposed change of course). I could update the date 
>> range in the header but I don't think we have to do that (I'm pretty 
>> sure Xiomara runs a script that periodically updates these).
>
> Xiomara, could you confirm that?

Right, that is the process. 

-Xiomara

>
> -- 
> best regards,
> Anthony

From Anthony.Petrov at Sun.COM  Wed Sep 16 10:46:22 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 16 Sep 2009 21:46:22 +0400
Subject: <AWT Dev> 6854954: Eliminate static dependency
	on	java.awt.AWTPermission
In-Reply-To: <4AB11D8D.8000304@sun.com>
References: <4AAF9CB1.5000505@sun.com> <4AB0BC6D.4030604@sun.com>
	<4AB1109C.8040906@sun.com> <4AB11B7D.4090200@sun.com>
	<4AB11D8D.8000304@sun.com>
Message-ID: <4AB1246E.6020806@sun.com>

On 9/16/2009 9:17 PM Xiomara Jayasena wrote:
>>>> 2. The copyright notices might be updated to indicate that 2009 is 
>>>> the year of last modification of the files.
>>>>
>> ...
>>> (it pre-dates my proposed change of course). I could update the date 
>>> range in the header but I don't think we have to do that (I'm pretty 
>>> sure Xiomara runs a script that periodically updates these).
>>
>> Xiomara, could you confirm that?
> 
> Right, that is the process.

That sounds great! Thanks for the information!

--
best regards,
Anthony

From Mandy.Chung at Sun.COM  Wed Sep 16 17:38:19 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Wed, 16 Sep 2009 17:38:19 -0700
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AAD9D2D.6000502@sun.com>
References: <4AAD9D2D.6000502@sun.com>
Message-ID: <4AB184FB.7080603@sun.com>

Here are the new webrevs:

core-libs changes that include java.util.Currency:
    http://cr.openjdk.java.net/~mchung/6882376/webrev.00/

    - Added a new jtreg test
    - Cleaned up PlatformLogger.java per Alan's feedback.

awt/2d/swing changes:
    http://cr.openjdk.java.net/~mchung/6879044/webrev.01/

    - Keep the logger in AWTEvent.java and Cursor.java be statically 
initialized.
    - I updated 6880089 to consider lazy initialization or reduce to a 
few loggers vs 85 on unix and 35 on windows.  I decide to leave it to 
the fix for 6880089 to make a consistent change.

Files other than the one listed above are not changed since the last 
version.

Thanks
Mandy

Mandy Chung 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 class that will handle the 
> log messages in a similar way as Logger but it will only delegate to 
> java.util.logging only when it is enabled.  LogManager and LogRecord 
> are modified to support the platform loggers.  The users of 
> PlatformLogger will continue to run if java.util.logging classes do 
> not exist.
>
> 2. AWT, 2D, Swing, and a few java.util classes are modified to use 
> PlatformLogger instead of Logger.  Although many files are modified, 
> the change is mostly replacement with classname.
>
> AWT statically creates a number of loggers. Running a simple AWT 
> Framer application with JDK 7 b71 creates 79 loggers on solaris-i586 
> and 34 loggers on windows-i586. SwingSet2 creates a total of 85 
> loggers including a few non-awt ones on solaris-i586 and 35 on 
> windows-i586).
> Although the memory usage might not be very high (especially with this 
> fix), I don't see the need of having many fine-grained loggers.  This 
> fix doesn't address this the number of AWT loggers. I file a separate 
> CR (6880089) to revisit it.
>
> Startup Performance:
> This change does not have significant startup performance improvement, 
> as expected.  However, it does reduce the number of loaded classes 
> (Framer app loads 16 fewer classes and jedit loads 13 fewer classes).
>
>
> Thanks
> Mandy
>
>


From son.two at gmail.com  Wed Sep 16 19:43:16 2009
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Thu, 17 Sep 2009 06:43:16 +0400
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AAFE744.4050009@Sun.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
	<4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
Message-ID: <271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>

On Tue, Sep 15, 2009 at 11:13 PM, Mandy Chung <Mandy.Chung at sun.com> wrote:
>
>
> Oleg Sukhodolsky wrote:
>>
>> On Mon, Sep 14, 2009 at 9:19 PM, Mandy Chung <Mandy.Chung at 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 expect
>> PlatformLogger to be a wrapper around the default logger,
>> and as far as I can see from provided sources it is.
>
> System.err is the default configuration that ConsoleHandler will output to.
> ?The default handler specified in <JRE>/lib/logging.properties is:
>
> # By default we only configure a ConsoleHandler, which will only
> # show messages at the INFO and above levels.
> handlers= java.util.logging.ConsoleHandler
>
> # To also add the FileHandler, use the following line instead.
> #handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
>
> If you want to log to a file, you need to supply a logging.properties to
> alter the handles property. ? If you specify
> -Djava.util.logging.config.file=<your logging.properties>, all log messages
> will go to the file as described by your logging.properties. The only
> difference with the fix is that the platform loggers doesn't check if the
> <JRE>/lib/logging.properties is modified.
>
>> internal PlatformLogger is present in Sun's implementation of JRE
>> only, so such changes will
>> complicate porting JRE implementation.
>
> How does it complicate the porting?

I'm not sure that IBM's or some other's version of JDK is allowed to
contain such
classes, thus it may be harder to port our RI to their implementation .

> The issue we are dealing with is that the JDK is big and deeply
> interconnected [1]. ?A command-line hello program loads 300 classes and a
> Framer (awt version of helloworld) loads 834 classes running with JDK 7 b71.
>
> Without module support ?(JSR 294 + jigsaw) - like we are today, continual
> JDK development could cause startup of a simple awt app to load over 1000
> classes very easily (I actually recalled that one point in time it was over
> 1000 classes but we put a fix to reduce the number of loaded classes).

What if an application will use logging? How many Logger.getLogger()
user need to add to his(her)
code to completely initialize logging and make your changes useless?  How often
we will have user's code which doesn't use logging?
Why we have to remove all usages of logging in our code instead of
changing logging package to be
more startup friendly?

Oleg.

>> Also I wonder how big logging
>> module is, what advantage we do receive
>> by removing dependency on it? ?How many Mb we do not need to load in this
>> case?
>
> Not only the MB of the java.util.logging classes but the classes they pull
> in at runtime.
>
>> I'd suggest to keep all logger's initialization as is to simplify the fix.
>
> My goal is to reduce the number of logger instances created at startup. ?In
> addition, I think the fix is very simple. ?As I mentioned in my reply to
> Andrew, Alex Potochkin also brought up a consistency issue that will be
> addressed by 6880089 or a new CR.
>
> I'm ok to take out the lazy initialization of AWT loggers in my fix as long
> as the AWT team is going to fix 6880089 soon. ?Artem, Alex, what do you
> think?
>
> Thanks
> Mandy
>
> [1] http://blogs.sun.com/mr/entry/massive_monolithic_jdk
>

From Alan.Bateman at Sun.COM  Thu Sep 17 01:56:42 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 17 Sep 2009 09:56:42 +0100
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
	<4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
Message-ID: <4AB1F9CA.40309@sun.com>

Oleg Sukhodolsky wrote:
> On Tue, Sep 15, 2009 at 11:13 PM, Mandy Chung <Mandy.Chung at sun.com> wrote:
>   
>> :
>>> complicate porting JRE implementation.
>>>       
>> How does it complicate the porting?
>>     
>
> I'm not sure that IBM's or some other's version of JDK is allowed to
> contain such
> classes, thus it may be harder to port our RI to their implementation .
>   
I don't see a problem here. These are implementation classes (you'll see 
that AWT already makes use of lot of implementation classes from 
sun.awt, sun.security, sun.java2d, and more). Furthermore, these changes 
aren't introducing any platform dependent or native code that increases 
porting efforts. If there are ports that already remove these loggers 
then the effort, once Mandy's changes are in, isn't any different.

:

> Why we have to remove all usages of logging in our code instead of
> changing logging package to be
> more startup friendly?
>   
I haven't seen any proposals to eliminate the logging but rather the 
suggestion is that this logging should be re-examined because there are 
way too many loggers created at startup. For example, one of the 
suggestions that Mandy has put in 6880089 [1] is that there be a logger 
per core component rather than class.

-Alan.

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880089



From son.two at gmail.com  Thu Sep 17 02:20:35 2009
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Thu, 17 Sep 2009 13:20:35 +0400
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AB1F9CA.40309@sun.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
	<4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com>
Message-ID: <271e55d20909170220i73d31a2do43b8dcf750f792d1@mail.gmail.com>

On Thu, Sep 17, 2009 at 12:56 PM, Alan Bateman <Alan.Bateman at sun.com> wrote:
> Oleg Sukhodolsky wrote:
>>
>> On Tue, Sep 15, 2009 at 11:13 PM, Mandy Chung <Mandy.Chung at sun.com> wrote:
>>
>>>
>>> :
>>>>
>>>> complicate porting JRE implementation.
>>>>
>>>
>>> How does it complicate the porting?
>>>
>>
>> I'm not sure that IBM's or some other's version of JDK is allowed to
>> contain such
>> classes, thus it may be harder to port our RI to their implementation .
>>
>
> I don't see a problem here. These are implementation classes (you'll see
> that AWT already makes use of lot of implementation classes from sun.awt,
> sun.security, sun.java2d, and more). Furthermore, these changes aren't
> introducing any platform dependent or native code that increases porting
> efforts. If there are ports that already remove these loggers then the
> effort, once Mandy's changes are in, isn't any different.

Ok, they just add one more issue to solve for porters :)

>> Why we have to remove all usages of logging in our code instead of
>> changing logging package to be
>> more startup friendly?
>>
>
> I haven't seen any proposals to eliminate the logging but rather the
> suggestion is that this logging should be re-examined because there are way
> too many loggers created at startup. For example, one of the suggestions
> that Mandy has put in 6880089 [1] is that there be a logger per core
> component rather than class.

By "remove all usages of logging" I meant "remove all usages of
standard logging package".
And, again, I do not understand why we can not change the logging
package instead (perhaps we can not,
but no body has explained why).  BTW if we can change the logging
package to resolve this problem for our code,
such changes will also help to other java developers.

Also since it look like all suggested changes are about startup
performance it would be nice to see results of
performance testing which would prove that suggested changes will
help, and show what kind of applications
will benefit from the changes.  Without such results we can not be
sure that the changes will help and
they can be treated as "premature optimization"

Oleg.

>
> -Alan.
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880089
>
>
>

From Anthony.Petrov at Sun.COM  Thu Sep 17 03:01:13 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 17 Sep 2009 14:01:13 +0400
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AB1F9CA.40309@sun.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
	<4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com>
Message-ID: <4AB208E9.8020900@sun.com>

On 09/17/2009 12:56 PM, Alan Bateman wrote:
> I haven't seen any proposals to eliminate the logging but rather the 
> suggestion is that this logging should be re-examined because there are 
> way too many loggers created at startup. For example, one of the 
> suggestions that Mandy has put in 6880089 [1] is that there be a logger 
> per core component rather than class.

I have to say that that is not the best possible solution. For instance, 
the sun.awt.X11 classes have many different loggers: for focus-related 
code, for insets-related code, and so on. If a developer debugs a 
particular kind of problem, (s)he doesn't need to look through all the 
garbage that other loggers generate: it's just enough to enable a 
particular logging facility (such as the
"sun.awt.X11.insets.XDecoratedPeer" for example) and examine what (s)he 
really needs.
Combining all the output to just one logger will make debugging a nightmare.

I would second to Oleg: improving the performance/design of the existing 
logging classes at java.util.logging package would help all applications 
at once.

--
best regards,
Anthony

From Alan.Bateman at Sun.COM  Thu Sep 17 03:08:55 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 17 Sep 2009 11:08:55 +0100
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AB184FB.7080603@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB184FB.7080603@sun.com>
Message-ID: <4AB20AB7.1020506@sun.com>

Mandy Chung wrote:
> Here are the new webrevs:
>
> core-libs changes that include java.util.Currency:
>    http://cr.openjdk.java.net/~mchung/6882376/webrev.00/
>
>    - Added a new jtreg test
>    - Cleaned up PlatformLogger.java per Alan's feedback.
This looks much better. A couple of additional comments:

I see the lookup of the logging properties is now in a doPrivileged 
block - do you need to do the same for the line.separator?

In LoggerProxy, should levelValue and effectiveLevel be volatile?

In JavaLogger.getMethod I see that you return null if the method is not 
found. Should it be better to throw an InternalError or AssertionError 
here? That is, if java.util.logging is present then something is 
seriously wrong is the Logger methods don't exist.

Otherwise, I think I'm okay with this.

-Alan.


From Alan.Bateman at Sun.COM  Thu Sep 17 03:43:06 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 17 Sep 2009 11:43:06 +0100
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AB208E9.8020900@sun.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
	<4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com> <4AB208E9.8020900@sun.com>
Message-ID: <4AB212BA.6040405@sun.com>

Anthony Petrov wrote:
> :
> I have to say that that is not the best possible solution. For 
> instance, the sun.awt.X11 classes have many different loggers: for 
> focus-related code, for insets-related code, and so on. If a developer 
> debugs a particular kind of problem, (s)he doesn't need to look 
> through all the garbage that other loggers generate: it's just enough 
> to enable a particular logging facility (such as the
> "sun.awt.X11.insets.XDecoratedPeer" for example) and examine what 
> (s)he really needs.
> Combining all the output to just one logger will make debugging a 
> nightmare.
>
> I would second to Oleg: improving the performance/design of the 
> existing logging classes at java.util.logging package would help all 
> applications at once.
I'm not familiar with the AWT implementation to have a strong view as to 
how 6880089 is addressed. However, Mandy does raise a good question as 
to why there is a need for so many loggers. I think one mail mentioned 
there 85 loggers setup when running simple "hello world" Framer test. 
Maybe they can be created lazily; maybe some of them aren't needed, but 
at least there is a bug created so that someone can re-visit this. I 
agree that any improvements to j.u.logging would be welcome too but that 
doesn't solve the desire to decouple the dependency. For example, if the 
libraries are broken up into a set of fine grain modules then why would 
I need to have a logging module installed to run a simple client 
application?

-Alan.







From son.two at gmail.com  Thu Sep 17 04:17:56 2009
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Thu, 17 Sep 2009 15:17:56 +0400
Subject: <AWT Dev> Review Request for 6879044
In-Reply-To: <4AB212BA.6040405@sun.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
	<4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com> <4AB208E9.8020900@sun.com>
	<4AB212BA.6040405@sun.com>
Message-ID: <271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>

On Thu, Sep 17, 2009 at 2:43 PM, Alan Bateman <Alan.Bateman at sun.com> wrote:
> Anthony Petrov wrote:
>>
>> :
>> I have to say that that is not the best possible solution. For instance,
>> the sun.awt.X11 classes have many different loggers: for focus-related code,
>> for insets-related code, and so on. If a developer debugs a particular kind
>> of problem, (s)he doesn't need to look through all the garbage that other
>> loggers generate: it's just enough to enable a particular logging facility
>> (such as the
>> "sun.awt.X11.insets.XDecoratedPeer" for example) and examine what (s)he
>> really needs.
>> Combining all the output to just one logger will make debugging a
>> nightmare.
>>
>> I would second to Oleg: improving the performance/design of the existing
>> logging classes at java.util.logging package would help all applications at
>> once.
>
> I'm not familiar with the AWT implementation to have a strong view as to how
> 6880089 is addressed. However, Mandy does raise a good question as to why
> there is a need for so many loggers. I think one mail mentioned there 85
> loggers setup when running simple "hello world" Framer test. Maybe they can
> be created lazily; maybe some of them aren't needed, but at least there is a
> bug created so that someone can re-visit this. I agree that any improvements
> to j.u.logging would be welcome too but that doesn't solve the desire to
> decouple the dependency.

imho removing dependency on j.u.logging for me looks as strange as removing
dependency on j.l.Object or java.util.* :)

> For example, if the libraries are broken up into a
> set of fine grain modules then why would I need to have a logging module
> installed to run a simple client application?

Perhaps because most application use logging ;)

From Igor.Nekrestyanov at Sun.COM  Thu Sep 17 04:17:55 2009
From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov)
Date: Thu, 17 Sep 2009 04:17:55 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4AB208E9.8020900@sun.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
	<4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com> <4AB208E9.8020900@sun.com>
Message-ID: <4AB21AE3.8090207@sun.com>


> I would second to Oleg: improving the performance/design of the 
> existing logging classes at java.util.logging package would help all 
> applications at once.
That certainly will be best thing to do but unfortunately it is not easy 
(possible?) maintaining backward compatibility.

Several people had been looking into this in the past.
Please feel free to advise if you see how it can be improved.

-igor


From Igor.Nekrestyanov at Sun.COM  Thu Sep 17 04:20:08 2009
From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov)
Date: Thu, 17 Sep 2009 04:20:08 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
References: <4AAD9D2D.6000502@sun.com>
	<271e55d20909132044k3b6b7a5bw86e87a5e21a2c34e@mail.gmail.com>
	<4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com> <4AB208E9.8020900@sun.com>
	<4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
Message-ID: <4AB21B68.90603@sun.com>


> imho removing dependency on j.u.logging for me looks as strange as removing
> dependency on j.l.Object or java.util.* :)
>
>   
>> For example, if the libraries are broken up into a
>> set of fine grain modules then why would I need to have a logging module
>> installed to run a simple client application?
>>     
>
> Perhaps because most application use logging ;)
>   
But in general it is useful for developers only.
Why end user need it unless it wants to debug/trace?

-igor


From son.two at gmail.com  Thu Sep 17 04:32:45 2009
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Thu, 17 Sep 2009 15:32:45 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4AB21B68.90603@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com> <4AB208E9.8020900@sun.com>
	<4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
Message-ID: <271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>

On Thu, Sep 17, 2009 at 3:20 PM, Igor Nekrestyanov
<Igor.Nekrestyanov at sun.com> wrote:
>
>> imho removing dependency on j.u.logging for me looks as strange as
>> removing
>> dependency on j.l.Object or java.util.* :)
>>
>>
>>>
>>> For example, if the libraries are broken up into a
>>> set of fine grain modules then why would I need to have a logging module
>>> installed to run a simple client application?
>>>
>>
>> Perhaps because most application use logging ;)
>>
>
> But in general it is useful for developers only.

Agree, but if the application uses logging (which is disabled of course)
it anyway initialize the logging and has the same problem as AWT or 2D have now.

> Why end user need it unless it wants to debug/trace?

the end-user doesn't need logging, but application may contain it any way.

Oleg.
>
> -igor
>
>

From Anthony.Petrov at Sun.COM  Thu Sep 17 05:38:28 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 17 Sep 2009 16:38:28 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
References: <4AAD9D2D.6000502@sun.com> <4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com> <4AB208E9.8020900@sun.com>
	<4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
Message-ID: <4AB22DC4.2050106@sun.com>

On 09/17/2009 03:32 PM, Oleg Sukhodolsky wrote:
>>> imho removing dependency on j.u.logging for me looks as strange as
>>> removing
>>> dependency on j.l.Object or java.util.* :)
>>>
>>>
>>>> For example, if the libraries are broken up into a
>>>> set of fine grain modules then why would I need to have a logging module
>>>> installed to run a simple client application?
>>>>
>>> Perhaps because most application use logging ;)
>>>
>> But in general it is useful for developers only.
> 
> Agree, but if the application uses logging (which is disabled of course)
> it anyway initialize the logging and has the same problem as AWT or 2D have now.
> 
>> Why end user need it unless it wants to debug/trace?
> 
> the end-user doesn't need logging, but application may contain it any way.

The fix simply introduces a lightweight version of the logging facility. 
Still, we didn't see any figures demonstrating a possible performance 
gain, or memory-usage optimization, or download size reduction. These 
would be very interesting to look over.

--
best regards,
Anthony

From Mandy.Chung at Sun.COM  Thu Sep 17 10:54:10 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Thu, 17 Sep 2009 10:54:10 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
References: <4AAD9D2D.6000502@sun.com> <4AAE7B12.5000403@Sun.com>
	<271e55d20909142004r4b566cdawfe935115bd099e9d@mail.gmail.com>
	<4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com> <4AB208E9.8020900@sun.com>
	<4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
Message-ID: <4AB277C2.8030603@Sun.com>

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 addressing 
problem described in (1).

(1) The problem is to decouple the dependency on logging from some JRE 
components.

FYI. The jigsaw project page [1] provides links to the good background 
why we're doing that.  Mark gave a very good overview and demo of 
Project jigsaw at JavaOne General Technical Session[2].

Logging is one candidate module if the libraries are broken up into a 
set of fine grained modules.   The fix for 6882376 provides the internal 
support for JRE implementation to eliminate their dependency on logging. 
  Alan and Naoto reviewed the fix.

As for the AWT/2D/Swing changes,
    6879044: Eliminate the dependency on logging from the AWT/2D/Swing 
classes,

When the libraries are broken into modules, are you saying that the 
client module should require the logging module to exist?  On the other 
hand, as Alan explained, why would a user need to have a logging module 
installed to run a simple client application?

Artem and Dmitri reviewed the fix.   If you have another proposal of 
decoupling the dependency, I would be interested too.

(2) Startup performance improvement

The suggested change does not have a signifcant startup performance as 
expected (as I mentioned in the bug report).  It does load fewer classes 
(~16 classes) which isn't bad.  My apology if I confuse you when we 
mixed it in this review request.

I have done some performance analysis [3] [4] to determine what 
opportunity the jigsaw module system could implement and the estimate of 
the startup time improvement we could possibly get.  Decoupling 
dependency is an important step to modularize the JDK while the startup 
gain may not be materialized until the module system is in place.

(3) AWT loggers

The AWT loggers are for debugging purpose.  I understand the advantage 
of fine-grained loggers to have a fine-grained control of the debugging 
output.  It's a tradeoff between performance (time and memory) and such 
debugging ability.  I would argue that this fine-grained debugging 
ability is nice to have but isn't necessary to be available in the 
production environment.  You should consider some way to enable such 
debuggability but disabled by default to minimize the performance 
overhead such as lazily creating these logger.  sun.font only enables 
logging when -Dsun.java2d.debugfonts=true system property is set to 
true.  This should be revisited - see 6880089 [5].

(4) Performance and design of java.util.logging

I totally agree with that the performance and design of j.u.logging 
should be improved.  If you have any idea and solution, your 
contribution would be appreciated.  In fact, I would hope that we could 
have something like DTrace [6] that tracing code can be added in the 
implementation but no overhead is paid if the probes are not enabled [7].

Thanks
Mandy

[1] http://openjdk.java.net/projects/jigsaw/
[2] 
http://java.sun.com/javaone/2009/playlist.jsp?pid=24494811001&autoStart=on
[3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
[4] 
http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64
[5] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880089
[6] http://www.sun.com/bigadmin/content/dtrace/index.jsp
[7] https://btrace.dev.java.net/

From son.two at gmail.com  Thu Sep 17 19:45:40 2009
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Fri, 18 Sep 2009 06:45:40 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4AB277C2.8030603@Sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com> <4AB208E9.8020900@sun.com>
	<4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
Message-ID: <271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>

Hi Mandy,

On Thu, Sep 17, 2009 at 9:54 PM, Mandy Chung <Mandy.Chung at sun.com> wrote:
> 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 addressing problem described
> in (1).
>
> (1) The problem is to decouple the dependency on logging from some JRE
> components.
>
> FYI. The jigsaw project page [1] provides links to the good background why
> we're doing that. ?Mark gave a very good overview and demo of Project jigsaw
> at JavaOne General Technical Session[2].
>
> Logging is one candidate module if the libraries are broken up into a set of
> fine grained modules. ? The fix for 6882376 provides the internal support
> for JRE implementation to eliminate their dependency on logging. ?Alan and
> Naoto reviewed the fix.
>
> As for the AWT/2D/Swing changes,
> ? 6879044: Eliminate the dependency on logging from the AWT/2D/Swing
> classes,
>
> When the libraries are broken into modules, are you saying that the client
> module should require the logging module to exist? ?On the other hand, as
> Alan explained, why would a user need to have a logging module installed to
> run a simple client application?

Ok, so this fix is only about modules.  But why AWT should not depend
on logging module?
The qiestion is: how many application we want to run doesn't use
logging& Because if an application
uses logging there is no reasons for AWT to not use it.  Please note
that even if logging is turned
off, the application still needs logging package/module.  So, though
end-user doesn't need logging output
she may need logging module to run the application.  So, it is really
important to understand
what number of application will get advantage of suggested changes.

Second question is: how big logging module is going to be? How big the
benefit for end-user will be?

I'm asking so many question mainly because the changes you suggested
create rather unnatural code (we can not
use standard logging machinery any more), so such changes should be
well-justified.

With best regards, Oleg.

> Artem and Dmitri reviewed the fix. ? If you have another proposal of
> decoupling the dependency, I would be interested too.
>
> (2) Startup performance improvement
>
> The suggested change does not have a signifcant startup performance as
> expected (as I mentioned in the bug report). ?It does load fewer classes
> (~16 classes) which isn't bad. ?My apology if I confuse you when we mixed it
> in this review request.
>
> I have done some performance analysis [3] [4] to determine what opportunity
> the jigsaw module system could implement and the estimate of the startup
> time improvement we could possibly get. ?Decoupling dependency is an
> important step to modularize the JDK while the startup gain may not be
> materialized until the module system is in place.
>
> (3) AWT loggers
>
> The AWT loggers are for debugging purpose. ?I understand the advantage of
> fine-grained loggers to have a fine-grained control of the debugging output.
> ?It's a tradeoff between performance (time and memory) and such debugging
> ability. ?I would argue that this fine-grained debugging ability is nice to
> have but isn't necessary to be available in the production environment. ?You
> should consider some way to enable such debuggability but disabled by
> default to minimize the performance overhead such as lazily creating these
> logger. ?sun.font only enables logging when -Dsun.java2d.debugfonts=true
> system property is set to true. ?This should be revisited - see 6880089 [5].
>
> (4) Performance and design of java.util.logging
>
> I totally agree with that the performance and design of j.u.logging should
> be improved. ?If you have any idea and solution, your contribution would be
> appreciated. ?In fact, I would hope that we could have something like DTrace
> [6] that tracing code can be added in the implementation but no overhead is
> paid if the probes are not enabled [7].
>
> Thanks
> Mandy
>
> [1] http://openjdk.java.net/projects/jigsaw/
> [2]
> http://java.sun.com/javaone/2009/playlist.jsp?pid=24494811001&autoStart=on
> [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
> [4]
> http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64
> [5] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880089
> [6] http://www.sun.com/bigadmin/content/dtrace/index.jsp
> [7] https://btrace.dev.java.net/
>

From Mandy.Chung at Sun.COM  Fri Sep 18 13:19:44 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Fri, 18 Sep 2009 13:19:44 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
References: <4AAD9D2D.6000502@sun.com> <4AAFE744.4050009@Sun.com>
	<271e55d20909161943v651a1006tff17cfd2542c4974@mail.gmail.com>
	<4AB1F9CA.40309@sun.com> <4AB208E9.8020900@sun.com>
	<4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
Message-ID: <4AB3EB60.7050600@sun.com>

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 the 
logging API is to support maintaining and servicing software at customer 
sites.   Adding debugging code in the awt implementation using logging 
API is reasonable but it's not the requirement for the logging API.  If 
there were a better option to add debugging code, I believe you have no 
problem changing the awt debugging code not to use the logging API.

Server-type applications are typical use cases that logging information 
is very important and useful for diagnosis in the field - long running 
apps, hard to reproduce problems until running for many days/months.  It 
is hard to imagine how the logging information is important in client 
applications.   But you seem to know many client applications use the 
logging API that I would also be interested to follow up with their 
requirements.

>
> Ok, so this fix is only about modules.  But why AWT should not depend
> on logging module?
> The qiestion is: how many application we want to run doesn't use
> logging& Because if an application
> uses logging there is no reasons for AWT to not use it.  Please note
> that even if logging is turned
> off, the application still needs logging package/module.  So, though
> end-user doesn't need logging output
> she may need logging module to run the application.  

This is exactly why we want to decouple the dependency on logging.  When 
an application uses logging, the application knows clearly what module 
they require and that's fine.  When an application doesn't logging, if 
the awt component requires logging for debugging purpose only, it 
increases the download size, footprint and startup performance (class 
lookup time, loading, init, etc) - please see my performance analysis 
report; otherwise, it's not fruitful to discuss the details in this 
thread without the background info.  Just to mention it what we care about.

> So, it is really
> important to understand
> what number of application will get advantage of suggested changes.
>
>   

You are suggesting the client applications always have a dependency on 
logging.   Many client team engineers are happy to see the dependency on 
logging being eliminated from the client stack requirement and approve 
this fix :)

> Second question is: how big logging module is going to be? How big the
> benefit for end-user will be?
>
>   

The size of the logging API is not big (~90K) but the size is not the 
only one factor determining what benefit the end-user will have.   It's 
not necessary to logging API as one single module and details are to be 
worked out.   Subscribe to the jigsaw project to follow the discussion 
and progress there.   Serviceability includes other API as well.  If awt 
started using other serviceability API (java.lang.management, 
java.lang.instrument) for whatever reason, your argument would apply 
there as well.  I don't think you wanted the awt module depends on all 
the serviceability APIs.

> I'm asking so many question mainly because the changes you suggested
> create rather unnatural code (we can not
> use standard logging machinery any more), so such changes should be
> well-justified.
>
>   

That's what we pay for to modularize the JDK after many years of JDK 
development without module support in the platform.  Otherwise, if there 
were module support in the platform, you would consider very carefully 
when adding a dependency on another module.

If you have further issue, I suggest to start a different thread on the 
awt-dev alias.

Thanks
Mandy
[1] http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html

From son.two at gmail.com  Fri Sep 18 20:59:47 2009
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Sat, 19 Sep 2009 07:59:47 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4AB3EB60.7050600@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
Message-ID: <271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>

HI Mandy,

On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <Mandy.Chung at sun.com> wrote:
> 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 the logging API is
> to support maintaining and servicing software at customer sites. ? Adding
> debugging code in the awt implementation using logging API is reasonable but
> it's not the requirement for the logging API. ?If there were a better option
> to add debugging code, I believe you have no problem changing the awt
> debugging code not to use the logging API.
>
> Server-type applications are typical use cases that logging information is
> very important and useful for diagnosis in the field - long running apps,
> hard to reproduce problems until running for many days/months. ?It is hard
> to imagine how the logging information is important in client applications.

as ex-AWT developer I can confirm that there were number of cases when
logging had helped us to diagnose problem on client's site.  Even
though you usually
do not need to run an application for a long time to reproduce a problem
it can be very hard to reproduce it because the problem depends on
window manager
and other environment which is hard to re-create.

> ? But you seem to know many client applications use the logging API that I
> would also be interested to follow up with their requirements.

I do not know many client applications which uses logging API (because I have
never write real client application) and it is hard to say if it uses
logging or not.
I hoped that you who saying that suggested changes will help to client
application
has some statistic to confirm your expectation

>> Ok, so this fix is only about modules. ?But why AWT should not depend
>> on logging module?
>> The qiestion is: how many application we want to run doesn't use
>> logging& Because if an application
>> uses logging there is no reasons for AWT to not use it. ?Please note
>> that even if logging is turned
>> off, the application still needs logging package/module. ?So, though
>> end-user doesn't need logging output
>> she may need logging module to run the application.
>
> This is exactly why we want to decouple the dependency on logging. ?When an
> application uses logging, the application knows clearly what module they
> require and that's fine. ?When an application doesn't logging, if the awt
> component requires logging for debugging purpose only, it increases the
> download size, footprint and startup performance (class lookup time,
> loading, init, etc) - please see my performance analysis report; otherwise,
> it's not fruitful to discuss the details in this thread without the
> background info. ?Just to mention it what we care about.

I have found only two links to some performance analysis:

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64

but they say about -Xverify and -Xshare and do not understand how they
can be related
to our topic :(  If they do, please explain (I have never been an
expert in this area :(
Or, if I missed something could you please point me what I have missed.

>> So, it is really
>> important to understand
>> what number of application will get advantage of suggested changes.
>>
>>
>
> You are suggesting the client applications always have a dependency on
> logging. ? Many client team engineers are happy to see the dependency on
> logging being eliminated from the client stack requirement and approve this
> fix :)

I do not see how this can be considered as prove that the changes will
help client applications.
Unless we have some statistic it is all just our guess (which, as we
know, usually wrong ;)

>> Second question is: how big logging module is going to be? How big the
>> benefit for end-user will be?
>>
>>
>
> The size of the logging API is not big (~90K) but the size is not the only
> one factor determining what benefit the end-user will have.

what other factors do you know?

> ?It's not
> necessary to logging API as one single module and details are to be worked
> out. ? Subscribe to the jigsaw project to follow the discussion and progress
> there. ? Serviceability includes other API as well. ?If awt started using
> other serviceability API (java.lang.management, java.lang.instrument) for
> whatever reason, your argument would apply there as well. ?I don't think you
> wanted the awt module depends on all the serviceability APIs.

I agree that usage of any API should be done after careful consideration.
Logging API provides us exactly what we need (ability to create log of
an application
executed on client)  this is why we started to use it.

>> I'm asking so many question mainly because the changes you suggested
>> create rather unnatural code (we can not
>> use standard logging machinery any more), so such changes should be
>> well-justified.
>>
>>
>
> That's what we pay for to modularize the JDK after many years of JDK
> development without module support in the platform. ?Otherwise, if there
> were module support in the platform, you would consider very carefully when
> adding a dependency on another module.

perhaps you are right, but in case of logging I would expect that we'd use it
anyway.

Oleg.

>
> If you have further issue, I suggest to start a different thread on the
> awt-dev alias.
>
> Thanks
> Mandy
> [1] http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
>

From Andrei.Dmitriev at Sun.COM  Mon Sep 21 01:49:17 2009
From: Andrei.Dmitriev at Sun.COM (Andrei Dmitriev)
Date: Mon, 21 Sep 2009 12:49:17 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
Message-ID: <4AB73E0D.3000600@sun.com>

Hi Mandy, Oleg,

I'm going to summarize pros and cons of this change just to make judge 
(basically for myself).

1) we can't expect a significant memory gain (the numbers are ~90Kb). 
That's a minus.
2) we decouple awt/swing/2d with logging package which is a Plus in a 
view of jigsaw. See 6) for more.
3) we don't have time measures for this change. That's a minus.
4) nobody measured anything else than Framer and SwingSet. That's a minus.
5) we lose flexibility on debugging. That's a minus.
6) this fix don't decouple anything else awt/swing/2d.
I made a grep on "Logger.getLogger" and there are entries from xml, jmx, 
etc. That means we have to deal with them as well too (as it causes the 
class to be loaded anyway), if we aware of jigsaw.
7) In most cases AWT initiates classes statically but basically may want 
to do that lazily. That's minus. I'd consider initialization in CTOR at 
first and see the impact. Believe SwingSet would show enough here. If 
not, that's the reason to go further to... well to check if the Java 
property set.

Now, I don't see the evaluation is completed to make the decision. And 
if we could modify client code in the way that Framer will never 
initialize or/and load Logger (et al) classes so we achieved the goal.

Thanks,
  Andrei

Oleg Sukhodolsky wrote:
> HI Mandy,
>
> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <Mandy.Chung at sun.com> wrote:
>   
>> 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 the logging API is
>> to support maintaining and servicing software at customer sites.   Adding
>> debugging code in the awt implementation using logging API is reasonable but
>> it's not the requirement for the logging API.  If there were a better option
>> to add debugging code, I believe you have no problem changing the awt
>> debugging code not to use the logging API.
>>
>> Server-type applications are typical use cases that logging information is
>> very important and useful for diagnosis in the field - long running apps,
>> hard to reproduce problems until running for many days/months.  It is hard
>> to imagine how the logging information is important in client applications.
>>     
>
> as ex-AWT developer I can confirm that there were number of cases when
> logging had helped us to diagnose problem on client's site.  Even
> though you usually
> do not need to run an application for a long time to reproduce a problem
> it can be very hard to reproduce it because the problem depends on
> window manager
> and other environment which is hard to re-create.
>
>   
>>   But you seem to know many client applications use the logging API that I
>> would also be interested to follow up with their requirements.
>>     
>
> I do not know many client applications which uses logging API (because I have
> never write real client application) and it is hard to say if it uses
> logging or not.
> I hoped that you who saying that suggested changes will help to client
> application
> has some statistic to confirm your expectation
>
>   
>>> Ok, so this fix is only about modules.  But why AWT should not depend
>>> on logging module?
>>> The qiestion is: how many application we want to run doesn't use
>>> logging& Because if an application
>>> uses logging there is no reasons for AWT to not use it.  Please note
>>> that even if logging is turned
>>> off, the application still needs logging package/module.  So, though
>>> end-user doesn't need logging output
>>> she may need logging module to run the application.
>>>       
>> This is exactly why we want to decouple the dependency on logging.  When an
>> application uses logging, the application knows clearly what module they
>> require and that's fine.  When an application doesn't logging, if the awt
>> component requires logging for debugging purpose only, it increases the
>> download size, footprint and startup performance (class lookup time,
>> loading, init, etc) - please see my performance analysis report; otherwise,
>> it's not fruitful to discuss the details in this thread without the
>> background info.  Just to mention it what we care about.
>>     
>
> I have found only two links to some performance analysis:
>
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
> http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64
>
> but they say about -Xverify and -Xshare and do not understand how they
> can be related
> to our topic :(  If they do, please explain (I have never been an
> expert in this area :(
> Or, if I missed something could you please point me what I have missed.
>
>   
>>> So, it is really
>>> important to understand
>>> what number of application will get advantage of suggested changes.
>>>
>>>
>>>       
>> You are suggesting the client applications always have a dependency on
>> logging.   Many client team engineers are happy to see the dependency on
>> logging being eliminated from the client stack requirement and approve this
>> fix :)
>>     
>
> I do not see how this can be considered as prove that the changes will
> help client applications.
> Unless we have some statistic it is all just our guess (which, as we
> know, usually wrong ;)
>
>   
>>> Second question is: how big logging module is going to be? How big the
>>> benefit for end-user will be?
>>>
>>>
>>>       
>> The size of the logging API is not big (~90K) but the size is not the only
>> one factor determining what benefit the end-user will have.
>>     
>
> what other factors do you know?
>
>   
>>  It's not
>> necessary to logging API as one single module and details are to be worked
>> out.   Subscribe to the jigsaw project to follow the discussion and progress
>> there.   Serviceability includes other API as well.  If awt started using
>> other serviceability API (java.lang.management, java.lang.instrument) for
>> whatever reason, your argument would apply there as well.  I don't think you
>> wanted the awt module depends on all the serviceability APIs.
>>     
>
> I agree that usage of any API should be done after careful consideration.
> Logging API provides us exactly what we need (ability to create log of
> an application
> executed on client)  this is why we started to use it.
>
>   
>>> I'm asking so many question mainly because the changes you suggested
>>> create rather unnatural code (we can not
>>> use standard logging machinery any more), so such changes should be
>>> well-justified.
>>>
>>>
>>>       
>> That's what we pay for to modularize the JDK after many years of JDK
>> development without module support in the platform.  Otherwise, if there
>> were module support in the platform, you would consider very carefully when
>> adding a dependency on another module.
>>     
>
> perhaps you are right, but in case of logging I would expect that we'd use it
> anyway.
>
> Oleg.
>
>   
>> If you have further issue, I suggest to start a different thread on the
>> awt-dev alias.
>>
>> Thanks
>> Mandy
>> [1] http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
>>
>>     


From yuri.nesterenko at sun.com  Tue Sep 22 03:46:02 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Tue, 22 Sep 2009 10:46:02 +0000
Subject: <AWT Dev> hg: jdk7/awt: 6 new changesets
Message-ID: <20090922104602.619CF12726@hg.openjdk.java.net>

Changeset: d8b49b53d8cf
Author:    wetmore
Date:      2009-08-14 17:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/rev/d8b49b53d8cf

6872177: JCE framework and provider builds broken following -target 7 changes
Reviewed-by: ohair

! make/Defs-internal.gmk

Changeset: 4c36e9853dda
Author:    tbell
Date:      2009-08-24 22:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/rev/4c36e9853dda

Merge


Changeset: 378f57273f09
Author:    xdono
Date:      2009-09-03 10:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/rev/378f57273f09

Added tag jdk7-b71 for changeset 4c36e9853dda

! .hgtags

Changeset: 4079d923a501
Author:    peterz
Date:      2009-08-31 14:10 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/rev/4079d923a501

6844267: Nimbus generator depends on JIBX
Summary: Nimbus generator now uses JAXB instead of JIBX
Reviewed-by: jasper

! README-builds.html

Changeset: 0d7e03b426df
Author:    yan
Date:      2009-09-09 00:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/rev/0d7e03b426df

Merge


Changeset: 4c4fe09fb670
Author:    xdono
Date:      2009-09-17 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/rev/4c4fe09fb670

Added tag jdk7-b72 for changeset 0d7e03b426df

! .hgtags


From yuri.nesterenko at sun.com  Tue Sep 22 03:46:36 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Tue, 22 Sep 2009 10:46:36 +0000
Subject: <AWT Dev> hg: jdk7/awt/corba: 5 new changesets
Message-ID: <20090922104641.086991272B@hg.openjdk.java.net>

Changeset: 8001ba2bf10d
Author:    andrew
Date:      2009-08-20 01:28 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/corba/rev/8001ba2bf10d

6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk javac
Summary: The bootstrap javac currently uses the default source and targets of the boot javac
Reviewed-by: jjg, ohair

! make/common/shared/Defs-java.gmk

Changeset: 04414f276160
Author:    xdono
Date:      2009-08-24 17:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/corba/rev/04414f276160

Merge


Changeset: 3f1ef7f899ea
Author:    andrew
Date:      2009-09-01 23:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/corba/rev/3f1ef7f899ea

6878106: Synchronize CORBA and JDK makefiles where possible
Summary: Add recent changes to the JDK makefile to the CORBA makefile
Reviewed-by: jjg, never

! make/common/shared/Defs-java.gmk

Changeset: c793a3120926
Author:    xdono
Date:      2009-09-03 10:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/corba/rev/c793a3120926

Added tag jdk7-b71 for changeset 3f1ef7f899ea

! .hgtags

Changeset: 12991b453239
Author:    xdono
Date:      2009-09-17 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/corba/rev/12991b453239

Added tag jdk7-b72 for changeset c793a3120926

! .hgtags


From yuri.nesterenko at sun.com  Tue Sep 22 03:48:59 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Tue, 22 Sep 2009 10:48:59 +0000
Subject: <AWT Dev> hg: jdk7/awt/hotspot: 74 new changesets
Message-ID: <20090922105120.1D2F112738@hg.openjdk.java.net>

Changeset: f753dffae23e
Author:    trims
Date:      2009-08-13 17:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/f753dffae23e

6871765: Bump the HS16 build number to 08
Summary: Update the HS16 build number to 08
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 6a93908f268f
Author:    mchung
Date:      2009-07-10 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/6a93908f268f

6857194: Add hotspot perf counters to aid class loading performance measurement
Summary: Add new jvmstat counters to measure detailed class loading time
Reviewed-by: acorn, kamg

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/classLoader.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/includeDB_core
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/perfData.hpp
! src/share/vm/services/threadService.cpp
! src/share/vm/services/threadService.hpp

Changeset: 1413494da700
Author:    martin
Date:      2009-06-29 14:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/1413494da700

6850957: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit
Summary: call report_java_out_of_memory("Requested array size exceeds VM limit")
Reviewed-by: tbell, dholmes, alanb, ysr
Contributed-by: jeremymanson at google.com

! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp

Changeset: 8c79517a9300
Author:    poonam
Date:      2009-07-16 18:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/8c79517a9300

6840305: Discrepancy in system memory details (when 4G or greater) reported by JVM and Windows OS
Summary: GlobalMemoryStatus() does not report correct memory usage when the system has more than 4gb of RAM. GlobalMemoryStatusEx() should be used in place of GlobalMemoryStatus().
Reviewed-by: kamg, coleenp

! src/os/windows/vm/os_windows.cpp

Changeset: abe076e3636f
Author:    mchung
Date:      2009-07-27 09:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/abe076e3636f

6864003: Modify JVM_FindClassFromBootLoader to return null if class not found
Summary: JVM_FindClassFromBootLoader returns null if class not found
Reviewed-by: acorn, alanb, dholmes

! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h

Changeset: 494244ae0171
Author:    coleenp
Date:      2009-07-27 17:23 -0400
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/494244ae0171

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/includeDB_core
! src/share/vm/oops/objArrayKlass.cpp

Changeset: 2b4230d1e589
Author:    dcubed
Date:      2009-07-28 13:35 -0600
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/2b4230d1e589

6862295: JDWP threadid changes during debugging session (leading to ingored breakpoints)
Summary: Correctly count full GC operations for framework collectors. Add ForceFullGCJVMTIEpilogues as a future work around if needed.
Reviewed-by: jcoomes, alanb, ysr

! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 16c930df1e9b
Author:    dcubed
Date:      2009-07-28 13:50 -0600
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/16c930df1e9b

Merge

! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 66b0f834a440
Author:    coleenp
Date:      2009-07-30 15:06 -0400
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/66b0f834a440

Merge

! src/share/vm/classfile/classLoader.cpp

Changeset: 27f6a9b9c311
Author:    tonyp
Date:      2009-07-29 11:01 -0400
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/27f6a9b9c311

6864886: G1: rename -XX parameters related to update buffers
Summary: renaming a couple of update buffer-related parameters to make them more understandable and consistent.
Reviewed-by: iveresov, ysr

! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 83b687ce3090
Author:    tonyp
Date:      2009-07-30 14:50 -0400
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/83b687ce3090

6866591: G1: print update buffer processing stats more often
Summary: It adds parameter -XX:+G1SummarizeRSetStatsPeriod that causes update buffer processing information to be printed periodically. It also includes two small formatting changes.
Reviewed-by: jmasa, jcoomes, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 7f807f55161a
Author:    ysr
Date:      2009-07-31 10:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/7f807f55161a

Merge

! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 061cd4d965fc
Author:    jmasa
Date:      2009-08-02 18:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/061cd4d965fc

6862534: -XX:NewRatio completely ignored when combined with -XX:+UseConcMarkSweepG
Summary: Use NewRatio if it is explicitly set.
Reviewed-by: ysr, jcoomes

! src/share/vm/runtime/arguments.cpp

Changeset: ff004bcd2596
Author:    jmasa
Date:      2009-08-02 19:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/ff004bcd2596

6843292: "Expect to be beyond new region unless impacting another region" assertion too strong
Summary: In the assertion allow for collision with the guard page.
Reviewed-by: tonyp, ysr, jcoomes

! src/share/vm/memory/cardTableModRefBS.cpp

Changeset: 59726d16b30d
Author:    jmasa
Date:      2009-08-02 22:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/59726d16b30d

Merge


Changeset: 15c5903cf9e1
Author:    johnc
Date:      2009-08-03 12:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/15c5903cf9e1

6865703: G1: Parallelize hot card cache cleanup
Summary: Have the GC worker threads clear the hot card cache in parallel by having each worker thread claim a chunk of the card cache and process the cards in that chunk. The size of the chunks that each thread will claim is determined at VM initialization from the size of the card cache and the number of worker threads.
Reviewed-by: jmasa, tonyp

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 6cb8e9df7174
Author:    johnc
Date:      2009-08-04 16:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/6cb8e9df7174

6819077: G1: first GC thread coming late into the GC.
Summary: The first worker thread is delayed when entering the GC because it clears the card count table that is used in identifying hot cards. Replace the card count table with a dynamically sized evicting hash table that includes an epoch based counter.
Reviewed-by: iveresov, tonyp

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/includeDB_gc_g1

Changeset: 703065c670fa
Author:    ysr
Date:      2009-08-05 18:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/703065c670fa

6868991: JPRT: elide GCBasher_G1 test on winx64 until 6867250 is resolved
Summary: JPRT: elide GCBasher_G1 test on winx64 until 6867250 is resolved
Reviewed-by: jcoomes

! make/jprt.properties

Changeset: a94af87c3357
Author:    never
Date:      2009-07-24 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/a94af87c3357

6861984: solaris version of libsaproc.so should support SA_ALTROOT directly
Reviewed-by: kvn, twisti

! agent/make/saenv.sh
! agent/make/saenv64.sh
! agent/src/os/solaris/proc/Makefile
! agent/src/os/solaris/proc/mapfile
! agent/src/os/solaris/proc/saproc.cpp
+ agent/src/os/solaris/proc/saproc_audit.cpp

Changeset: dd0a4e1e219b
Author:    kvn
Date:      2009-07-26 12:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/dd0a4e1e219b

6851386: assert(b->find_node(def) < j,"uses must follow definitions")
Summary: Add additional check for a tight loop.
Reviewed-by: never

! src/share/vm/opto/block.cpp

Changeset: 665be97e8704
Author:    kvn
Date:      2009-07-26 16:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/665be97e8704

6863420: os::javaTimeNanos() go backward on Solaris x86
Summary: Use new atomic long load method Atomic::load() to load max_hrtime.
Reviewed-by: never, ysr, johnc, phh, dcubed, acorn

! src/os/solaris/vm/os_solaris.cpp
! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp
! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/solaris_x86_32.il
! src/share/vm/runtime/atomic.hpp
+ test/compiler/6863420/Test.java

Changeset: 94b6d06fd759
Author:    twisti
Date:      2009-07-20 08:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/94b6d06fd759

6860920: serialize.cpp shouldn't use objArrayOopDesc::base_offset_in_bytes(T_BYTE)
Summary: serialize.cpp currently uses objArrayOopDesc::base_offset_in_bytes(T_BYTE), which seems to be wrong.
Reviewed-by: coleenp, kvn

! src/share/vm/memory/serialize.cpp
! src/share/vm/oops/objArrayOop.hpp
! src/share/vm/opto/library_call.cpp

Changeset: 1cef5ec3ca56
Author:    twisti
Date:      2009-07-27 06:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/1cef5ec3ca56

Merge

! src/share/vm/opto/library_call.cpp

Changeset: 52898b0c43e9
Author:    twisti
Date:      2009-07-28 09:02 +0200
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/52898b0c43e9

6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask)
Summary: Code compiled with server compiler generates an incorrect result.
Reviewed-by: cfang, never, kvn

! src/share/vm/opto/mulnode.cpp
+ test/compiler/6863155/Test6863155.java

Changeset: 60fea60a6db5
Author:    kvn
Date:      2009-07-30 16:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/60fea60a6db5

6864914: SPECjvm2008 produces invalid result with zero based Compressed Oops
Summary: Always use "lea" instruction for narrow oop decoding instead of "shift".
Reviewed-by: never

! src/cpu/x86/vm/assembler_x86.cpp

Changeset: 55cb84cd1247
Author:    kvn
Date:      2009-07-31 12:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/55cb84cd1247

6865031: Application gives bad result (throws bad exception) with compressed oops
Summary: Produce narrow type for new Phi from the original Phi type.
Reviewed-by: cfang

! src/share/vm/opto/cfgnode.cpp
+ test/compiler/6865031/Test.java

Changeset: 9987d9d5eb0e
Author:    cfang
Date:      2009-07-31 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/9987d9d5eb0e

6833129: specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot
Summary: developed a reexecute logic for the interpreter to reexecute the bytecode when deopt happens
Reviewed-by: kvn, never, jrose, twisti

! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_IR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/code/debugInfo.hpp
! src/share/vm/code/debugInfoRec.cpp
! src/share/vm/code/debugInfoRec.hpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/code/scopeDesc.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/interpreter/templateInterpreter.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/vframe.hpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vframeArray.hpp
! src/share/vm/runtime/vframe_hp.cpp
! src/share/vm/runtime/vframe_hp.hpp
+ test/compiler/6833129/Test.java

Changeset: 2b9164d13ce9
Author:    kvn
Date:      2009-08-04 17:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/2b9164d13ce9

6868486: timouts and outOfMemory in regression tests
Summary: Increase timeout for tests and heap size for 6851282 test.
Reviewed-by: never, cfang

! test/compiler/6826736/Test.java
! test/compiler/6851282/Test.java

Changeset: fc2281ddce3c
Author:    cfang
Date:      2009-08-04 21:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/fc2281ddce3c

6868269: CompileTheWorld assertion failure introduced by the reexecute bit implementation
Summary: Improvement on reexecute implementation to fix the assertion failure
Reviewed-by: kvn, never

! src/share/vm/opto/library_call.cpp

Changeset: 15bbd3f505c0
Author:    kvn
Date:      2009-08-06 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/15bbd3f505c0

Merge

! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/vframe.hpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vframe_hp.cpp

Changeset: ef671fb22f73
Author:    never
Date:      2009-08-06 12:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/ef671fb22f73

6868051: (SA) FreeChunk support for compressed oops is broken
Reviewed-by: kvn, dcubed

! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java
! agent/src/share/classes/sun/jvm/hotspot/memory/FreeChunk.java

Changeset: bd2b1f617a4e
Author:    jrose
Date:      2009-08-06 14:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/bd2b1f617a4e

6868487: EnableInvokeDynamic and EnableMethodHandles should not be visible flags in JDK6 or JDK7
Summary: switch them from product to experimental; 6817525 will toggle them and switch to diagnostic
Reviewed-by: kvn

! src/share/vm/runtime/globals.hpp

Changeset: 9c65a08a31a3
Author:    jrose
Date:      2009-08-06 16:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/9c65a08a31a3

Merge


Changeset: 3ee342e25e57
Author:    jcoomes
Date:      2009-08-05 12:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/3ee342e25e57

6821693: 64-bit TaskQueue capacity still too small
6821507: Alignment problem in GC taskqueue
Reviewed-by: tonyp, apetrusenko

! src/share/vm/utilities/taskqueue.hpp

Changeset: b1773b9a2ca1
Author:    ysr
Date:      2009-08-09 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/b1773b9a2ca1

Merge


Changeset: b32a809aab08
Author:    jcoomes
Date:      2009-08-11 23:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/b32a809aab08

6866585: debug code in ciObjectFactory too slow for large objects
Reviewed-by: ysr, never, kvn

! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 10d8c0d0d60e
Author:    jcoomes
Date:      2009-08-12 14:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/10d8c0d0d60e

6867645: java -Xshare:dump failed - read only space too small
Reviewed-by: iveresov, tonyp, ysr

! src/share/vm/runtime/globals.hpp

Changeset: 16314a31b961
Author:    trims
Date:      2009-08-13 17:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/16314a31b961

Merge


Changeset: 308762b2bf14
Author:    apetrusenko
Date:      2009-08-14 13:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/308762b2bf14

6872000: G1: compilation fails on linux/older gcc
Reviewed-by: jcoomes, tonyp

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: ac59d4e6dae5
Author:    trims
Date:      2009-08-14 17:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/ac59d4e6dae5

Merge


Changeset: 50a95aa4a247
Author:    trims
Date:      2009-08-21 20:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/50a95aa4a247

Merge


Changeset: 6e6427f797c0
Author:    xdono
Date:      2009-09-03 10:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/6e6427f797c0

Added tag jdk7-b71 for changeset 50a95aa4a247

! .hgtags

Changeset: a05ea7791ee3
Author:    trims
Date:      2009-08-21 20:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/a05ea7791ee3

6873236: Fork HS16 to HS17 - renumber Major and build numbers of JVM
Summary: Update the Major and build numbers for HS17 fork
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1760a1cbed36
Author:    dcubed
Date:      2009-08-11 11:57 -0600
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/1760a1cbed36

6862945: 4/3 conversion of jmethodID to methodOop in JVMTI is too expensive
Summary: Refactor JNIHandles::checked_resolve_jmethod_id() into fast and paranoid parts.
Reviewed-by: never, alanb

! src/share/vm/prims/jniCheck.cpp
! src/share/vm/runtime/jniHandles.hpp

Changeset: 6ab1d6ece8bd
Author:    apangin
Date:      2009-08-17 15:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/6ab1d6ece8bd

Merge


Changeset: 585222cadf79
Author:    apangin
Date:      2009-08-19 15:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/585222cadf79

Merge


Changeset: a774e1abbe85
Author:    trims
Date:      2009-08-21 20:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/a774e1abbe85

Merge


Changeset: 046932b72aa2
Author:    never
Date:      2009-08-14 00:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/046932b72aa2

6862956: PhaseIdealLoop should have a CFG verification mode
Reviewed-by: kvn, twisti

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/phase.cpp
! src/share/vm/opto/phase.hpp

Changeset: 1a81ea4b45d4
Author:    kvn
Date:      2009-08-14 12:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/1a81ea4b45d4

6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop")
Summary: Replace the assert with narrow_oop_shift set to 0.
Reviewed-by: never, jcoomes

! src/share/vm/memory/universe.cpp

Changeset: a70508bb21c3
Author:    never
Date:      2009-08-14 15:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/a70508bb21c3

6862863: C2 compiler fails in elide_copy()
Reviewed-by: kvn

! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/postaloc.cpp

Changeset: 55784fd95fe3
Author:    never
Date:      2009-08-14 15:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/55784fd95fe3

Merge


Changeset: 7c14587118b3
Author:    never
Date:      2009-08-14 22:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/7c14587118b3

Merge


Changeset: c8e2135f7e30
Author:    cfang
Date:      2009-08-17 09:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/c8e2135f7e30

6829127: Deoptimization Failure on Specjvm98 _227_mtrt with -XX:+DeoptimizeALot since Hs11 b01
Summary: Make sure the control word is correct in deopt_blob after restore_result_registers
Reviewed-by: kvn, never

! src/cpu/x86/vm/sharedRuntime_x86_32.cpp

Changeset: 662f330d7275
Author:    cfang
Date:      2009-08-17 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/662f330d7275

6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59)
Summary: delay dead code elimination in set_req_X to make it safe
Reviewed-by: kvn, never

! src/share/vm/opto/phaseX.cpp
+ test/compiler/6866651/Test.java

Changeset: d0acbc302e14
Author:    never
Date:      2009-08-17 14:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/d0acbc302e14

6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc
Reviewed-by: twisti, cfang

! src/cpu/sparc/vm/c1_Defs_sparc.hpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/share/vm/includeDB_compiler1
+ test/compiler/6795465/Test6795465.java

Changeset: cd18bd5e667c
Author:    never
Date:      2009-08-19 18:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/cd18bd5e667c

6873777: FPU control word optimization still performed with SSE
Reviewed-by: kvn

! src/share/vm/opto/compile.cpp

Changeset: 357d4e2eb4dd
Author:    kvn
Date:      2009-08-19 19:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/357d4e2eb4dd

6873799: enable escape analysis by default
Summary: enable escape analysis by default
Reviewed-by: never

! src/share/vm/opto/c2_globals.hpp

Changeset: 72088be4b386
Author:    cfang
Date:      2009-08-20 12:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/72088be4b386

6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit
Summary: use PcDesc to keep record of the reexecute bit instead of using DebugInfoStreams
Reviewed-by: kvn, never, twisti

! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java
! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/code/debugInfo.hpp
! src/share/vm/code/debugInfoRec.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/pcDesc.cpp
! src/share/vm/code/pcDesc.hpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/code/scopeDesc.hpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/prims/jvmtiCodeBlobEvents.cpp
! src/share/vm/runtime/vframe.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 82bd76d4d7f2
Author:    kvn
Date:      2009-08-24 11:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/82bd76d4d7f2

6873800: enable compressed oops by default
Summary: enable compressed oops by default
Reviewed-by: never, ysr

! src/share/vm/runtime/arguments.cpp

Changeset: cdb8b7c37ac1
Author:    never
Date:      2009-08-24 22:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/cdb8b7c37ac1

6875329: fix for 6795465 broke exception handler cloning
Reviewed-by: kvn

! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp

Changeset: aba04734b61e
Author:    kvn
Date:      2009-08-25 13:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/aba04734b61e

Merge


Changeset: 05f89f00a864
Author:    jmasa
Date:      2009-08-24 10:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/05f89f00a864

6798898: CMS: bugs related to class unloading
Summary: Override should_remember_klasses() and remember_klass() as needed.
Reviewed-by: ysr, jcoomes

! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
! src/share/vm/memory/iterator.cpp
! src/share/vm/memory/iterator.hpp
! src/share/vm/memory/referenceProcessor.cpp

Changeset: e1fdf4fd34dc
Author:    tonyp
Date:      2009-08-19 12:53 -0400
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/e1fdf4fd34dc

6871111: G1: remove the concurrent overhead tracker
Summary: Removing the concurrent overhead tracker from G1, along with the GC overhead reporter and the G1AccountConcurrentOverhead (both of which rely on the the concurrent overhead tracker).
Reviewed-by: iveresov, johnc

! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp
! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp
! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp
! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/includeDB_gc_g1
! src/share/vm/gc_implementation/includeDB_gc_shared
- src/share/vm/gc_implementation/shared/coTracker.cpp
- src/share/vm/gc_implementation/shared/coTracker.hpp
- src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp
- src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp

Changeset: ead53f6b615d
Author:    tonyp
Date:      2009-08-24 13:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/ead53f6b615d

Merge

- src/share/vm/gc_implementation/shared/coTracker.cpp
- src/share/vm/gc_implementation/shared/coTracker.hpp
- src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp
- src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp

Changeset: b37c246bf7ce
Author:    jcoomes
Date:      2009-08-11 15:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/b37c246bf7ce

6861660: OopMapBlock count/size confusion
Reviewed-by: tonyp, iveresov

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/memory/oopFactory.cpp
! src/share/vm/memory/oopFactory.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/oops/instanceKlassKlass.hpp
! src/share/vm/oops/instanceRefKlass.cpp

Changeset: 9eebd3ac74cf
Author:    jcoomes
Date:      2009-08-13 16:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/9eebd3ac74cf

6845368: large objects cause a crash or unexpected exception
Reviewed-by: jmasa, iveresov

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/memory/oopFactory.cpp
! src/share/vm/memory/oopFactory.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/oops/instanceKlassKlass.hpp
! src/share/vm/oops/instanceRefKlass.cpp
+ test/gc/6845368/bigobj.java

Changeset: 8624da129f0b
Author:    apetrusenko
Date:      2009-08-31 05:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/8624da129f0b

6841313: G1: dirty cards of survivor regions in parallel
Reviewed-by: tonyp, iveresov

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp

Changeset: 8b46c4d82093
Author:    ysr
Date:      2009-09-02 00:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/8b46c4d82093

4957990: Perm heap bloat in JVM
Summary: Treat ProfileData in MDO's as a source of weak, not strong, roots. Fixes the bug for stop-world collection -- the case of concurrent collection will be fixed separately.
Reviewed-by: jcoomes, jmasa, kvn, never

! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge
! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_implementation/shared/markSweep.cpp
! src/share/vm/gc_implementation/shared/markSweep.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/includeDB_core
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/iterator.hpp
! src/share/vm/oops/methodDataOop.cpp
! src/share/vm/oops/methodDataOop.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sweeper.cpp

Changeset: 2c79770d1f6e
Author:    tonyp
Date:      2009-07-30 16:22 -0400
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/2c79770d1f6e

6819085: G1: use larger and/or user settable region size
Summary: Instead of the region size being hard-coded, allow the user to set it.
Reviewed-by: jmasa, johnc, apetrusenko

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.hpp
! src/share/vm/gc_implementation/includeDB_gc_g1

Changeset: b1606b3c0a8a
Author:    apetrusenko
Date:      2009-09-04 05:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/b1606b3c0a8a

Merge

! src/share/vm/code/nmethod.cpp
- src/share/vm/gc_implementation/shared/coTracker.cpp
- src/share/vm/gc_implementation/shared/coTracker.hpp
- src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp
- src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp

Changeset: b1f5ced5da21
Author:    jcoomes
Date:      2009-09-03 19:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/b1f5ced5da21

6879076: disable jprt sync after builds are done
Reviewed-by: kamg, dholmes

! make/jprt.properties

Changeset: 68ef3fdcdb76
Author:    ysr
Date:      2009-09-10 16:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/68ef3fdcdb76

6872136: CMS: confusing message may be printed when a collector is switched off implicitly
Summary: Fix CDS/CMS option overrides related to iCMS option CMSIncrementalMode; explicate overrides to error stream.
Reviewed-by: coleenp

! src/share/vm/runtime/arguments.cpp

Changeset: a94714c55065
Author:    trims
Date:      2009-09-15 20:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/a94714c55065

Merge


Changeset: 1e5f0e56d242
Author:    xdono
Date:      2009-09-17 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/1e5f0e56d242

Added tag jdk7-b72 for changeset a94714c55065

! .hgtags


From yuri.nesterenko at sun.com  Tue Sep 22 03:57:38 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Tue, 22 Sep 2009 10:57:38 +0000
Subject: <AWT Dev> hg: jdk7/awt/jaxp: 2 new changesets
Message-ID: <20090922105742.5D5711273E@hg.openjdk.java.net>

Changeset: 37c805b6156f
Author:    xdono
Date:      2009-09-03 10:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxp/rev/37c805b6156f

Added tag jdk7-b71 for changeset ff94d8ce0dad

! .hgtags

Changeset: 93dfa6e0fe76
Author:    xdono
Date:      2009-09-17 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxp/rev/93dfa6e0fe76

Added tag jdk7-b72 for changeset 37c805b6156f

! .hgtags


From yuri.nesterenko at sun.com  Tue Sep 22 03:58:15 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Tue, 22 Sep 2009 10:58:15 +0000
Subject: <AWT Dev> hg: jdk7/awt/jaxws: 2 new changesets
Message-ID: <20090922105819.8B2BD12744@hg.openjdk.java.net>

Changeset: 4c990aa99bc0
Author:    xdono
Date:      2009-09-03 10:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxws/rev/4c990aa99bc0

Added tag jdk7-b71 for changeset 03314cf56a72

! .hgtags

Changeset: d79f0d601c2b
Author:    xdono
Date:      2009-09-17 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxws/rev/d79f0d601c2b

Added tag jdk7-b72 for changeset 4c990aa99bc0

! .hgtags


From yuri.nesterenko at sun.com  Tue Sep 22 04:01:27 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Tue, 22 Sep 2009 11:01:27 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 75 new changesets
Message-ID: <20090922111657.09C901274F@hg.openjdk.java.net>

Changeset: 1ff977b938e5
Author:    sherman
Date:      2009-08-13 10:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/1ff977b938e5

6840246: Lightweight implementation of String.split for simple use case
Summary: Added a fastpath for simple use case
Reviewed-by: alanb, martin

! src/share/classes/java/lang/String.java
! test/java/lang/String/Split.java

Changeset: 8c0c96a3f9f6
Author:    wetmore
Date:      2009-08-13 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/8c0c96a3f9f6

6870335: Provider numbers need to be bumped to 1.7
Reviewed-by: mullan

! src/share/classes/com/sun/security/sasl/Provider.java
! src/share/classes/sun/security/jgss/SunProvider.java
! src/share/classes/sun/security/provider/Sun.java
! src/share/classes/sun/security/smartcardio/SunPCSC.java
! src/share/classes/sun/security/ssl/SunJSSE.java

Changeset: 6797a2407a50
Author:    wetmore
Date:      2009-08-13 12:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/6797a2407a50

Merge


Changeset: 35f32639ee20
Author:    sherman
Date:      2009-08-13 15:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/35f32639ee20

6676423: (prefs) Opensource unit/regression tests for java.util.prefs
Summary: Moved the existing test cases for prefs to open area
Reviewed-by: martin, alanb

+ test/java/util/prefs/CommentsInXml.java
+ test/java/util/prefs/ConflictInFlush.java
+ test/java/util/prefs/ExportNode.java
+ test/java/util/prefs/ExportSubtree.java
+ test/java/util/prefs/PrefsSpi.java
+ test/java/util/prefs/PrefsSpi.sh
+ test/java/util/prefs/RemoveReadOnlyNode.java
+ test/java/util/prefs/RemoveUnregedListener.java
+ test/java/util/prefs/SerializeExceptions.java

Changeset: f094eb92a6e0
Author:    sherman
Date:      2009-08-13 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/f094eb92a6e0

Merge


Changeset: 7fcdefc99dc4
Author:    sherman
Date:      2009-08-14 11:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/7fcdefc99dc4

6866397: (file) PathMatcher with regex syntax doesn't match as expected (win)
Summary: Use unicode_case_insensitive for windows path matcher for now.
Reviewed-by: alanb

! src/windows/classes/sun/nio/fs/WindowsFileSystem.java
! test/java/nio/file/PathMatcher/Basic.java

Changeset: 77a1c2056565
Author:    sherman
Date:      2009-08-14 14:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/77a1c2056565

6730652: CharsetEncoder.canEncode(char) returns incorrect values for some charsets
Summary: override the canEncode() in ISO2022_CN_CNS
Reviewed-by: martin

! src/share/classes/sun/nio/cs/ext/ISO2022.java
! src/share/classes/sun/nio/cs/ext/ISO2022_CN_CNS.java
! test/sun/nio/cs/FindCanEncodeBugs.java

Changeset: 8414927b41d8
Author:    weijun
Date:      2009-08-18 10:20 +0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/8414927b41d8

6829785: TextCallbackHandler does not honor PasswordCallback.isEchoOn()
Reviewed-by: mullan

! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java
! src/share/classes/sun/security/util/Password.java
+ test/com/sun/security/auth/callback/TextCallbackHandler/Password.java

Changeset: 74029d1cf4e4
Author:    tbell
Date:      2009-08-18 17:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/74029d1cf4e4

Merge


Changeset: 5e8986cabdd8
Author:    weijun
Date:      2009-08-20 11:24 +0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/5e8986cabdd8

6867665: Problem with keytabs with multiple kvno's (key versions)
Reviewed-by: valeriep, ohair

! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
+ test/sun/security/krb5/ktab/HighestKvno.java

Changeset: dfece53c600f
Author:    alanb
Date:      2009-08-20 08:39 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/dfece53c600f

6595866: File does work with symbolic links (win,vista)
Reviewed-by: sherman

! src/windows/native/java/io/WinNTFileSystem_md.c
+ test/java/io/File/SymLinks.java

Changeset: 70c03e494a68
Author:    alanb
Date:      2009-08-20 08:42 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/70c03e494a68

6870926: (file) Path.toRealPath performance can be improved (win)
Reviewed-by: sherman

! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java
! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java
! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java
! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c

Changeset: 5cd12b68d09b
Author:    alanb
Date:      2009-08-20 08:48 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/5cd12b68d09b

6866804: (file) Path calls checkPermission insteadof checkXXX (sol)
Reviewed-by: sherman

! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java
+ test/java/nio/file/Path/CheckPermissions.java
! test/java/nio/file/Path/Misc.java

Changeset: 3992a43bb0a5
Author:    darcy
Date:      2009-08-21 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3992a43bb0a5

6378701: (enum) Unclear purpose of EnumConstantNotPresentException
Reviewed-by: lancea, andrew, alanb

! src/share/classes/java/lang/EnumConstantNotPresentException.java
! src/share/classes/java/lang/TypeNotPresentException.java
! src/share/classes/java/lang/annotation/AnnotationFormatError.java
! src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java
! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java

Changeset: 99a55f6f1cef
Author:    alanb
Date:      2009-08-22 17:40 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/99a55f6f1cef

6874521: Remove @note tags
Reviewed-by: andrew, darcy

! src/share/classes/java/nio/channels/Channels.java
! src/share/classes/java/nio/channels/FileChannel.java
! src/share/classes/java/nio/channels/FileLock.java
! src/share/classes/java/nio/channels/package-info.java
! src/share/classes/java/nio/file/FileRef.java
! src/share/classes/java/util/Scanner.java

Changeset: cef30252932a
Author:    alanb
Date:      2009-08-23 12:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/cef30252932a

6842687: New I/O: Update Asynchronous I/O API to jsr203/nio2-b101
Reviewed-by: sherman

! make/java/nio/FILES_java.gmk
! src/share/classes/java/nio/channels/AsynchronousByteChannel.java
! src/share/classes/java/nio/channels/AsynchronousChannel.java
! src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java
! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java
! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java
! src/share/classes/java/nio/channels/CompletionHandler.java
! src/share/classes/java/nio/channels/exceptions
- src/share/classes/sun/nio/ch/AbstractFuture.java
! src/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java
! src/share/classes/sun/nio/ch/AsynchronousFileChannelImpl.java
! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java
! src/share/classes/sun/nio/ch/CompletedFuture.java
! src/share/classes/sun/nio/ch/Invoker.java
! src/share/classes/sun/nio/ch/PendingFuture.java
! src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java
! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java
! src/solaris/classes/sun/nio/ch/EPollPort.java
! src/solaris/classes/sun/nio/ch/Port.java
! src/solaris/classes/sun/nio/ch/SolarisEventPort.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/Iocp.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
! src/windows/native/sun/nio/ch/Iocp.c
! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
! test/java/nio/channels/AsynchronousChannelGroup/Identity.java
! test/java/nio/channels/AsynchronousChannelGroup/Restart.java
! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java
! test/java/nio/channels/AsynchronousDatagramChannel/Basic.java
! test/java/nio/channels/AsynchronousFileChannel/Basic.java
! test/java/nio/channels/AsynchronousFileChannel/CustomThreadPool.java
! test/java/nio/channels/AsynchronousFileChannel/Lock.java
! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java
! test/java/nio/channels/AsynchronousSocketChannel/Basic.java
+ test/java/nio/channels/AsynchronousSocketChannel/DieBeforeComplete.java
! test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
! test/java/nio/channels/FileChannel/ReleaseOnCloseDeadlock.java

Changeset: fca3e1a178fd
Author:    alanb
Date:      2009-08-23 17:20 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/fca3e1a178fd

Merge


Changeset: dbcc1f13e4fd
Author:    weijun
Date:      2009-08-24 18:37 +0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/dbcc1f13e4fd

6875033: regression: test of 6867665 fail
Reviewed-by: xuelei

! test/sun/security/krb5/ktab/HighestKvno.java

Changeset: d954cd279188
Author:    ohair
Date:      2009-08-24 09:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/d954cd279188

6853636: Fix warnings in jdwpgen, add jdwpgen NetBeans project
Reviewed-by: andrew, alanb, tbell, swamyv

! .hgignore
+ make/netbeans/jdwpgen/build.xml
+ make/netbeans/jdwpgen/nbproject/build-impl.xml
+ make/netbeans/jdwpgen/nbproject/findbugs.settings
+ make/netbeans/jdwpgen/nbproject/genfiles.properties
+ make/netbeans/jdwpgen/nbproject/project.properties
+ make/netbeans/jdwpgen/nbproject/project.xml
+ make/netbeans/jdwpgen/nbproject/sqe.properties
! make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java
! make/tools/src/build/tools/jdwpgen/AltNode.java
! make/tools/src/build/tools/jdwpgen/ConstantSetNode.java
! make/tools/src/build/tools/jdwpgen/Main.java
! make/tools/src/build/tools/jdwpgen/Node.java
! make/tools/src/build/tools/jdwpgen/Parse.java
! make/tools/src/build/tools/jdwpgen/RepeatNode.java
! make/tools/src/build/tools/jdwpgen/SelectNode.java

Changeset: dd997cc0c823
Author:    vinnie
Date:      2009-08-24 18:37 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/dd997cc0c823

6872048: bad private keys are generated for 2 specific ECC curves
Reviewed-by: wetmore

! src/share/native/sun/security/ec/ec.c
! test/sun/security/ec/TestEC.java

Changeset: b71a03c75515
Author:    tbell
Date:      2009-08-24 22:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b71a03c75515

Merge

- src/share/classes/sun/nio/ch/AbstractFuture.java

Changeset: 80368890a2a0
Author:    andrew
Date:      2009-08-18 19:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/80368890a2a0

6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk javac
Summary: The bootstrap javac currently uses the default source and targets of the boot javac
Reviewed-by: ohair

! make/common/shared/Defs-java.gmk

Changeset: 43465920bf47
Author:    xdono
Date:      2009-08-18 19:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/43465920bf47

Merge

- test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java
- test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java

Changeset: b3aac0db5586
Author:    tbell
Date:      2009-08-21 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b3aac0db5586

6705913: freetype_versioncheck.exe - Unable To Locate Component
Summary: Update freetype_versioncheck to deal with newer Visual Studio releases
Reviewed-by: ohair

! make/tools/freetypecheck/Makefile
! make/tools/freetypecheck/freetypecheck.c

Changeset: e0b26d347302
Author:    xdono
Date:      2009-08-24 17:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e0b26d347302

Merge


Changeset: b3f3240135f0
Author:    xdono
Date:      2009-09-01 13:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b3f3240135f0

Merge

- src/share/classes/sun/nio/ch/AbstractFuture.java

Changeset: ce3fde68c495
Author:    xdono
Date:      2009-09-03 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/ce3fde68c495

Added tag jdk7-b71 for changeset b3f3240135f0

! .hgtags

Changeset: b115cf946852
Author:    sherman
Date:      2009-08-25 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b115cf946852

4963968: zlib should be upgraded to current version of zlib
Summary: upgrade zlib to the latest ver 1.2.3
Reviewed-by: martin, alanb, ksrini

! make/com/sun/java/pack/Makefile
! make/common/Defs.gmk
! make/java/jli/Makefile
! make/java/zip/FILES_c.gmk
! make/java/zip/Makefile
! make/java/zip/reorder-i586
! make/java/zip/reorder-sparc
! make/java/zip/reorder-sparcv9
! make/sun/splashscreen/FILES_c.gmk
! make/sun/splashscreen/Makefile
- src/share/native/java/util/zip/zlib-1.1.3/ChangeLog
- src/share/native/java/util/zip/zlib-1.1.3/README
- src/share/native/java/util/zip/zlib-1.1.3/compress.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.h
- src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc
- src/share/native/java/util/zip/zlib-1.1.3/example.c
- src/share/native/java/util/zip/zlib-1.1.3/gzio.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.h
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.c
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.h
- src/share/native/java/util/zip/zlib-1.1.3/inffast.c
- src/share/native/java/util/zip/zlib-1.1.3/inffast.h
- src/share/native/java/util/zip/zlib-1.1.3/inffixed.h
- src/share/native/java/util/zip/zlib-1.1.3/inflate.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.h
- src/share/native/java/util/zip/zlib-1.1.3/infutil.c
- src/share/native/java/util/zip/zlib-1.1.3/infutil.h
- src/share/native/java/util/zip/zlib-1.1.3/minigzip.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.h
- src/share/native/java/util/zip/zlib-1.1.3/uncompr.c
- src/share/native/java/util/zip/zlib-1.1.3/zadler32.c
- src/share/native/java/util/zip/zlib-1.1.3/zconf.h
- src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c
- src/share/native/java/util/zip/zlib-1.1.3/zlib.h
- src/share/native/java/util/zip/zlib-1.1.3/zutil.c
- src/share/native/java/util/zip/zlib-1.1.3/zutil.h
+ src/share/native/java/util/zip/zlib-1.2.3/ChangeLog
+ src/share/native/java/util/zip/zlib-1.2.3/README
+ src/share/native/java/util/zip/zlib-1.2.3/compress.c
+ src/share/native/java/util/zip/zlib-1.2.3/crc32.h
+ src/share/native/java/util/zip/zlib-1.2.3/deflate.c
+ src/share/native/java/util/zip/zlib-1.2.3/deflate.h
+ src/share/native/java/util/zip/zlib-1.2.3/gzio.c
+ src/share/native/java/util/zip/zlib-1.2.3/infback.c
+ src/share/native/java/util/zip/zlib-1.2.3/inffast.c
+ src/share/native/java/util/zip/zlib-1.2.3/inffast.h
+ src/share/native/java/util/zip/zlib-1.2.3/inffixed.h
+ src/share/native/java/util/zip/zlib-1.2.3/inflate.c
+ src/share/native/java/util/zip/zlib-1.2.3/inflate.h
+ src/share/native/java/util/zip/zlib-1.2.3/inftrees.c
+ src/share/native/java/util/zip/zlib-1.2.3/inftrees.h
+ src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java
+ src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff
+ src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff
+ src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff
+ src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff
+ src/share/native/java/util/zip/zlib-1.2.3/trees.c
+ src/share/native/java/util/zip/zlib-1.2.3/trees.h
+ src/share/native/java/util/zip/zlib-1.2.3/uncompr.c
+ src/share/native/java/util/zip/zlib-1.2.3/zadler32.c
+ src/share/native/java/util/zip/zlib-1.2.3/zconf.h
+ src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c
+ src/share/native/java/util/zip/zlib-1.2.3/zlib.h
+ src/share/native/java/util/zip/zlib-1.2.3/zutil.c
+ src/share/native/java/util/zip/zlib-1.2.3/zutil.h

Changeset: 196c7bb551e7
Author:    darcy
Date:      2009-08-25 18:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/196c7bb551e7

6875861: javadoc build warning on java.util.Properites from unconventional @see ordering
Reviewed-by: martin

! src/share/classes/java/util/Properties.java

Changeset: 2607e571a6d5
Author:    weijun
Date:      2009-08-26 12:17 +0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/2607e571a6d5

6868864: Kerberos tests fail under windows/cygwin
Reviewed-by: wetmore

! test/sun/security/krb5/auto/basic.sh

Changeset: 69396f593772
Author:    dl
Date:      2009-08-25 19:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/69396f593772

6871697: LinkedBlockingQueue Iterator/remove/poll race
Summary: More checks for node.next == node
Reviewed-by: martin, dholmes, chegar

! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java

Changeset: aeaf7b138d90
Author:    dl
Date:      2009-08-25 19:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/aeaf7b138d90

6868712: Improve concurrent queue tests
Summary: Fix all known flaky tests, plus minor maintenance
Reviewed-by: martin, chegar

! test/java/util/Collection/BiggernYours.java
! test/java/util/Collection/IteratorAtEnd.java
! test/java/util/Collection/MOAT.java
! test/java/util/Collections/RacingCollections.java
! test/java/util/PriorityQueue/RemoveContains.java
! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java
! test/java/util/concurrent/BlockingQueue/Interrupt.java
+ test/java/util/concurrent/BlockingQueue/LastElement.java
! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java
! test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java
! test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java
! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java
! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java
! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java
! test/java/util/concurrent/ConcurrentQueues/GCRetention.java
! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java
+ test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java
! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java
- test/java/util/concurrent/LinkedBlockingQueue/LastElement.java
- test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java

Changeset: 25371bf31658
Author:    darcy
Date:      2009-08-27 11:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/25371bf31658

6876628: @throw instead of @throws in two ParagraphView classes
Reviewed-by: peterz

! src/share/classes/javax/swing/text/ParagraphView.java
! src/share/classes/javax/swing/text/html/ParagraphView.java

Changeset: 5342b0cdbf95
Author:    xlu
Date:      2009-08-27 18:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/5342b0cdbf95

6876282: BigDecimal's divide(BigDecimal bd, RoundingFormat r) produces incorrect result
Reviewed-by: darcy

! src/share/classes/java/math/BigDecimal.java
! test/java/math/BigDecimal/DivideTests.java

Changeset: 4a5f2147f953
Author:    darcy
Date:      2009-08-28 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/4a5f2147f953

6877122: Many javadoc warnings from java.awt.Window, other awt classes
Reviewed-by: anthony

! src/share/classes/java/awt/Cursor.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/awt/dnd/DragSourceContext.java

Changeset: e0f79982edd2
Author:    darcy
Date:      2009-08-28 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e0f79982edd2

6261502: (reflect) Add the functionality to screen out the "inappropriate" modifier bits
Reviewed-by: alanb

! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Modifier.java

Changeset: 225aa5ee10da
Author:    tbell
Date:      2009-08-28 16:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/225aa5ee10da

Merge

! src/share/classes/javax/swing/text/ParagraphView.java
- src/share/native/java/util/zip/zlib-1.1.3/ChangeLog
- src/share/native/java/util/zip/zlib-1.1.3/README
- src/share/native/java/util/zip/zlib-1.1.3/compress.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.h
- src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc
- src/share/native/java/util/zip/zlib-1.1.3/example.c
- src/share/native/java/util/zip/zlib-1.1.3/gzio.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.h
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.c
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.h
- src/share/native/java/util/zip/zlib-1.1.3/inffast.c
- src/share/native/java/util/zip/zlib-1.1.3/inffast.h
- src/share/native/java/util/zip/zlib-1.1.3/inffixed.h
- src/share/native/java/util/zip/zlib-1.1.3/inflate.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.h
- src/share/native/java/util/zip/zlib-1.1.3/infutil.c
- src/share/native/java/util/zip/zlib-1.1.3/infutil.h
- src/share/native/java/util/zip/zlib-1.1.3/minigzip.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.h
- src/share/native/java/util/zip/zlib-1.1.3/uncompr.c
- src/share/native/java/util/zip/zlib-1.1.3/zadler32.c
- src/share/native/java/util/zip/zlib-1.1.3/zconf.h
- src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c
- src/share/native/java/util/zip/zlib-1.1.3/zlib.h
- src/share/native/java/util/zip/zlib-1.1.3/zutil.c
- src/share/native/java/util/zip/zlib-1.1.3/zutil.h
- test/java/util/concurrent/LinkedBlockingQueue/LastElement.java
- test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java

Changeset: db5d6b4cbc11
Author:    martin
Date:      2009-08-31 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/db5d6b4cbc11

6860431: Character.isSurrogate(char ch)
Summary: Add new method Character.isSurrogate(char ch)
Reviewed-by: sherman, darcy, okutsu

! src/share/classes/java/lang/Character.java
! src/share/classes/sun/io/CharToByteDBCS_ASCII.java
! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java
! src/share/classes/sun/nio/cs/ISO_8859_1.java
! src/share/classes/sun/nio/cs/SingleByte.java
! src/share/classes/sun/nio/cs/SingleByteEncoder.java
! src/share/classes/sun/nio/cs/Surrogate.java
! src/share/classes/sun/nio/cs/US_ASCII.java
! src/share/classes/sun/nio/cs/UTF_32Coder.java
! src/share/classes/sun/nio/cs/UTF_8.java
! src/share/classes/sun/nio/cs/UnicodeDecoder.java
! src/share/classes/sun/nio/cs/UnicodeEncoder.java
! src/share/classes/sun/nio/cs/ext/DoubleByte.java
! src/share/classes/sun/nio/cs/ext/DoubleByteEncoder.java
! src/share/classes/sun/nio/cs/ext/EUC_JP.java
! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java
! src/share/classes/sun/nio/cs/ext/EUC_TW.java
! src/share/classes/sun/nio/cs/ext/GB18030.java
! src/share/classes/sun/nio/cs/ext/ISCII91.java
! src/share/classes/sun/nio/cs/ext/ISO2022.java
! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java
! src/share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java

Changeset: ed0863629d28
Author:    tbell
Date:      2009-09-03 18:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/ed0863629d28

Merge

- src/share/native/java/util/zip/zlib-1.1.3/ChangeLog
- src/share/native/java/util/zip/zlib-1.1.3/README
- src/share/native/java/util/zip/zlib-1.1.3/compress.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.h
- src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc
- src/share/native/java/util/zip/zlib-1.1.3/example.c
- src/share/native/java/util/zip/zlib-1.1.3/gzio.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.h
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.c
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.h
- src/share/native/java/util/zip/zlib-1.1.3/inffast.c
- src/share/native/java/util/zip/zlib-1.1.3/inffast.h
- src/share/native/java/util/zip/zlib-1.1.3/inffixed.h
- src/share/native/java/util/zip/zlib-1.1.3/inflate.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.h
- src/share/native/java/util/zip/zlib-1.1.3/infutil.c
- src/share/native/java/util/zip/zlib-1.1.3/infutil.h
- src/share/native/java/util/zip/zlib-1.1.3/minigzip.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.h
- src/share/native/java/util/zip/zlib-1.1.3/uncompr.c
- src/share/native/java/util/zip/zlib-1.1.3/zadler32.c
- src/share/native/java/util/zip/zlib-1.1.3/zconf.h
- src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c
- src/share/native/java/util/zip/zlib-1.1.3/zlib.h
- src/share/native/java/util/zip/zlib-1.1.3/zutil.c
- src/share/native/java/util/zip/zlib-1.1.3/zutil.h
- test/java/util/concurrent/LinkedBlockingQueue/LastElement.java
- test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java

Changeset: ee5300e1835a
Author:    weijun
Date:      2009-09-04 14:58 +0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/ee5300e1835a

6876328: different names for the same digest algorithms breaks jarsigner
Reviewed-by: mullan

! src/share/classes/sun/security/tools/JarSigner.java
+ test/sun/security/tools/jarsigner/nameclash.sh

Changeset: 98ad1322051e
Author:    weijun
Date:      2009-09-04 14:59 +0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/98ad1322051e

6871847: AlgorithmId.get("SHA256withECDSA") not available
Reviewed-by: vinnie

! src/share/classes/sun/security/x509/AlgorithmId.java
+ test/sun/security/x509/AlgorithmId/SHA256withECDSA.java

Changeset: c34f92a47245
Author:    darcy
Date:      2009-09-04 13:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/c34f92a47245

6873951: test/java/lang/reflect/Generics/Probe.java fails.
Reviewed-by: alanb

! test/java/lang/reflect/Generics/Probe.java

Changeset: 704296144175
Author:    martin
Date:      2009-09-04 13:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/704296144175

6879368: Remove stray quote in Character javadoc
Summary: Remove stray quote in Character.valueOf javadoc, using Ulf's \u005CuXXXX technique
Reviewed-by: darcy

! src/share/classes/java/lang/Character.java

Changeset: 658a4255c797
Author:    tbell
Date:      2009-09-04 17:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/658a4255c797

Merge


Changeset: 3f87b755b1c8
Author:    alanb
Date:      2009-09-04 18:15 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3f87b755b1c8

6873621: (file) FileStore.supportsFileAttributeView(Class<FileAttributeView> type) returns wrong result
Reviewed-by: andrew

! src/share/sample/nio/file/Xdd.java
! src/solaris/classes/sun/nio/fs/LinuxFileStore.java
! src/solaris/classes/sun/nio/fs/SolarisFileStore.java
! src/solaris/classes/sun/nio/fs/UnixFileStore.java
! src/windows/classes/sun/nio/fs/WindowsFileStore.java
! test/java/nio/file/FileStore/Basic.java

Changeset: 05ea733a7ae2
Author:    alanb
Date:      2009-09-04 18:17 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/05ea733a7ae2

6868627: (spec) Files.walkFileTree doesn't make it clear that uncaught errors and exceptions are propagated
Reviewed-by: sherman

! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/file/SimpleFileVisitor.java

Changeset: 87a2ef2439bc
Author:    alanb
Date:      2009-09-04 22:22 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/87a2ef2439bc

6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to java.net.ConnectException
Reviewed-by: tbell, ohair, dcubed, andrew

! src/share/transport/socket/socketTransport.c
! test/com/sun/jdi/BadHandshakeTest.java

Changeset: 7afdf9d0bc2c
Author:    alanb
Date:      2009-09-05 15:57 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/7afdf9d0bc2c

Merge


Changeset: abb69e8b1774
Author:    tbell
Date:      2009-09-06 23:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/abb69e8b1774

Merge


Changeset: 5a584fbcc712
Author:    yan
Date:      2009-09-09 00:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/5a584fbcc712

Merge


Changeset: a48c15bcf64f
Author:    rupashka
Date:      2009-08-14 13:18 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/a48c15bcf64f

6824600: OOM occurs when setLookAndFeel() is executed in Windows L&F(XP style)
Reviewed-by: alexp

! src/share/classes/com/sun/java/swing/plaf/windows/DesktopProperty.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/share/classes/javax/swing/plaf/metal/MetalFontDesktopProperty.java
! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java
+ test/com/sun/java/swing/plaf/windows/Test6824600.java

Changeset: fa334ff12794
Author:    alexp
Date:      2009-08-19 17:24 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/fa334ff12794

6872492: JLayer sources contain wrong header
Reviewed-by: rupashka

! src/share/classes/javax/swing/JLayer.java
! src/share/classes/javax/swing/plaf/LayerUI.java

Changeset: 3e36c9abb569
Author:    yan
Date:      2009-08-20 23:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3e36c9abb569

Merge

- test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java
- test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java

Changeset: e8d93257cf7e
Author:    rupashka
Date:      2009-08-21 16:59 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e8d93257cf7e

6579827: vista : JSlider on JColorchooser is not properly render or can't be seen completely.
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
+ test/javax/swing/JSlider/6579827/bug6579827.java

Changeset: d07bd8fa89e4
Author:    rupashka
Date:      2009-08-24 18:21 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/d07bd8fa89e4

6849266: closed/javax/swing/JFileChooser/6484091/bug6484091.java fails on solaris 10 sparc
Reviewed-by: peterz

+ test/javax/swing/JFileChooser/6484091/bug6484091.java

Changeset: 799439873bf9
Author:    alexp
Date:      2009-08-24 19:22 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/799439873bf9

6824395: Several Swing core components prevent using them in wrapper classes
Reviewed-by: peterz

! src/share/classes/javax/swing/JEditorPane.java
! src/share/classes/javax/swing/JLayer.java
! src/share/classes/javax/swing/JList.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/JTextField.java
! src/share/classes/javax/swing/JTree.java
! src/share/classes/javax/swing/plaf/LayerUI.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/sun/swing/SwingUtilities2.java
+ test/javax/swing/JLayer/6824395/bug6824395.java
! test/javax/swing/JLayer/SerializationTest/SerializationTest.java

Changeset: 4914723317b9
Author:    peytoia
Date:      2009-08-31 12:55 +0900
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/4914723317b9

6851214: (tz) New Jordan rule creates a failure for SimpleTimeZone parsing post tzdata2009h
Reviewed-by: okutsu

! src/share/classes/java/util/SimpleTimeZone.java
+ test/java/util/TimeZone/ListTimeZones.java

Changeset: 7aa6cb832991
Author:    peytoia
Date:      2009-08-31 14:50 +0900
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/7aa6cb832991

6872467: (tz) Support tzdata2009l
Reviewed-by: okutsu

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/antarctica
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/backward
! make/sun/javazic/tzdata/etcetera
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/factory
! make/sun/javazic/tzdata/iso3166.tab
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/pacificnew
! make/sun/javazic/tzdata/solar87
! make/sun/javazic/tzdata/solar88
! make/sun/javazic/tzdata/solar89
! make/sun/javazic/tzdata/southamerica
! make/sun/javazic/tzdata/systemv
! make/sun/javazic/tzdata/zone.tab

Changeset: 92b6482e7719
Author:    peytoia
Date:      2009-08-31 14:53 +0900
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/92b6482e7719

6456628: (tz) Default timezone is incorrectly set occasionally on Linux
Reviewed-by: okutsu

! src/solaris/native/java/util/TimeZone_md.c

Changeset: f7d606ca25a9
Author:    peterz
Date:      2009-08-31 13:46 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/f7d606ca25a9

6802944: Nimbus initialization is too slow
Reviewed-by: jasper

! make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java
! src/share/classes/javax/swing/plaf/nimbus/Defaults.template
! src/share/classes/javax/swing/plaf/nimbus/DerivedColor.java
! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java

Changeset: 7e7153da24ef
Author:    peterz
Date:      2009-08-31 13:56 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/7e7153da24ef

6844267: Nimbus generator depends on JIBX
Summary: Nimbus generator now uses JAXB instead of JIBX
Reviewed-by: jasper

! README
! make/common/Sanity.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk
! make/javax/swing/plaf/Makefile
- make/javax/swing/plaf/nimbus/Makefile
! make/tools/Makefile
+ make/tools/generate_nimbus/Makefile
+ make/tools/src/build/tools/generatenimbus/Generator.java
+ make/tools/src/build/tools/generatenimbus/ObjectFactory.java
+ make/tools/src/build/tools/generatenimbus/Paint.java
+ make/tools/src/build/tools/generatenimbus/PainterGenerator.java
+ make/tools/src/build/tools/generatenimbus/Shape.java
+ make/tools/src/build/tools/generatenimbus/SynthModel.java
+ make/tools/src/build/tools/generatenimbus/UIDefault.java
+ make/tools/src/build/tools/generatenimbus/UIStyle.java
+ make/tools/src/build/tools/generatenimbus/Utils.java
- make/tools/swing-nimbus/Makefile
- make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java

Changeset: e7d311b4ae94
Author:    alexp
Date:      2009-08-31 18:39 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e7d311b4ae94

6872503: JLayer event handling should be rewritten
Reviewed-by: art

! src/share/classes/javax/swing/JLayer.java
+ test/javax/swing/JLayer/6872503/bug6872503.java

Changeset: 9d8f551780d5
Author:    peytoia
Date:      2009-09-01 15:39 +0900
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/9d8f551780d5

6830423: Unified Ext B character not displayed with Dialog font
Reviewed-by: okutsu

! src/windows/classes/sun/awt/windows/fontconfig.properties

Changeset: 37c33432e98a
Author:    peytoia
Date:      2009-09-01 15:42 +0900
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/37c33432e98a

6838887: (tz) Add UTC and Yerevan to tzmappings
Reviewed-by: okutsu

! src/windows/lib/tzmappings

Changeset: 5780cff2763c
Author:    peytoia
Date:      2009-09-01 16:15 +0900
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/5780cff2763c

6856390: RFE : sequence.allfonts.UTF-8.ja for Windows fontconfig.properties
Reviewed-by: okutsu

! src/windows/classes/sun/awt/windows/fontconfig.properties

Changeset: 4f819e2e0bfc
Author:    peterz
Date:      2009-09-01 15:34 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/4f819e2e0bfc

6387579: Usage of package-private class as parameter of a method (javax.swing.tree.DefaultTreeSelectionModel)
Reviewed-by: rupashka

! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java

Changeset: 935814bd43a6
Author:    alexp
Date:      2009-09-01 18:51 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/935814bd43a6

6875153: JLayer.isOptimizedDrawingEnabled() throws NPE for null glass pane set
Reviewed-by: rupashka

! src/share/classes/javax/swing/JLayer.java
! src/share/classes/javax/swing/plaf/LayerUI.java
+ test/javax/swing/JLayer/6875153/bug6875153.java

Changeset: 281fbd82a971
Author:    alexp
Date:      2009-09-02 17:47 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/281fbd82a971

6797139: JButton title is truncating for some strings irrespective of preferred size.
Reviewed-by: peterz

! src/share/classes/javax/swing/SwingUtilities.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java
! src/share/classes/sun/swing/MenuItemLayoutHelper.java
! src/share/classes/sun/swing/SwingUtilities2.java
+ test/javax/swing/SwingUtilities/6797139/bug6797139.java

Changeset: ff468ef27959
Author:    gsm
Date:      2009-09-07 12:27 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/ff468ef27959

6699856: Creating text in a JTextPane using Chinese text causes undesired behavior
Reviewed-by: peterz

! src/share/classes/javax/swing/JEditorPane.java
! src/share/classes/javax/swing/JTextPane.java
! src/share/classes/javax/swing/text/JTextComponent.java

Changeset: 01c46cb72eb7
Author:    rupashka
Date:      2009-09-07 15:09 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/01c46cb72eb7

6589634: Unable to view focus on "Up one level", "create new folder" etc. of  JFileChooser Dialog
Reviewed-by: peterz, loneid

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java

Changeset: d73a741a7ea1
Author:    malenkov
Date:      2009-09-08 14:08 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/d73a741a7ea1

6868185: 2 JCK api/java_beans/Introspector/ tests fails starting from jdk7 b66
Reviewed-by: peterz

! src/share/classes/com/sun/beans/finder/BeanInfoFinder.java

Changeset: e289c06b6d36
Author:    yan
Date:      2009-09-09 00:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e289c06b6d36

Merge

- make/javax/swing/plaf/nimbus/Makefile
- make/tools/swing-nimbus/Makefile
- make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java

Changeset: 460639b036f3
Author:    yan
Date:      2009-09-15 23:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/460639b036f3

Merge

- make/javax/swing/plaf/nimbus/Makefile
- make/tools/swing-nimbus/Makefile
- make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java

Changeset: f09a2bfba691
Author:    xdono
Date:      2009-09-17 13:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/f09a2bfba691

Added tag jdk7-b72 for changeset 460639b036f3

! .hgtags

Changeset: 986ec552383f
Author:    yan
Date:      2009-09-22 01:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/986ec552383f

Merge

- make/javax/swing/plaf/nimbus/Makefile
- make/tools/swing-nimbus/Makefile
- make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java
- make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java
- make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java
- src/share/classes/sun/nio/ch/AbstractFuture.java
- src/share/native/java/util/zip/zlib-1.1.3/ChangeLog
- src/share/native/java/util/zip/zlib-1.1.3/README
- src/share/native/java/util/zip/zlib-1.1.3/compress.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.h
- src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc
- src/share/native/java/util/zip/zlib-1.1.3/example.c
- src/share/native/java/util/zip/zlib-1.1.3/gzio.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.h
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.c
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.h
- src/share/native/java/util/zip/zlib-1.1.3/inffast.c
- src/share/native/java/util/zip/zlib-1.1.3/inffast.h
- src/share/native/java/util/zip/zlib-1.1.3/inffixed.h
- src/share/native/java/util/zip/zlib-1.1.3/inflate.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.h
- src/share/native/java/util/zip/zlib-1.1.3/infutil.c
- src/share/native/java/util/zip/zlib-1.1.3/infutil.h
- src/share/native/java/util/zip/zlib-1.1.3/minigzip.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.h
- src/share/native/java/util/zip/zlib-1.1.3/uncompr.c
- src/share/native/java/util/zip/zlib-1.1.3/zadler32.c
- src/share/native/java/util/zip/zlib-1.1.3/zconf.h
- src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c
- src/share/native/java/util/zip/zlib-1.1.3/zlib.h
- src/share/native/java/util/zip/zlib-1.1.3/zutil.c
- src/share/native/java/util/zip/zlib-1.1.3/zutil.h
- test/java/util/concurrent/LinkedBlockingQueue/LastElement.java
- test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java


From yuri.nesterenko at sun.com  Tue Sep 22 04:26:01 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Tue, 22 Sep 2009 11:26:01 +0000
Subject: <AWT Dev> hg: jdk7/awt/langtools: 34 new changesets
Message-ID: <20090922112656.687BF12754@hg.openjdk.java.net>

Changeset: 8a03f3c7d160
Author:    jjg
Date:      2009-08-12 07:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/8a03f3c7d160

6870706: langtools launcher issues
Reviewed-by: mcimadamore

! make/build.xml
! src/share/bin/launcher.sh-template

Changeset: 71680973d8ec
Author:    jjg
Date:      2009-08-12 07:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/71680973d8ec

6758471: should be able to set jtreg options in langtools build
Reviewed-by: mcimadamore

! make/build.properties
! make/build.xml

Changeset: 7dbb79875a63
Author:    jjg
Date:      2009-08-12 10:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/7dbb79875a63

6558476: com/sun/tools/javac/Main.compile don't release file handles on return
Reviewed-by: darcy

+ src/share/classes/com/sun/tools/javac/file/CloseableURLClassLoader.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ test/tools/javac/T6558476.java

Changeset: b055a5ea0dad
Author:    tbell
Date:      2009-08-18 17:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/b055a5ea0dad

Merge


Changeset: 2aa3a1cdb094
Author:    andrew
Date:      2009-08-19 20:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/2aa3a1cdb094

6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk
Summary: Set source and target explicitly in pcompile task
Reviewed-by: jjg

! make/build.xml

Changeset: 2ce3597237f0
Author:    darcy
Date:      2009-08-19 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/2ce3597237f0

6871291: Please clarify javax.tools.JavaCompiler.getTask() "classes" parameter
Reviewed-by: jjg

! src/share/classes/javax/tools/JavaCompiler.java

Changeset: 61c1f735df67
Author:    jjg
Date:      2009-08-21 11:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/61c1f735df67

6873849: suppress notes generated by javac
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/util/Log.java
+ test/tools/javac/T6873849.java

Changeset: d9febdd5ae21
Author:    jjg
Date:      2009-08-21 14:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/d9febdd5ae21

6873845: refine access to symbol file
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/main/JavacOption.java
! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/T6873845.java

Changeset: c863e90091ee
Author:    jjg
Date:      2009-08-24 14:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/c863e90091ee

6869216: testgetallmembers should consistently use correct filemanager
Reviewed-by: darcy

! test/tools/javac/processing/model/testgetallmembers/Main.java

Changeset: 33c8c38e1757
Author:    tbell
Date:      2009-08-24 22:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/33c8c38e1757

Merge


Changeset: d434aa041b52
Author:    xdono
Date:      2009-09-03 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/d434aa041b52

Added tag jdk7-b71 for changeset 33c8c38e1757

! .hgtags

Changeset: 40aca381dcaf
Author:    darcy
Date:      2009-08-25 16:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/40aca381dcaf

6872011: Update printing processor to support JSR 308
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java

Changeset: 25f15fdd168a
Author:    darcy
Date:      2009-08-26 19:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/25f15fdd168a

6548708: Annotation processing should free service loader if there are no processors
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java

Changeset: 8109aa93b212
Author:    mcimadamore
Date:      2009-08-27 13:40 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/8109aa93b212

6840638: Project Coin: Improved Type Inference for Generic Instance Creation (aka 'diamond')
Summary: diamond operator implementation (simple approach)
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/generics/diamond/neg/Neg01.java
+ test/tools/javac/generics/diamond/neg/Neg01.out
+ test/tools/javac/generics/diamond/neg/Neg02.java
+ test/tools/javac/generics/diamond/neg/Neg02.out
+ test/tools/javac/generics/diamond/neg/Neg03.java
+ test/tools/javac/generics/diamond/neg/Neg03.out
+ test/tools/javac/generics/diamond/neg/Neg04.java
+ test/tools/javac/generics/diamond/neg/Neg04.out
+ test/tools/javac/generics/diamond/neg/Neg05.java
+ test/tools/javac/generics/diamond/neg/Neg05.out
+ test/tools/javac/generics/diamond/pos/Pos01.java
+ test/tools/javac/generics/diamond/pos/Pos02.java
+ test/tools/javac/generics/diamond/pos/Pos03.java
+ test/tools/javac/generics/diamond/pos/Pos04.java

Changeset: ed31953ca025
Author:    jjg
Date:      2009-08-27 11:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/ed31953ca025

6875336: some tests should use /nodynamiccopyright/
Reviewed-by: darcy

! test/tools/javac/6521805/T6521805a.java
! test/tools/javac/6521805/T6521805a_1.out
! test/tools/javac/6521805/T6521805a_2.out
! test/tools/javac/6521805/T6521805d.java
! test/tools/javac/6521805/T6521805d.out
! test/tools/javac/6717241/T6717241a.java
! test/tools/javac/6717241/T6717241a.out
! test/tools/javac/6717241/T6717241b.java
! test/tools/javac/6717241/T6717241b.out
! test/tools/javac/6734819/T6734819c.java
! test/tools/javac/6734819/T6734819c.out
! test/tools/javac/6758789/T6758789a.java
! test/tools/javac/6758789/T6758789a.out
! test/tools/javac/6758789/T6758789b.java
! test/tools/javac/6758789/T6758789b.out
! test/tools/javac/6840059/T6840059.java
! test/tools/javac/6840059/T6840059.out
! test/tools/javac/Diagnostics/6722234/T6722234a.java
! test/tools/javac/Diagnostics/6722234/T6722234a_1.out
! test/tools/javac/Diagnostics/6722234/T6722234a_2.out
! test/tools/javac/Diagnostics/6722234/T6722234b.java
! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
! test/tools/javac/Diagnostics/6722234/T6722234c.java
! test/tools/javac/Diagnostics/6722234/T6722234c.out
! test/tools/javac/Diagnostics/6722234/T6722234d.java
! test/tools/javac/Diagnostics/6722234/T6722234d_1.out
! test/tools/javac/Diagnostics/6722234/T6722234d_2.out
! test/tools/javac/Diagnostics/6799605/T6799605.java
! test/tools/javac/Diagnostics/6799605/T6799605.out
! test/tools/javac/Diagnostics/6860795/T6860795.java
! test/tools/javac/Diagnostics/6860795/T6860795.out
! test/tools/javac/Diagnostics/6862608/T6862608a.java
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/Diagnostics/6862608/T6862608b.java
! test/tools/javac/Diagnostics/6862608/T6862608b.out
! test/tools/javac/Diagnostics/6864382/T6864382.java
! test/tools/javac/Diagnostics/6864382/T6864382.out
! test/tools/javac/OverrideChecks/6199153/T6199153.java
! test/tools/javac/OverrideChecks/6199153/T6199153.out
! test/tools/javac/OverrideChecks/6400189/T6400189a.java
! test/tools/javac/OverrideChecks/6400189/T6400189a.out
! test/tools/javac/OverrideChecks/6400189/T6400189b.java
! test/tools/javac/OverrideChecks/6400189/T6400189b.out
! test/tools/javac/cast/6467183/T6467183a.java
! test/tools/javac/cast/6467183/T6467183a.out
! test/tools/javac/cast/6557182/T6557182.java
! test/tools/javac/cast/6557182/T6557182.out
! test/tools/javac/cast/6665356/T6665356.java
! test/tools/javac/cast/6665356/T6665356.out
! test/tools/javac/cast/6795580/T6795580.java
! test/tools/javac/cast/6795580/T6795580.out
! test/tools/javac/generics/5009937/T5009937.java
! test/tools/javac/generics/5009937/T5009937.out
! test/tools/javac/generics/6182950/T6182950a.java
! test/tools/javac/generics/6182950/T6182950a.out
! test/tools/javac/generics/6182950/T6182950b.java
! test/tools/javac/generics/6182950/T6182950b.out
! test/tools/javac/generics/6677785/T6677785.java
! test/tools/javac/generics/6677785/T6677785.out
! test/tools/javac/generics/6711619/T6711619a.java
! test/tools/javac/generics/6711619/T6711619a.out
! test/tools/javac/generics/6711619/T6711619b.java
! test/tools/javac/generics/6711619/T6711619b.out
! test/tools/javac/generics/6723444/T6723444.java
! test/tools/javac/generics/6723444/T6723444.out
! test/tools/javac/generics/inference/6315770/T6315770.java
! test/tools/javac/generics/inference/6315770/T6315770.out
! test/tools/javac/generics/inference/6611449/T6611449.java
! test/tools/javac/generics/inference/6611449/T6611449.out
! test/tools/javac/generics/inference/6638712/T6638712a.java
! test/tools/javac/generics/inference/6638712/T6638712a.out
! test/tools/javac/generics/inference/6638712/T6638712b.java
! test/tools/javac/generics/inference/6638712/T6638712b.out
! test/tools/javac/generics/inference/6638712/T6638712c.java
! test/tools/javac/generics/inference/6638712/T6638712c.out
! test/tools/javac/generics/inference/6638712/T6638712d.java
! test/tools/javac/generics/inference/6638712/T6638712d.out
! test/tools/javac/generics/inference/6638712/T6638712e.java
! test/tools/javac/generics/inference/6638712/T6638712e.out
! test/tools/javac/generics/inference/6718364/T6718364.java
! test/tools/javac/generics/inference/6718364/T6718364.out
! test/tools/javac/generics/rare/6665356/T6665356.java
! test/tools/javac/generics/rare/6665356/T6665356.out
! test/tools/javac/generics/typevars/6569404/T6569404b.java
! test/tools/javac/generics/typevars/6569404/T6569404b.out
! test/tools/javac/generics/typevars/6680106/T6680106.java
! test/tools/javac/generics/typevars/6680106/T6680106.out
! test/tools/javac/generics/typevars/6804733/T6804733.java
! test/tools/javac/generics/typevars/6804733/T6804733.out
! test/tools/javac/typeAnnotations/failures/AnnotationVersion.java
! test/tools/javac/typeAnnotations/failures/AnnotationVersion.out
! test/tools/javac/typeAnnotations/failures/IncompleteArray.java
! test/tools/javac/typeAnnotations/failures/IncompleteArray.out
! test/tools/javac/typeAnnotations/failures/IncompleteVararg.java
! test/tools/javac/typeAnnotations/failures/IncompleteVararg.out
! test/tools/javac/typeAnnotations/failures/IndexArray.java
! test/tools/javac/typeAnnotations/failures/IndexArray.out
! test/tools/javac/typeAnnotations/failures/LintCast.java
! test/tools/javac/typeAnnotations/failures/LintCast.out
! test/tools/javac/typeAnnotations/failures/Scopes.java
! test/tools/javac/typeAnnotations/failures/Scopes.out
! test/tools/javac/typeAnnotations/failures/StaticFields.java
! test/tools/javac/typeAnnotations/failures/StaticFields.out
! test/tools/javac/typeAnnotations/failures/StaticMethods.java
! test/tools/javac/typeAnnotations/failures/StaticMethods.out
! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/target/Constructor.java
! test/tools/javac/typeAnnotations/failures/target/Constructor.out
! test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java
! test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out
! test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java
! test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out
! test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java
! test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out
! test/tools/javac/typeAnnotations/failures/target/VoidMethod.java
! test/tools/javac/typeAnnotations/failures/target/VoidMethod.out
! test/tools/javac/varargs/6806876/T6806876.java
! test/tools/javac/varargs/6806876/T6806876.out
! test/tools/javac/warnings/6747671/T6747671.java
! test/tools/javac/warnings/6747671/T6747671.out

Changeset: 74760fd5197f
Author:    jjg
Date:      2009-08-27 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/74760fd5197f

6843707: bad tests generate files in the test/ directory
6876699: generated files in repository
Reviewed-by: darcy

- test/tools/javac/meth/InvokeMH_BAD68.java
- test/tools/javac/meth/InvokeMH_BAD72.java
! test/tools/javac/meth/MakeNegTests.sh
! test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/quid/QuotedIdent_BAD61.java
- test/tools/javac/quid/QuotedIdent_BAD62.java
- test/tools/javac/quid/QuotedIdent_BAD63.java

Changeset: 2c20f17c429c
Author:    jjg
Date:      2009-08-27 17:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/2c20f17c429c

6876753: javap tests fail on Windows
Reviewed-by: darcy

! test/tools/javap/T4975569.java
! test/tools/javap/T6729471.java
! test/tools/javap/pathsep.sh
! test/tools/javap/stackmap/T6271292.sh

Changeset: f29068bfeaed
Author:    jjg
Date:      2009-08-27 17:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/f29068bfeaed

6876755: apt tests fail on Windows
Reviewed-by: darcy

! test/tools/apt/Basics/apt.sh
! test/tools/apt/Basics/print.sh
! test/tools/apt/Compile/compile.sh

Changeset: 477c5bf1149c
Author:    jjg
Date:      2009-08-27 18:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/477c5bf1149c

6876765: javah tests fail on Windows
Reviewed-by: darcy

! test/tools/javah/6257087/foo.sh
! test/tools/javah/ConstMacroTest.sh
! test/tools/javah/MissingParamClassTest.sh
! test/tools/javah/ReadOldClass.sh

Changeset: 0ba956343648
Author:    jjg
Date:      2009-08-28 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/0ba956343648

6876782: two javadoc tests fail on Windows
Reviewed-by: darcy

! test/com/sun/javadoc/lib/JavadocTester.java
! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java

Changeset: f0c9fc46990b
Author:    jjg
Date:      2009-08-28 14:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/f0c9fc46990b

6877188: some javac shell tests do not work on Windows
Reviewed-by: darcy

! test/tools/javac/4846262/Test.sh
! test/tools/javac/6302184/T6302184.sh
! test/tools/javac/ClassPathTest/ClassPathTest.sh
! test/tools/javac/ExtDirs/ExtDirs.sh
! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh
! test/tools/javac/javazip/Test.sh
! test/tools/javac/newlines/Newlines.sh
! test/tools/javac/unicode/SupplementaryJavaID6.sh

Changeset: ce5be4c09f2a
Author:    tbell
Date:      2009-08-28 16:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/ce5be4c09f2a

Merge

- test/tools/javac/meth/InvokeMH_BAD68.java
- test/tools/javac/meth/InvokeMH_BAD72.java
- test/tools/javac/quid/QuotedIdent_BAD61.java
- test/tools/javac/quid/QuotedIdent_BAD62.java
- test/tools/javac/quid/QuotedIdent_BAD63.java

Changeset: d5e76d422509
Author:    jjg
Date:      2009-08-31 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/d5e76d422509

6877229: more javac tests fail on Windows
Reviewed-by: darcy

! test/tools/javac/6589361/T6589361.java
! test/tools/javac/MissingInclude.sh
! test/tools/javac/T5090006/compiler.sh
! test/tools/javac/api/6440333/T6440333.java
! test/tools/javac/api/Sibling.java
! test/tools/javac/code/ArrayClone.java
! test/tools/javac/constDebug/ConstDebug.sh
! test/tools/javac/fatalErrors/NoJavaLang.sh
! test/tools/javac/innerClassFile/Driver.sh
! test/tools/javac/quid/QuotedIdent.java
! test/tools/javac/quid/QuotedIdent2.java
! test/tools/javac/stackmap/T4955930.sh

Changeset: 4fa458c945ac
Author:    jjg
Date:      2009-08-31 17:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/4fa458c945ac

6877744: delete extraneous file
Reviewed-by: darcy

- test/tools/javac/innerClassFile/Driver.java

Changeset: 45301370bc5a
Author:    jjg
Date:      2009-08-31 18:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/45301370bc5a

6877751: test/tools/javac/6627362/T6627362.java fails
Reviewed-by: darcy

! test/tools/javac/6627362/T6627362.java

Changeset: 5a72ba18c471
Author:    jjg
Date:      2009-08-31 19:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/5a72ba18c471

6877759: test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java leaves open file
Reviewed-by: darcy

! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java

Changeset: dda7e13f09fb
Author:    mcimadamore
Date:      2009-09-01 14:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/dda7e13f09fb

6650759: Inference of formal type parameter (unused in formal parameters) is not performed
Summary: propagate inference constraints from 15.12.2.7 to 15.12.2.8
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/generics/inference/6302954/T6476073.java
! test/tools/javac/generics/inference/6638712/T6638712b.out
! test/tools/javac/generics/inference/6638712/T6638712e.out
+ test/tools/javac/generics/inference/6650759/T6650759a.java
+ test/tools/javac/generics/inference/6650759/T6650759b.java
+ test/tools/javac/generics/inference/6650759/T6650759c.java
+ test/tools/javac/generics/inference/6650759/T6650759d.java
+ test/tools/javac/generics/inference/6650759/T6650759e.java
+ test/tools/javac/generics/inference/6650759/T6650759f.java
+ test/tools/javac/generics/inference/6650759/T6650759g.java
+ test/tools/javac/generics/inference/6650759/T6650759h.java
+ test/tools/javac/generics/inference/6650759/T6650759i.java
+ test/tools/javac/generics/inference/6650759/T6650759j.java
+ test/tools/javac/generics/inference/6650759/T6650759k.java
+ test/tools/javac/generics/inference/6650759/T6650759l.java
+ test/tools/javac/generics/inference/6650759/T6650759m.java
+ test/tools/javac/generics/inference/6650759/T6650759m.out

Changeset: 40a1327a5283
Author:    jjg
Date:      2009-09-01 11:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/40a1327a5283

6877763: update langtools/test/Makefile for JPRT
Reviewed-by: ohair

! test/Makefile

Changeset: 8d999cb7ec09
Author:    jjg
Date:      2009-09-02 10:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/8d999cb7ec09

6874249: Check has duplicate local variable and field for "source"
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Check.java

Changeset: 90c28923e449
Author:    tbell
Date:      2009-09-03 18:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/90c28923e449

Merge

- test/tools/javac/innerClassFile/Driver.java
- test/tools/javac/meth/InvokeMH_BAD68.java
- test/tools/javac/meth/InvokeMH_BAD72.java
- test/tools/javac/quid/QuotedIdent_BAD61.java
- test/tools/javac/quid/QuotedIdent_BAD62.java
- test/tools/javac/quid/QuotedIdent_BAD63.java

Changeset: 35e29f51a7c3
Author:    jjg
Date:      2009-09-08 11:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/35e29f51a7c3

6419701: DefaultFileManager clean up: URI.create
6483788: DefaultFileManager.ZipFileObject.toUri() fails to escape space characters
6501502: JSR 199: FileObject.toUri should return file:///c:/ or file:/c:/ not file://c:/
6877206: JavaFileObject.toUri returns bogus URI (win)
6877223: tests @ignored because of issues with File.toURI on Windows
Reviewed-by: mcimadamore, alanb

! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java
! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java
! src/share/classes/com/sun/tools/javac/file/ZipArchive.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! test/tools/javac/Diagnostics/6769027/tester.properties
! test/tools/javac/api/6440333/T6440333.java
! test/tools/javac/api/Sibling.java
+ test/tools/javac/api/T6483788.java
+ test/tools/javac/api/T6501502.java
+ test/tools/javac/api/T6877206.java

Changeset: dd98acd9f717
Author:    jjg
Date:      2009-09-08 11:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/dd98acd9f717

6879346: files have Windows newlines
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml
! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java
! test/com/sun/javadoc/testCRLineSeparator/pkg/MyClass.java
! test/com/sun/javadoc/testHref/package-list
! test/com/sun/javadoc/testLinkOption/testNewLineInLink/package.html
! test/com/sun/javadoc/testNoPackagesFile/TestNoPackagesFile.java
! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java
! test/com/sun/javadoc/testRelativeLinks/pkg/package.html
! test/com/sun/javadoc/testTaglets/TestTaglets.java
! test/com/sun/javadoc/testWarnings/pkg/package.html
! test/tools/javah/SubClassConsts.win

Changeset: 261c54b2312e
Author:    jjg
Date:      2009-09-08 11:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/261c54b2312e

6879371: javap does not close internal default file manager
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javap/JavapTask.java
+ test/tools/javap/T6879371.java

Changeset: bfad32768345
Author:    xdono
Date:      2009-09-17 13:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/bfad32768345

Added tag jdk7-b72 for changeset 261c54b2312e

! .hgtags


From Mandy.Chung at Sun.COM  Tue Sep 22 10:19:29 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Tue, 22 Sep 2009 10:19:29 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4AB73E0D.3000600@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com>
Message-ID: <4AB90721.2060509@Sun.com>

(I took the core-libs-dev off as this is about awt/2d/swing discussion).

The main question is whether the client stack wants to require the 
dependency on logging when the JDK is broken down into fine-grained 
module.   It is fine to wait until the jigsaw module system is ready to 
provide the performance numbers for you to evaluate.

Some clarification inlined below.

Andrei Dmitriev wrote:
> Hi Mandy, Oleg,
> 
> I'm going to summarize pros and cons of this change just to make judge 
> (basically for myself).
> 
> 1) we can't expect a significant memory gain (the numbers are ~90Kb). 
> That's a minus.

I would not say it's a minus as it doesn't have negative impact.

> 2) we decouple awt/swing/2d with logging package which is a Plus in a 
> view of jigsaw. See 6) for more.
> 3) we don't have time measures for this change. That's a minus.

This statement isn't true.  This should be "no significant perf 
improvement" for this fix and the perf improvment is not the goal for 
this fix.

I did run the refworkload startup benchmark.  But the numbers confirm 
that there is no significant improvement as expected.

==============================================================================
mchung.baseline.b70:
   Benchmark           Samples        Mean     Stdev             Geomean 
Weight
   startup3                 30        2.33      0.05
     Framer                 30        0.30      0.01             0.03
     JEdit                  30        1.71      0.11             0.30
     LimeWire               30        2.21      0.06             0.30
     NetBeans               30        7.38      0.14             0.30
     Noop                   30        0.11      0.00             0.03
     XFramer                30        0.30      0.00             0.04
==============================================================================
mchung.platform.logging:
   Benchmark           Samples        Mean     Stdev   %Diff     P 
Significant
   startup3                 30        2.34      0.05   -0.22 0.684 
       *
     Framer                 30        0.30      0.00    0.33 0.326 
       *
     JEdit                  30        1.70      0.09    0.99 0.522 
       *
     LimeWire               30        2.24      0.05   -1.56 0.025 
       *
     NetBeans               30        7.37      0.06    0.08 0.833 
       *
     Noop                   30        0.11      0.02   -3.94 0.326 
       *
     XFramer                30        0.30      0.00    0.22 0.310 
       *
==============================================================================
   * - Not Significant: A non-zero %Diff for the mean could be noise. If the
       %Diff is 0, an actual difference may still exist. In either case, 
more
       samples would be needed to detect an actual difference in sample 
means.

> 4) nobody measured anything else than Framer and SwingSet. That's a minus.

As I said, the fix is to eliminate the dependency on logging.  I'm not 
sure what measurement you want to do.

> 5) we lose flexibility on debugging. That's a minus.

This statement isn't true.  AWT debugging ability is unchanged.

Mandy

> 6) this fix don't decouple anything else awt/swing/2d.
> I made a grep on "Logger.getLogger" and there are entries from xml, jmx, 
> etc. That means we have to deal with them as well too (as it causes the 
> class to be loaded anyway), if we aware of jigsaw.
> 7) In most cases AWT initiates classes statically but basically may want 
> to do that lazily. That's minus. I'd consider initialization in CTOR at 
> first and see the impact. Believe SwingSet would show enough here. If 
> not, that's the reason to go further to... well to check if the Java 
> property set.
> 
> Now, I don't see the evaluation is completed to make the decision. And 
> if we could modify client code in the way that Framer will never 
> initialize or/and load Logger (et al) classes so we achieved the goal.
> 
> Thanks,
>  Andrei
> 
> Oleg Sukhodolsky wrote:
>> HI Mandy,
>>
>> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <Mandy.Chung at sun.com> 
>> wrote:
>>  
>>> 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 the logging 
>>> API is
>>> to support maintaining and servicing software at customer sites.   
>>> Adding
>>> debugging code in the awt implementation using logging API is 
>>> reasonable but
>>> it's not the requirement for the logging API.  If there were a better 
>>> option
>>> to add debugging code, I believe you have no problem changing the awt
>>> debugging code not to use the logging API.
>>>
>>> Server-type applications are typical use cases that logging 
>>> information is
>>> very important and useful for diagnosis in the field - long running 
>>> apps,
>>> hard to reproduce problems until running for many days/months.  It is 
>>> hard
>>> to imagine how the logging information is important in client 
>>> applications.
>>>     
>>
>> as ex-AWT developer I can confirm that there were number of cases when
>> logging had helped us to diagnose problem on client's site.  Even
>> though you usually
>> do not need to run an application for a long time to reproduce a problem
>> it can be very hard to reproduce it because the problem depends on
>> window manager
>> and other environment which is hard to re-create.
>>
>>  
>>>   But you seem to know many client applications use the logging API 
>>> that I
>>> would also be interested to follow up with their requirements.
>>>     
>>
>> I do not know many client applications which uses logging API (because 
>> I have
>> never write real client application) and it is hard to say if it uses
>> logging or not.
>> I hoped that you who saying that suggested changes will help to client
>> application
>> has some statistic to confirm your expectation
>>
>>  
>>>> Ok, so this fix is only about modules.  But why AWT should not depend
>>>> on logging module?
>>>> The qiestion is: how many application we want to run doesn't use
>>>> logging& Because if an application
>>>> uses logging there is no reasons for AWT to not use it.  Please note
>>>> that even if logging is turned
>>>> off, the application still needs logging package/module.  So, though
>>>> end-user doesn't need logging output
>>>> she may need logging module to run the application.
>>>>       
>>> This is exactly why we want to decouple the dependency on logging.  
>>> When an
>>> application uses logging, the application knows clearly what module they
>>> require and that's fine.  When an application doesn't logging, if the 
>>> awt
>>> component requires logging for debugging purpose only, it increases the
>>> download size, footprint and startup performance (class lookup time,
>>> loading, init, etc) - please see my performance analysis report; 
>>> otherwise,
>>> it's not fruitful to discuss the details in this thread without the
>>> background info.  Just to mention it what we care about.
>>>     
>>
>> I have found only two links to some performance analysis:
>>
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
>> http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64 
>>
>>
>> but they say about -Xverify and -Xshare and do not understand how they
>> can be related
>> to our topic :(  If they do, please explain (I have never been an
>> expert in this area :(
>> Or, if I missed something could you please point me what I have missed.
>>
>>  
>>>> So, it is really
>>>> important to understand
>>>> what number of application will get advantage of suggested changes.
>>>>
>>>>
>>>>       
>>> You are suggesting the client applications always have a dependency on
>>> logging.   Many client team engineers are happy to see the dependency on
>>> logging being eliminated from the client stack requirement and 
>>> approve this
>>> fix :)
>>>     
>>
>> I do not see how this can be considered as prove that the changes will
>> help client applications.
>> Unless we have some statistic it is all just our guess (which, as we
>> know, usually wrong ;)
>>
>>  
>>>> Second question is: how big logging module is going to be? How big the
>>>> benefit for end-user will be?
>>>>
>>>>
>>>>       
>>> The size of the logging API is not big (~90K) but the size is not the 
>>> only
>>> one factor determining what benefit the end-user will have.
>>>     
>>
>> what other factors do you know?
>>
>>  
>>>  It's not
>>> necessary to logging API as one single module and details are to be 
>>> worked
>>> out.   Subscribe to the jigsaw project to follow the discussion and 
>>> progress
>>> there.   Serviceability includes other API as well.  If awt started 
>>> using
>>> other serviceability API (java.lang.management, java.lang.instrument) 
>>> for
>>> whatever reason, your argument would apply there as well.  I don't 
>>> think you
>>> wanted the awt module depends on all the serviceability APIs.
>>>     
>>
>> I agree that usage of any API should be done after careful consideration.
>> Logging API provides us exactly what we need (ability to create log of
>> an application
>> executed on client)  this is why we started to use it.
>>
>>  
>>>> I'm asking so many question mainly because the changes you suggested
>>>> create rather unnatural code (we can not
>>>> use standard logging machinery any more), so such changes should be
>>>> well-justified.
>>>>
>>>>
>>>>       
>>> That's what we pay for to modularize the JDK after many years of JDK
>>> development without module support in the platform.  Otherwise, if there
>>> were module support in the platform, you would consider very 
>>> carefully when
>>> adding a dependency on another module.
>>>     
>>
>> perhaps you are right, but in case of logging I would expect that we'd 
>> use it
>> anyway.
>>
>> Oleg.
>>
>>  
>>> If you have further issue, I suggest to start a different thread on the
>>> awt-dev alias.
>>>
>>> Thanks
>>> Mandy
>>> [1] http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
>>>
>>>     
> 

From Igor.Nekrestyanov at Sun.COM  Tue Sep 22 11:00:57 2009
From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov)
Date: Tue, 22 Sep 2009 11:00:57 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]    Review Request for 6879044
In-Reply-To: <4AB90721.2060509@Sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
Message-ID: <4AB910D9.2090709@sun.com>

BTW, note that reducing set of required core classes will save 3x of 
memory at least (think of jqs and classes.jsa in addition to rt.jar (on 
windows)).

-igor

On 9/22/09 10:19 AM, Mandy Chung wrote:
> (I took the core-libs-dev off as this is about awt/2d/swing discussion).
>
> The main question is whether the client stack wants to require the 
> dependency on logging when the JDK is broken down into fine-grained 
> module.   It is fine to wait until the jigsaw module system is ready 
> to provide the performance numbers for you to evaluate.
>
> Some clarification inlined below.
>
> Andrei Dmitriev wrote:
>> Hi Mandy, Oleg,
>>
>> I'm going to summarize pros and cons of this change just to make 
>> judge (basically for myself).
>>
>> 1) we can't expect a significant memory gain (the numbers are ~90Kb). 
>> That's a minus.
>
> I would not say it's a minus as it doesn't have negative impact.
>
>> 2) we decouple awt/swing/2d with logging package which is a Plus in a 
>> view of jigsaw. See 6) for more.
>> 3) we don't have time measures for this change. That's a minus.
>
> This statement isn't true.  This should be "no significant perf 
> improvement" for this fix and the perf improvment is not the goal for 
> this fix.
>
> I did run the refworkload startup benchmark.  But the numbers confirm 
> that there is no significant improvement as expected.
>
> ============================================================================== 
>
> mchung.baseline.b70:
>   Benchmark           Samples        Mean     Stdev             
> Geomean Weight
>   startup3                 30        2.33      0.05
>     Framer                 30        0.30      0.01             0.03
>     JEdit                  30        1.71      0.11             0.30
>     LimeWire               30        2.21      0.06             0.30
>     NetBeans               30        7.38      0.14             0.30
>     Noop                   30        0.11      0.00             0.03
>     XFramer                30        0.30      0.00             0.04
> ============================================================================== 
>
> mchung.platform.logging:
>   Benchmark           Samples        Mean     Stdev   %Diff     P 
> Significant
>   startup3                 30        2.34      0.05   -0.22 0.684       *
>     Framer                 30        0.30      0.00    0.33 0.326       *
>     JEdit                  30        1.70      0.09    0.99 0.522       *
>     LimeWire               30        2.24      0.05   -1.56 0.025       *
>     NetBeans               30        7.37      0.06    0.08 0.833       *
>     Noop                   30        0.11      0.02   -3.94 0.326       *
>     XFramer                30        0.30      0.00    0.22 0.310       *
> ============================================================================== 
>
>   * - Not Significant: A non-zero %Diff for the mean could be noise. 
> If the
>       %Diff is 0, an actual difference may still exist. In either 
> case, more
>       samples would be needed to detect an actual difference in sample 
> means.
>
>> 4) nobody measured anything else than Framer and SwingSet. That's a 
>> minus.
>
> As I said, the fix is to eliminate the dependency on logging.  I'm not 
> sure what measurement you want to do.
>
>> 5) we lose flexibility on debugging. That's a minus.
>
> This statement isn't true.  AWT debugging ability is unchanged.
>
> Mandy
>
>> 6) this fix don't decouple anything else awt/swing/2d.
>> I made a grep on "Logger.getLogger" and there are entries from xml, 
>> jmx, etc. That means we have to deal with them as well too (as it 
>> causes the class to be loaded anyway), if we aware of jigsaw.
>> 7) In most cases AWT initiates classes statically but basically may 
>> want to do that lazily. That's minus. I'd consider initialization in 
>> CTOR at first and see the impact. Believe SwingSet would show enough 
>> here. If not, that's the reason to go further to... well to check if 
>> the Java property set.
>>
>> Now, I don't see the evaluation is completed to make the decision. 
>> And if we could modify client code in the way that Framer will never 
>> initialize or/and load Logger (et al) classes so we achieved the goal.
>>
>> Thanks,
>>  Andrei
>>
>> Oleg Sukhodolsky wrote:
>>> HI Mandy,
>>>
>>> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <Mandy.Chung at sun.com> 
>>> wrote:
>>>
>>>> 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 the logging 
>>>> API is
>>>> to support maintaining and servicing software at customer sites.   
>>>> Adding
>>>> debugging code in the awt implementation using logging API is 
>>>> reasonable but
>>>> it's not the requirement for the logging API.  If there were a 
>>>> better option
>>>> to add debugging code, I believe you have no problem changing the awt
>>>> debugging code not to use the logging API.
>>>>
>>>> Server-type applications are typical use cases that logging 
>>>> information is
>>>> very important and useful for diagnosis in the field - long running 
>>>> apps,
>>>> hard to reproduce problems until running for many days/months.  It 
>>>> is hard
>>>> to imagine how the logging information is important in client 
>>>> applications.
>>>
>>> as ex-AWT developer I can confirm that there were number of cases when
>>> logging had helped us to diagnose problem on client's site.  Even
>>> though you usually
>>> do not need to run an application for a long time to reproduce a 
>>> problem
>>> it can be very hard to reproduce it because the problem depends on
>>> window manager
>>> and other environment which is hard to re-create.
>>>
>>>
>>>>   But you seem to know many client applications use the logging API 
>>>> that I
>>>> would also be interested to follow up with their requirements.
>>>
>>> I do not know many client applications which uses logging API 
>>> (because I have
>>> never write real client application) and it is hard to say if it uses
>>> logging or not.
>>> I hoped that you who saying that suggested changes will help to client
>>> application
>>> has some statistic to confirm your expectation
>>>
>>>
>>>>> Ok, so this fix is only about modules.  But why AWT should not depend
>>>>> on logging module?
>>>>> The qiestion is: how many application we want to run doesn't use
>>>>> logging& Because if an application
>>>>> uses logging there is no reasons for AWT to not use it.  Please note
>>>>> that even if logging is turned
>>>>> off, the application still needs logging package/module.  So, though
>>>>> end-user doesn't need logging output
>>>>> she may need logging module to run the application.
>>>> This is exactly why we want to decouple the dependency on logging.  
>>>> When an
>>>> application uses logging, the application knows clearly what module 
>>>> they
>>>> require and that's fine.  When an application doesn't logging, if 
>>>> the awt
>>>> component requires logging for debugging purpose only, it increases 
>>>> the
>>>> download size, footprint and startup performance (class lookup time,
>>>> loading, init, etc) - please see my performance analysis report; 
>>>> otherwise,
>>>> it's not fruitful to discuss the details in this thread without the
>>>> background info.  Just to mention it what we care about.
>>>
>>> I have found only two links to some performance analysis:
>>>
>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
>>> http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64 
>>>
>>>
>>> but they say about -Xverify and -Xshare and do not understand how they
>>> can be related
>>> to our topic :(  If they do, please explain (I have never been an
>>> expert in this area :(
>>> Or, if I missed something could you please point me what I have missed.
>>>
>>>
>>>>> So, it is really
>>>>> important to understand
>>>>> what number of application will get advantage of suggested changes.
>>>>>
>>>>>
>>>> You are suggesting the client applications always have a dependency on
>>>> logging.   Many client team engineers are happy to see the 
>>>> dependency on
>>>> logging being eliminated from the client stack requirement and 
>>>> approve this
>>>> fix :)
>>>
>>> I do not see how this can be considered as prove that the changes will
>>> help client applications.
>>> Unless we have some statistic it is all just our guess (which, as we
>>> know, usually wrong ;)
>>>
>>>
>>>>> Second question is: how big logging module is going to be? How big 
>>>>> the
>>>>> benefit for end-user will be?
>>>>>
>>>>>
>>>> The size of the logging API is not big (~90K) but the size is not 
>>>> the only
>>>> one factor determining what benefit the end-user will have.
>>>
>>> what other factors do you know?
>>>
>>>
>>>>  It's not
>>>> necessary to logging API as one single module and details are to be 
>>>> worked
>>>> out.   Subscribe to the jigsaw project to follow the discussion and 
>>>> progress
>>>> there.   Serviceability includes other API as well.  If awt started 
>>>> using
>>>> other serviceability API (java.lang.management, 
>>>> java.lang.instrument) for
>>>> whatever reason, your argument would apply there as well.  I don't 
>>>> think you
>>>> wanted the awt module depends on all the serviceability APIs.
>>>
>>> I agree that usage of any API should be done after careful 
>>> consideration.
>>> Logging API provides us exactly what we need (ability to create log of
>>> an application
>>> executed on client)  this is why we started to use it.
>>>
>>>
>>>>> I'm asking so many question mainly because the changes you suggested
>>>>> create rather unnatural code (we can not
>>>>> use standard logging machinery any more), so such changes should be
>>>>> well-justified.
>>>>>
>>>>>
>>>> That's what we pay for to modularize the JDK after many years of JDK
>>>> development without module support in the platform.  Otherwise, if 
>>>> there
>>>> were module support in the platform, you would consider very 
>>>> carefully when
>>>> adding a dependency on another module.
>>>
>>> perhaps you are right, but in case of logging I would expect that 
>>> we'd use it
>>> anyway.
>>>
>>> Oleg.
>>>
>>>
>>>> If you have further issue, I suggest to start a different thread on 
>>>> the
>>>> awt-dev alias.
>>>>
>>>> Thanks
>>>> Mandy
>>>> [1] http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
>>>>
>>


From Igor.Nekrestyanov at Sun.COM  Tue Sep 22 11:30:19 2009
From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov)
Date: Tue, 22 Sep 2009 11:30:19 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]    Review Request for 6879044
In-Reply-To: <4AB910D9.2090709@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
	<4AB910D9.2090709@sun.com>
Message-ID: <4AB917BB.4060403@sun.com>

Let me clarify this as it is does not directly translate into 3x footprint.
But savings are not just "size of classes to be loaded".

  Common "core" classes are also included into shared archive 
(classes.jsa) and removing logging classes
from the "core" will reduce size of classes.jsa (which is mmap-ed to the 
memory on Windows).
Note that we may read same class from rt.jar too if it happens to be in 
the same block as other class we need.

It will also reduce java quickstarter "read set" and this will make jqs 
more user friendly (less load on the system,
smaller portion of disk cache taken for java stuff).

None of these changes is "stunning" per se. But they sum up.
(This does not mean that Mandy's approach is the only way to go, if 
someone can suggest how to improve logging package to
get same savings and preserve backward compatibility - this will be even 
better.)

-igor

On 9/22/09 11:00 AM, Igor Nekrestyanov wrote:
> BTW, note that reducing set of required core classes will save 3x of 
> memory at least (think of jqs and classes.jsa in addition to rt.jar 
> (on windows)).
>
> -igor
>
> On 9/22/09 10:19 AM, Mandy Chung wrote:
>> (I took the core-libs-dev off as this is about awt/2d/swing discussion).
>>
>> The main question is whether the client stack wants to require the 
>> dependency on logging when the JDK is broken down into fine-grained 
>> module.   It is fine to wait until the jigsaw module system is ready 
>> to provide the performance numbers for you to evaluate.
>>
>> Some clarification inlined below.
>>
>> Andrei Dmitriev wrote:
>>> Hi Mandy, Oleg,
>>>
>>> I'm going to summarize pros and cons of this change just to make 
>>> judge (basically for myself).
>>>
>>> 1) we can't expect a significant memory gain (the numbers are 
>>> ~90Kb). That's a minus.
>>
>> I would not say it's a minus as it doesn't have negative impact.
>>
>>> 2) we decouple awt/swing/2d with logging package which is a Plus in 
>>> a view of jigsaw. See 6) for more.
>>> 3) we don't have time measures for this change. That's a minus.
>>
>> This statement isn't true.  This should be "no significant perf 
>> improvement" for this fix and the perf improvment is not the goal for 
>> this fix.
>>
>> I did run the refworkload startup benchmark.  But the numbers confirm 
>> that there is no significant improvement as expected.
>>
>> ============================================================================== 
>>
>> mchung.baseline.b70:
>>   Benchmark           Samples        Mean     Stdev             
>> Geomean Weight
>>   startup3                 30        2.33      0.05
>>     Framer                 30        0.30      0.01             0.03
>>     JEdit                  30        1.71      0.11             0.30
>>     LimeWire               30        2.21      0.06             0.30
>>     NetBeans               30        7.38      0.14             0.30
>>     Noop                   30        0.11      0.00             0.03
>>     XFramer                30        0.30      0.00             0.04
>> ============================================================================== 
>>
>> mchung.platform.logging:
>>   Benchmark           Samples        Mean     Stdev   %Diff     P 
>> Significant
>>   startup3                 30        2.34      0.05   -0.22 
>> 0.684       *
>>     Framer                 30        0.30      0.00    0.33 
>> 0.326       *
>>     JEdit                  30        1.70      0.09    0.99 
>> 0.522       *
>>     LimeWire               30        2.24      0.05   -1.56 
>> 0.025       *
>>     NetBeans               30        7.37      0.06    0.08 
>> 0.833       *
>>     Noop                   30        0.11      0.02   -3.94 
>> 0.326       *
>>     XFramer                30        0.30      0.00    0.22 
>> 0.310       *
>> ============================================================================== 
>>
>>   * - Not Significant: A non-zero %Diff for the mean could be noise. 
>> If the
>>       %Diff is 0, an actual difference may still exist. In either 
>> case, more
>>       samples would be needed to detect an actual difference in 
>> sample means.
>>
>>> 4) nobody measured anything else than Framer and SwingSet. That's a 
>>> minus.
>>
>> As I said, the fix is to eliminate the dependency on logging.  I'm 
>> not sure what measurement you want to do.
>>
>>> 5) we lose flexibility on debugging. That's a minus.
>>
>> This statement isn't true.  AWT debugging ability is unchanged.
>>
>> Mandy
>>
>>> 6) this fix don't decouple anything else awt/swing/2d.
>>> I made a grep on "Logger.getLogger" and there are entries from xml, 
>>> jmx, etc. That means we have to deal with them as well too (as it 
>>> causes the class to be loaded anyway), if we aware of jigsaw.
>>> 7) In most cases AWT initiates classes statically but basically may 
>>> want to do that lazily. That's minus. I'd consider initialization in 
>>> CTOR at first and see the impact. Believe SwingSet would show enough 
>>> here. If not, that's the reason to go further to... well to check if 
>>> the Java property set.
>>>
>>> Now, I don't see the evaluation is completed to make the decision. 
>>> And if we could modify client code in the way that Framer will never 
>>> initialize or/and load Logger (et al) classes so we achieved the goal.
>>>
>>> Thanks,
>>>  Andrei
>>>
>>> Oleg Sukhodolsky wrote:
>>>> HI Mandy,
>>>>
>>>> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <Mandy.Chung at sun.com> 
>>>> wrote:
>>>>
>>>>> 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 the 
>>>>> logging API is
>>>>> to support maintaining and servicing software at customer sites.   
>>>>> Adding
>>>>> debugging code in the awt implementation using logging API is 
>>>>> reasonable but
>>>>> it's not the requirement for the logging API.  If there were a 
>>>>> better option
>>>>> to add debugging code, I believe you have no problem changing the awt
>>>>> debugging code not to use the logging API.
>>>>>
>>>>> Server-type applications are typical use cases that logging 
>>>>> information is
>>>>> very important and useful for diagnosis in the field - long 
>>>>> running apps,
>>>>> hard to reproduce problems until running for many days/months.  It 
>>>>> is hard
>>>>> to imagine how the logging information is important in client 
>>>>> applications.
>>>>
>>>> as ex-AWT developer I can confirm that there were number of cases when
>>>> logging had helped us to diagnose problem on client's site.  Even
>>>> though you usually
>>>> do not need to run an application for a long time to reproduce a 
>>>> problem
>>>> it can be very hard to reproduce it because the problem depends on
>>>> window manager
>>>> and other environment which is hard to re-create.
>>>>
>>>>
>>>>>   But you seem to know many client applications use the logging 
>>>>> API that I
>>>>> would also be interested to follow up with their requirements.
>>>>
>>>> I do not know many client applications which uses logging API 
>>>> (because I have
>>>> never write real client application) and it is hard to say if it uses
>>>> logging or not.
>>>> I hoped that you who saying that suggested changes will help to client
>>>> application
>>>> has some statistic to confirm your expectation
>>>>
>>>>
>>>>>> Ok, so this fix is only about modules.  But why AWT should not 
>>>>>> depend
>>>>>> on logging module?
>>>>>> The qiestion is: how many application we want to run doesn't use
>>>>>> logging& Because if an application
>>>>>> uses logging there is no reasons for AWT to not use it.  Please note
>>>>>> that even if logging is turned
>>>>>> off, the application still needs logging package/module.  So, though
>>>>>> end-user doesn't need logging output
>>>>>> she may need logging module to run the application.
>>>>> This is exactly why we want to decouple the dependency on 
>>>>> logging.  When an
>>>>> application uses logging, the application knows clearly what 
>>>>> module they
>>>>> require and that's fine.  When an application doesn't logging, if 
>>>>> the awt
>>>>> component requires logging for debugging purpose only, it 
>>>>> increases the
>>>>> download size, footprint and startup performance (class lookup time,
>>>>> loading, init, etc) - please see my performance analysis report; 
>>>>> otherwise,
>>>>> it's not fruitful to discuss the details in this thread without the
>>>>> background info.  Just to mention it what we care about.
>>>>
>>>> I have found only two links to some performance analysis:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html 
>>>>
>>>> http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64 
>>>>
>>>>
>>>> but they say about -Xverify and -Xshare and do not understand how they
>>>> can be related
>>>> to our topic :(  If they do, please explain (I have never been an
>>>> expert in this area :(
>>>> Or, if I missed something could you please point me what I have 
>>>> missed.
>>>>
>>>>
>>>>>> So, it is really
>>>>>> important to understand
>>>>>> what number of application will get advantage of suggested changes.
>>>>>>
>>>>>>
>>>>> You are suggesting the client applications always have a 
>>>>> dependency on
>>>>> logging.   Many client team engineers are happy to see the 
>>>>> dependency on
>>>>> logging being eliminated from the client stack requirement and 
>>>>> approve this
>>>>> fix :)
>>>>
>>>> I do not see how this can be considered as prove that the changes will
>>>> help client applications.
>>>> Unless we have some statistic it is all just our guess (which, as we
>>>> know, usually wrong ;)
>>>>
>>>>
>>>>>> Second question is: how big logging module is going to be? How 
>>>>>> big the
>>>>>> benefit for end-user will be?
>>>>>>
>>>>>>
>>>>> The size of the logging API is not big (~90K) but the size is not 
>>>>> the only
>>>>> one factor determining what benefit the end-user will have.
>>>>
>>>> what other factors do you know?
>>>>
>>>>
>>>>>  It's not
>>>>> necessary to logging API as one single module and details are to 
>>>>> be worked
>>>>> out.   Subscribe to the jigsaw project to follow the discussion 
>>>>> and progress
>>>>> there.   Serviceability includes other API as well.  If awt 
>>>>> started using
>>>>> other serviceability API (java.lang.management, 
>>>>> java.lang.instrument) for
>>>>> whatever reason, your argument would apply there as well.  I don't 
>>>>> think you
>>>>> wanted the awt module depends on all the serviceability APIs.
>>>>
>>>> I agree that usage of any API should be done after careful 
>>>> consideration.
>>>> Logging API provides us exactly what we need (ability to create log of
>>>> an application
>>>> executed on client)  this is why we started to use it.
>>>>
>>>>
>>>>>> I'm asking so many question mainly because the changes you suggested
>>>>>> create rather unnatural code (we can not
>>>>>> use standard logging machinery any more), so such changes should be
>>>>>> well-justified.
>>>>>>
>>>>>>
>>>>> That's what we pay for to modularize the JDK after many years of JDK
>>>>> development without module support in the platform.  Otherwise, if 
>>>>> there
>>>>> were module support in the platform, you would consider very 
>>>>> carefully when
>>>>> adding a dependency on another module.
>>>>
>>>> perhaps you are right, but in case of logging I would expect that 
>>>> we'd use it
>>>> anyway.
>>>>
>>>> Oleg.
>>>>
>>>>
>>>>> If you have further issue, I suggest to start a different thread 
>>>>> on the
>>>>> awt-dev alias.
>>>>>
>>>>> Thanks
>>>>> Mandy
>>>>> [1] http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
>>>>>
>>>
>


From Andrei.Dmitriev at Sun.COM  Tue Sep 22 13:09:10 2009
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Wed, 23 Sep 2009 00:09:10 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4AB90721.2060509@Sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
Message-ID: <4AB92EE6.8070603@sun.com>

Mandy Chung wrote:
> (I took the core-libs-dev off as this is about awt/2d/swing discussion).
>
> The main question is whether the client stack wants to require the 
> dependency on logging when the JDK is broken down into fine-grained 
> module.   It is fine to wait until the jigsaw module system is ready 
> to provide the performance numbers for you to evaluate.
>
> Some clarification inlined below.
>
> Andrei Dmitriev wrote:
>> Hi Mandy, Oleg,
>>
>> I'm going to summarize pros and cons of this change just to make 
>> judge (basically for myself).
>>
>> 1) we can't expect a significant memory gain (the numbers are ~90Kb). 
>> That's a minus.
>
> I would not say it's a minus as it doesn't have negative impact.
Ok.
>
>> 2) we decouple awt/swing/2d with logging package which is a Plus in a 
>> view of jigsaw. See 6) for more.
>> 3) we don't have time measures for this change. That's a minus.
>
> This statement isn't true.  This should be "no significant perf 
> improvement" for this fix and the perf improvment is not the goal for 
> this fix.
Oh, ok, that what I wanted to learn.
.
>
> I did run the refworkload startup benchmark.  But the numbers confirm 
> that there is no significant improvement as expected.
>
> ============================================================================== 
>
> mchung.baseline.b70:
>   Benchmark           Samples        Mean     Stdev             
> Geomean Weight
>   startup3                 30        2.33      0.05
>     Framer                 30        0.30      0.01             0.03
>     JEdit                  30        1.71      0.11             0.30
>     LimeWire               30        2.21      0.06             0.30
>     NetBeans               30        7.38      0.14             0.30
>     Noop                   30        0.11      0.00             0.03
>     XFramer                30        0.30      0.00             0.04
> ============================================================================== 
>
> mchung.platform.logging:
>   Benchmark           Samples        Mean     Stdev   %Diff     P 
> Significant
>   startup3                 30        2.34      0.05   -0.22 0.684       *
>     Framer                 30        0.30      0.00    0.33 0.326       *
>     JEdit                  30        1.70      0.09    0.99 0.522       *
>     LimeWire               30        2.24      0.05   -1.56 0.025       *
>     NetBeans               30        7.37      0.06    0.08 0.833       *
>     Noop                   30        0.11      0.02   -3.94 0.326       *
>     XFramer                30        0.30      0.00    0.22 0.310       *
> ============================================================================== 
>
>   * - Not Significant: A non-zero %Diff for the mean could be noise. 
> If the
>       %Diff is 0, an actual difference may still exist. In either 
> case, more
>       samples would be needed to detect an actual difference in sample 
> means.
>
>> 4) nobody measured anything else than Framer and SwingSet. That's a 
>> minus.
>
> As I said, the fix is to eliminate the dependency on logging.  I'm not 
> sure what measurement you want to do.
Yeah, I see.
>
>> 5) we lose flexibility on debugging. That's a minus.
>
> This statement isn't true.  AWT debugging ability is unchanged.
To be honest, I used client logging not so often and that was only 
required for customer's sites. We get rid of loggers... but I'll still 
could run same logging as before?!

What about 6)? Will we bother with other parts of JDK or leave it for a 
later time?
And any thoughts about 7)?

Thanks,
  Andrei
>
> Mandy
>
>> 6) this fix don't decouple anything else awt/swing/2d.
>> I made a grep on "Logger.getLogger" and there are entries from xml, 
>> jmx, etc. That means we have to deal with them as well too (as it 
>> causes the class to be loaded anyway), if we aware of jigsaw.
>> 7) In most cases AWT initiates classes statically but basically may 
>> want to do that lazily. That's minus. I'd consider initialization in 
>> CTOR at first and see the impact. Believe SwingSet would show enough 
>> here. If not, that's the reason to go further to... well to check if 
>> the Java property set.
>>
>> Now, I don't see the evaluation is completed to make the decision. 
>> And if we could modify client code in the way that Framer will never 
>> initialize or/and load Logger (et al) classes so we achieved the goal.
>>
>> Thanks,
>>  Andrei
>>
>> Oleg Sukhodolsky wrote:
>>> HI Mandy,
>>>
>>> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <Mandy.Chung at sun.com> 
>>> wrote:
>>>  
>>>> 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 the logging 
>>>> API is
>>>> to support maintaining and servicing software at customer sites.   
>>>> Adding
>>>> debugging code in the awt implementation using logging API is 
>>>> reasonable but
>>>> it's not the requirement for the logging API.  If there were a 
>>>> better option
>>>> to add debugging code, I believe you have no problem changing the awt
>>>> debugging code not to use the logging API.
>>>>
>>>> Server-type applications are typical use cases that logging 
>>>> information is
>>>> very important and useful for diagnosis in the field - long running 
>>>> apps,
>>>> hard to reproduce problems until running for many days/months.  It 
>>>> is hard
>>>> to imagine how the logging information is important in client 
>>>> applications.
>>>>     
>>>
>>> as ex-AWT developer I can confirm that there were number of cases when
>>> logging had helped us to diagnose problem on client's site.  Even
>>> though you usually
>>> do not need to run an application for a long time to reproduce a 
>>> problem
>>> it can be very hard to reproduce it because the problem depends on
>>> window manager
>>> and other environment which is hard to re-create.
>>>
>>>  
>>>>   But you seem to know many client applications use the logging API 
>>>> that I
>>>> would also be interested to follow up with their requirements.
>>>>     
>>>
>>> I do not know many client applications which uses logging API 
>>> (because I have
>>> never write real client application) and it is hard to say if it uses
>>> logging or not.
>>> I hoped that you who saying that suggested changes will help to client
>>> application
>>> has some statistic to confirm your expectation
>>>
>>>  
>>>>> Ok, so this fix is only about modules.  But why AWT should not depend
>>>>> on logging module?
>>>>> The qiestion is: how many application we want to run doesn't use
>>>>> logging& Because if an application
>>>>> uses logging there is no reasons for AWT to not use it.  Please note
>>>>> that even if logging is turned
>>>>> off, the application still needs logging package/module.  So, though
>>>>> end-user doesn't need logging output
>>>>> she may need logging module to run the application.
>>>>>       
>>>> This is exactly why we want to decouple the dependency on logging.  
>>>> When an
>>>> application uses logging, the application knows clearly what module 
>>>> they
>>>> require and that's fine.  When an application doesn't logging, if 
>>>> the awt
>>>> component requires logging for debugging purpose only, it increases 
>>>> the
>>>> download size, footprint and startup performance (class lookup time,
>>>> loading, init, etc) - please see my performance analysis report; 
>>>> otherwise,
>>>> it's not fruitful to discuss the details in this thread without the
>>>> background info.  Just to mention it what we care about.
>>>>     
>>>
>>> I have found only two links to some performance analysis:
>>>
>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
>>> http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64 
>>>
>>>
>>> but they say about -Xverify and -Xshare and do not understand how they
>>> can be related
>>> to our topic :(  If they do, please explain (I have never been an
>>> expert in this area :(
>>> Or, if I missed something could you please point me what I have missed.
>>>
>>>  
>>>>> So, it is really
>>>>> important to understand
>>>>> what number of application will get advantage of suggested changes.
>>>>>
>>>>>
>>>>>       
>>>> You are suggesting the client applications always have a dependency on
>>>> logging.   Many client team engineers are happy to see the 
>>>> dependency on
>>>> logging being eliminated from the client stack requirement and 
>>>> approve this
>>>> fix :)
>>>>     
>>>
>>> I do not see how this can be considered as prove that the changes will
>>> help client applications.
>>> Unless we have some statistic it is all just our guess (which, as we
>>> know, usually wrong ;)
>>>
>>>  
>>>>> Second question is: how big logging module is going to be? How big 
>>>>> the
>>>>> benefit for end-user will be?
>>>>>
>>>>>
>>>>>       
>>>> The size of the logging API is not big (~90K) but the size is not 
>>>> the only
>>>> one factor determining what benefit the end-user will have.
>>>>     
>>>
>>> what other factors do you know?
>>>
>>>  
>>>>  It's not
>>>> necessary to logging API as one single module and details are to be 
>>>> worked
>>>> out.   Subscribe to the jigsaw project to follow the discussion and 
>>>> progress
>>>> there.   Serviceability includes other API as well.  If awt started 
>>>> using
>>>> other serviceability API (java.lang.management, 
>>>> java.lang.instrument) for
>>>> whatever reason, your argument would apply there as well.  I don't 
>>>> think you
>>>> wanted the awt module depends on all the serviceability APIs.
>>>>     
>>>
>>> I agree that usage of any API should be done after careful 
>>> consideration.
>>> Logging API provides us exactly what we need (ability to create log of
>>> an application
>>> executed on client)  this is why we started to use it.
>>>
>>>  
>>>>> I'm asking so many question mainly because the changes you suggested
>>>>> create rather unnatural code (we can not
>>>>> use standard logging machinery any more), so such changes should be
>>>>> well-justified.
>>>>>
>>>>>
>>>>>       
>>>> That's what we pay for to modularize the JDK after many years of JDK
>>>> development without module support in the platform.  Otherwise, if 
>>>> there
>>>> were module support in the platform, you would consider very 
>>>> carefully when
>>>> adding a dependency on another module.
>>>>     
>>>
>>> perhaps you are right, but in case of logging I would expect that 
>>> we'd use it
>>> anyway.
>>>
>>> Oleg.
>>>
>>>  
>>>> If you have further issue, I suggest to start a different thread on 
>>>> the
>>>> awt-dev alias.
>>>>
>>>> Thanks
>>>> Mandy
>>>> [1] http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
>>>>
>>>>     
>>


From Andrei.Dmitriev at Sun.COM  Tue Sep 22 13:22:04 2009
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Wed, 23 Sep 2009 00:22:04 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]    Review Request for 6879044
In-Reply-To: <4AB917BB.4060403@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
	<4AB910D9.2090709@sun.com> <4AB917BB.4060403@sun.com>
Message-ID: <4AB931EC.9010207@sun.com>


Igor Nekrestyanov wrote:
> Let me clarify this as it is does not directly translate into 3x 
> footprint.
> But savings are not just "size of classes to be loaded".
>
>  Common "core" classes are also included into shared archive 
> (classes.jsa) and removing logging classes
> from the "core" will reduce size of classes.jsa (which is mmap-ed to 
> the memory on Windows).
> Note that we may read same class from rt.jar too if it happens to be 
> in the same block as other class we need.
Oh, I got it. In other words you are trying not to cache Loggers in 
classes.jsa and nothing else classes.jsa will be mmap-ed to the memory? 
That sounds promising.

>
> It will also reduce java quickstarter "read set" and this will make 
> jqs more user friendly (less load on the system,
> smaller portion of disk cache taken for java stuff).
>
> None of these changes is "stunning" per se. But they sum up.
> (This does not mean that Mandy's approach is the only way to go, if 
> someone can suggest how to improve logging package to
> get same savings and preserve backward compatibility - this will be 
> even better.)
We could make local to AWT changes with respect to loggers as described 
in 7).
Thanks,
  Andrei

> -igor
>
> On 9/22/09 11:00 AM, Igor Nekrestyanov wrote:
>> BTW, note that reducing set of required core classes will save 3x of 
>> memory at least (think of jqs and classes.jsa in addition to rt.jar 
>> (on windows)).
>>
>> -igor
>>
>> On 9/22/09 10:19 AM, Mandy Chung wrote:
>>> (I took the core-libs-dev off as this is about awt/2d/swing 
>>> discussion).
>>>
>>> The main question is whether the client stack wants to require the 
>>> dependency on logging when the JDK is broken down into fine-grained 
>>> module.   It is fine to wait until the jigsaw module system is ready 
>>> to provide the performance numbers for you to evaluate.
>>>
>>> Some clarification inlined below.
>>>
>>> Andrei Dmitriev wrote:
>>>> Hi Mandy, Oleg,
>>>>
>>>> I'm going to summarize pros and cons of this change just to make 
>>>> judge (basically for myself).
>>>>
>>>> 1) we can't expect a significant memory gain (the numbers are 
>>>> ~90Kb). That's a minus.
>>>
>>> I would not say it's a minus as it doesn't have negative impact.
>>>
>>>> 2) we decouple awt/swing/2d with logging package which is a Plus in 
>>>> a view of jigsaw. See 6) for more.
>>>> 3) we don't have time measures for this change. That's a minus.
>>>
>>> This statement isn't true.  This should be "no significant perf 
>>> improvement" for this fix and the perf improvment is not the goal 
>>> for this fix.
>>>
>>> I did run the refworkload startup benchmark.  But the numbers 
>>> confirm that there is no significant improvement as expected.
>>>
>>> ============================================================================== 
>>>
>>> mchung.baseline.b70:
>>>   Benchmark           Samples        Mean     Stdev             
>>> Geomean Weight
>>>   startup3                 30        2.33      0.05
>>>     Framer                 30        0.30      0.01             0.03
>>>     JEdit                  30        1.71      0.11             0.30
>>>     LimeWire               30        2.21      0.06             0.30
>>>     NetBeans               30        7.38      0.14             0.30
>>>     Noop                   30        0.11      0.00             0.03
>>>     XFramer                30        0.30      0.00             0.04
>>> ============================================================================== 
>>>
>>> mchung.platform.logging:
>>>   Benchmark           Samples        Mean     Stdev   %Diff     P 
>>> Significant
>>>   startup3                 30        2.34      0.05   -0.22 
>>> 0.684       *
>>>     Framer                 30        0.30      0.00    0.33 
>>> 0.326       *
>>>     JEdit                  30        1.70      0.09    0.99 
>>> 0.522       *
>>>     LimeWire               30        2.24      0.05   -1.56 
>>> 0.025       *
>>>     NetBeans               30        7.37      0.06    0.08 
>>> 0.833       *
>>>     Noop                   30        0.11      0.02   -3.94 
>>> 0.326       *
>>>     XFramer                30        0.30      0.00    0.22 
>>> 0.310       *
>>> ============================================================================== 
>>>
>>>   * - Not Significant: A non-zero %Diff for the mean could be noise. 
>>> If the
>>>       %Diff is 0, an actual difference may still exist. In either 
>>> case, more
>>>       samples would be needed to detect an actual difference in 
>>> sample means.
>>>
>>>> 4) nobody measured anything else than Framer and SwingSet. That's a 
>>>> minus.
>>>
>>> As I said, the fix is to eliminate the dependency on logging.  I'm 
>>> not sure what measurement you want to do.
>>>
>>>> 5) we lose flexibility on debugging. That's a minus.
>>>
>>> This statement isn't true.  AWT debugging ability is unchanged.
>>>
>>> Mandy
>>>
>>>> 6) this fix don't decouple anything else awt/swing/2d.
>>>> I made a grep on "Logger.getLogger" and there are entries from xml, 
>>>> jmx, etc. That means we have to deal with them as well too (as it 
>>>> causes the class to be loaded anyway), if we aware of jigsaw.
>>>> 7) In most cases AWT initiates classes statically but basically may 
>>>> want to do that lazily. That's minus. I'd consider initialization 
>>>> in CTOR at first and see the impact. Believe SwingSet would show 
>>>> enough here. If not, that's the reason to go further to... well to 
>>>> check if the Java property set.
>>>>
>>>> Now, I don't see the evaluation is completed to make the decision. 
>>>> And if we could modify client code in the way that Framer will 
>>>> never initialize or/and load Logger (et al) classes so we achieved 
>>>> the goal.
>>>>
>>>> Thanks,
>>>>  Andrei
>>>>
>>>> Oleg Sukhodolsky wrote:
>>>>> HI Mandy,
>>>>>
>>>>> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung 
>>>>> <Mandy.Chung at sun.com> wrote:
>>>>>
>>>>>> 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 the 
>>>>>> logging API is
>>>>>> to support maintaining and servicing software at customer 
>>>>>> sites.   Adding
>>>>>> debugging code in the awt implementation using logging API is 
>>>>>> reasonable but
>>>>>> it's not the requirement for the logging API.  If there were a 
>>>>>> better option
>>>>>> to add debugging code, I believe you have no problem changing the 
>>>>>> awt
>>>>>> debugging code not to use the logging API.
>>>>>>
>>>>>> Server-type applications are typical use cases that logging 
>>>>>> information is
>>>>>> very important and useful for diagnosis in the field - long 
>>>>>> running apps,
>>>>>> hard to reproduce problems until running for many days/months.  
>>>>>> It is hard
>>>>>> to imagine how the logging information is important in client 
>>>>>> applications.
>>>>>
>>>>> as ex-AWT developer I can confirm that there were number of cases 
>>>>> when
>>>>> logging had helped us to diagnose problem on client's site.  Even
>>>>> though you usually
>>>>> do not need to run an application for a long time to reproduce a 
>>>>> problem
>>>>> it can be very hard to reproduce it because the problem depends on
>>>>> window manager
>>>>> and other environment which is hard to re-create.
>>>>>
>>>>>
>>>>>>   But you seem to know many client applications use the logging 
>>>>>> API that I
>>>>>> would also be interested to follow up with their requirements.
>>>>>
>>>>> I do not know many client applications which uses logging API 
>>>>> (because I have
>>>>> never write real client application) and it is hard to say if it uses
>>>>> logging or not.
>>>>> I hoped that you who saying that suggested changes will help to 
>>>>> client
>>>>> application
>>>>> has some statistic to confirm your expectation
>>>>>
>>>>>
>>>>>>> Ok, so this fix is only about modules.  But why AWT should not 
>>>>>>> depend
>>>>>>> on logging module?
>>>>>>> The qiestion is: how many application we want to run doesn't use
>>>>>>> logging& Because if an application
>>>>>>> uses logging there is no reasons for AWT to not use it.  Please 
>>>>>>> note
>>>>>>> that even if logging is turned
>>>>>>> off, the application still needs logging package/module.  So, 
>>>>>>> though
>>>>>>> end-user doesn't need logging output
>>>>>>> she may need logging module to run the application.
>>>>>> This is exactly why we want to decouple the dependency on 
>>>>>> logging.  When an
>>>>>> application uses logging, the application knows clearly what 
>>>>>> module they
>>>>>> require and that's fine.  When an application doesn't logging, if 
>>>>>> the awt
>>>>>> component requires logging for debugging purpose only, it 
>>>>>> increases the
>>>>>> download size, footprint and startup performance (class lookup time,
>>>>>> loading, init, etc) - please see my performance analysis report; 
>>>>>> otherwise,
>>>>>> it's not fruitful to discuss the details in this thread without the
>>>>>> background info.  Just to mention it what we care about.
>>>>>
>>>>> I have found only two links to some performance analysis:
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html 
>>>>>
>>>>> http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64 
>>>>>
>>>>>
>>>>> but they say about -Xverify and -Xshare and do not understand how 
>>>>> they
>>>>> can be related
>>>>> to our topic :(  If they do, please explain (I have never been an
>>>>> expert in this area :(
>>>>> Or, if I missed something could you please point me what I have 
>>>>> missed.
>>>>>
>>>>>
>>>>>>> So, it is really
>>>>>>> important to understand
>>>>>>> what number of application will get advantage of suggested changes.
>>>>>>>
>>>>>>>
>>>>>> You are suggesting the client applications always have a 
>>>>>> dependency on
>>>>>> logging.   Many client team engineers are happy to see the 
>>>>>> dependency on
>>>>>> logging being eliminated from the client stack requirement and 
>>>>>> approve this
>>>>>> fix :)
>>>>>
>>>>> I do not see how this can be considered as prove that the changes 
>>>>> will
>>>>> help client applications.
>>>>> Unless we have some statistic it is all just our guess (which, as we
>>>>> know, usually wrong ;)
>>>>>
>>>>>
>>>>>>> Second question is: how big logging module is going to be? How 
>>>>>>> big the
>>>>>>> benefit for end-user will be?
>>>>>>>
>>>>>>>
>>>>>> The size of the logging API is not big (~90K) but the size is not 
>>>>>> the only
>>>>>> one factor determining what benefit the end-user will have.
>>>>>
>>>>> what other factors do you know?
>>>>>
>>>>>
>>>>>>  It's not
>>>>>> necessary to logging API as one single module and details are to 
>>>>>> be worked
>>>>>> out.   Subscribe to the jigsaw project to follow the discussion 
>>>>>> and progress
>>>>>> there.   Serviceability includes other API as well.  If awt 
>>>>>> started using
>>>>>> other serviceability API (java.lang.management, 
>>>>>> java.lang.instrument) for
>>>>>> whatever reason, your argument would apply there as well.  I 
>>>>>> don't think you
>>>>>> wanted the awt module depends on all the serviceability APIs.
>>>>>
>>>>> I agree that usage of any API should be done after careful 
>>>>> consideration.
>>>>> Logging API provides us exactly what we need (ability to create 
>>>>> log of
>>>>> an application
>>>>> executed on client)  this is why we started to use it.
>>>>>
>>>>>
>>>>>>> I'm asking so many question mainly because the changes you 
>>>>>>> suggested
>>>>>>> create rather unnatural code (we can not
>>>>>>> use standard logging machinery any more), so such changes should be
>>>>>>> well-justified.
>>>>>>>
>>>>>>>
>>>>>> That's what we pay for to modularize the JDK after many years of JDK
>>>>>> development without module support in the platform.  Otherwise, 
>>>>>> if there
>>>>>> were module support in the platform, you would consider very 
>>>>>> carefully when
>>>>>> adding a dependency on another module.
>>>>>
>>>>> perhaps you are right, but in case of logging I would expect that 
>>>>> we'd use it
>>>>> anyway.
>>>>>
>>>>> Oleg.
>>>>>
>>>>>
>>>>>> If you have further issue, I suggest to start a different thread 
>>>>>> on the
>>>>>> awt-dev alias.
>>>>>>
>>>>>> Thanks
>>>>>> Mandy
>>>>>> [1] 
>>>>>> http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
>>>>>>
>>>>
>>
>


From Anthony.Petrov at Sun.COM  Wed Sep 23 03:33:16 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 23 Sep 2009 14:33:16 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4AB90721.2060509@Sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
Message-ID: <4AB9F96C.90303@sun.com>

Hi Mandy,

If AWT initialized the loggers lazily, and only did it when the logging 
is actually enabled (checking for some system property, or whatever 
other way), would we still be statically linked to the j.u.logging 
package in case of a regular client application that does not use/enable 
logging explicitly?

--
best regards,
Anthony


On 09/22/2009 09:19 PM, Mandy Chung wrote:
> (I took the core-libs-dev off as this is about awt/2d/swing discussion).
> 
> The main question is whether the client stack wants to require the 
> dependency on logging when the JDK is broken down into fine-grained 
> module.   It is fine to wait until the jigsaw module system is ready to 
> provide the performance numbers for you to evaluate.
> 
> Some clarification inlined below.
> 
> Andrei Dmitriev wrote:
>> Hi Mandy, Oleg,
>>
>> I'm going to summarize pros and cons of this change just to make judge 
>> (basically for myself).
>>
>> 1) we can't expect a significant memory gain (the numbers are ~90Kb). 
>> That's a minus.
> 
> I would not say it's a minus as it doesn't have negative impact.
> 
>> 2) we decouple awt/swing/2d with logging package which is a Plus in a 
>> view of jigsaw. See 6) for more.
>> 3) we don't have time measures for this change. That's a minus.
> 
> This statement isn't true.  This should be "no significant perf 
> improvement" for this fix and the perf improvment is not the goal for 
> this fix.
> 
> I did run the refworkload startup benchmark.  But the numbers confirm 
> that there is no significant improvement as expected.
> 
> ============================================================================== 
> 
> mchung.baseline.b70:
>   Benchmark           Samples        Mean     Stdev             Geomean 
> Weight
>   startup3                 30        2.33      0.05
>     Framer                 30        0.30      0.01             0.03
>     JEdit                  30        1.71      0.11             0.30
>     LimeWire               30        2.21      0.06             0.30
>     NetBeans               30        7.38      0.14             0.30
>     Noop                   30        0.11      0.00             0.03
>     XFramer                30        0.30      0.00             0.04
> ============================================================================== 
> 
> mchung.platform.logging:
>   Benchmark           Samples        Mean     Stdev   %Diff     P 
> Significant
>   startup3                 30        2.34      0.05   -0.22 0.684       *
>     Framer                 30        0.30      0.00    0.33 0.326       *
>     JEdit                  30        1.70      0.09    0.99 0.522       *
>     LimeWire               30        2.24      0.05   -1.56 0.025       *
>     NetBeans               30        7.37      0.06    0.08 0.833       *
>     Noop                   30        0.11      0.02   -3.94 0.326       *
>     XFramer                30        0.30      0.00    0.22 0.310       *
> ============================================================================== 
> 
>   * - Not Significant: A non-zero %Diff for the mean could be noise. If the
>       %Diff is 0, an actual difference may still exist. In either case, 
> more
>       samples would be needed to detect an actual difference in sample 
> means.
> 
>> 4) nobody measured anything else than Framer and SwingSet. That's a 
>> minus.
> 
> As I said, the fix is to eliminate the dependency on logging.  I'm not 
> sure what measurement you want to do.
> 
>> 5) we lose flexibility on debugging. That's a minus.
> 
> This statement isn't true.  AWT debugging ability is unchanged.
> 
> Mandy
> 
>> 6) this fix don't decouple anything else awt/swing/2d.
>> I made a grep on "Logger.getLogger" and there are entries from xml, 
>> jmx, etc. That means we have to deal with them as well too (as it 
>> causes the class to be loaded anyway), if we aware of jigsaw.
>> 7) In most cases AWT initiates classes statically but basically may 
>> want to do that lazily. That's minus. I'd consider initialization in 
>> CTOR at first and see the impact. Believe SwingSet would show enough 
>> here. If not, that's the reason to go further to... well to check if 
>> the Java property set.
>>
>> Now, I don't see the evaluation is completed to make the decision. And 
>> if we could modify client code in the way that Framer will never 
>> initialize or/and load Logger (et al) classes so we achieved the goal.
>>
>> Thanks,
>>  Andrei
>>
>> Oleg Sukhodolsky wrote:
>>> HI Mandy,
>>>
>>> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <Mandy.Chung at sun.com> 
>>> wrote:
>>>  
>>>> 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 the logging 
>>>> API is
>>>> to support maintaining and servicing software at customer sites.   
>>>> Adding
>>>> debugging code in the awt implementation using logging API is 
>>>> reasonable but
>>>> it's not the requirement for the logging API.  If there were a 
>>>> better option
>>>> to add debugging code, I believe you have no problem changing the awt
>>>> debugging code not to use the logging API.
>>>>
>>>> Server-type applications are typical use cases that logging 
>>>> information is
>>>> very important and useful for diagnosis in the field - long running 
>>>> apps,
>>>> hard to reproduce problems until running for many days/months.  It 
>>>> is hard
>>>> to imagine how the logging information is important in client 
>>>> applications.
>>>>     
>>>
>>> as ex-AWT developer I can confirm that there were number of cases when
>>> logging had helped us to diagnose problem on client's site.  Even
>>> though you usually
>>> do not need to run an application for a long time to reproduce a problem
>>> it can be very hard to reproduce it because the problem depends on
>>> window manager
>>> and other environment which is hard to re-create.
>>>
>>>  
>>>>   But you seem to know many client applications use the logging API 
>>>> that I
>>>> would also be interested to follow up with their requirements.
>>>>     
>>>
>>> I do not know many client applications which uses logging API 
>>> (because I have
>>> never write real client application) and it is hard to say if it uses
>>> logging or not.
>>> I hoped that you who saying that suggested changes will help to client
>>> application
>>> has some statistic to confirm your expectation
>>>
>>>  
>>>>> Ok, so this fix is only about modules.  But why AWT should not depend
>>>>> on logging module?
>>>>> The qiestion is: how many application we want to run doesn't use
>>>>> logging& Because if an application
>>>>> uses logging there is no reasons for AWT to not use it.  Please note
>>>>> that even if logging is turned
>>>>> off, the application still needs logging package/module.  So, though
>>>>> end-user doesn't need logging output
>>>>> she may need logging module to run the application.
>>>>>       
>>>> This is exactly why we want to decouple the dependency on logging.  
>>>> When an
>>>> application uses logging, the application knows clearly what module 
>>>> they
>>>> require and that's fine.  When an application doesn't logging, if 
>>>> the awt
>>>> component requires logging for debugging purpose only, it increases the
>>>> download size, footprint and startup performance (class lookup time,
>>>> loading, init, etc) - please see my performance analysis report; 
>>>> otherwise,
>>>> it's not fruitful to discuss the details in this thread without the
>>>> background info.  Just to mention it what we care about.
>>>>     
>>>
>>> I have found only two links to some performance analysis:
>>>
>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
>>> http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64 
>>>
>>>
>>> but they say about -Xverify and -Xshare and do not understand how they
>>> can be related
>>> to our topic :(  If they do, please explain (I have never been an
>>> expert in this area :(
>>> Or, if I missed something could you please point me what I have missed.
>>>
>>>  
>>>>> So, it is really
>>>>> important to understand
>>>>> what number of application will get advantage of suggested changes.
>>>>>
>>>>>
>>>>>       
>>>> You are suggesting the client applications always have a dependency on
>>>> logging.   Many client team engineers are happy to see the 
>>>> dependency on
>>>> logging being eliminated from the client stack requirement and 
>>>> approve this
>>>> fix :)
>>>>     
>>>
>>> I do not see how this can be considered as prove that the changes will
>>> help client applications.
>>> Unless we have some statistic it is all just our guess (which, as we
>>> know, usually wrong ;)
>>>
>>>  
>>>>> Second question is: how big logging module is going to be? How big the
>>>>> benefit for end-user will be?
>>>>>
>>>>>
>>>>>       
>>>> The size of the logging API is not big (~90K) but the size is not 
>>>> the only
>>>> one factor determining what benefit the end-user will have.
>>>>     
>>>
>>> what other factors do you know?
>>>
>>>  
>>>>  It's not
>>>> necessary to logging API as one single module and details are to be 
>>>> worked
>>>> out.   Subscribe to the jigsaw project to follow the discussion and 
>>>> progress
>>>> there.   Serviceability includes other API as well.  If awt started 
>>>> using
>>>> other serviceability API (java.lang.management, 
>>>> java.lang.instrument) for
>>>> whatever reason, your argument would apply there as well.  I don't 
>>>> think you
>>>> wanted the awt module depends on all the serviceability APIs.
>>>>     
>>>
>>> I agree that usage of any API should be done after careful 
>>> consideration.
>>> Logging API provides us exactly what we need (ability to create log of
>>> an application
>>> executed on client)  this is why we started to use it.
>>>
>>>  
>>>>> I'm asking so many question mainly because the changes you suggested
>>>>> create rather unnatural code (we can not
>>>>> use standard logging machinery any more), so such changes should be
>>>>> well-justified.
>>>>>
>>>>>
>>>>>       
>>>> That's what we pay for to modularize the JDK after many years of JDK
>>>> development without module support in the platform.  Otherwise, if 
>>>> there
>>>> were module support in the platform, you would consider very 
>>>> carefully when
>>>> adding a dependency on another module.
>>>>     
>>>
>>> perhaps you are right, but in case of logging I would expect that 
>>> we'd use it
>>> anyway.
>>>
>>> Oleg.
>>>
>>>  
>>>> If you have further issue, I suggest to start a different thread on the
>>>> awt-dev alias.
>>>>
>>>> Thanks
>>>> Mandy
>>>> [1] http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
>>>>
>>>>     
>>

From Alan.Bateman at Sun.COM  Wed Sep 23 04:41:43 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 23 Sep 2009 12:41:43 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4AB9F96C.90303@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
	<4AB9F96C.90303@sun.com>
Message-ID: <4ABA0977.8060501@sun.com>

Anthony Petrov wrote:
> Hi Mandy,
>
> If AWT initialized the loggers lazily, and only did it when the 
> logging is actually enabled (checking for some system property, or 
> whatever other way), would we still be statically linked to the 
> j.u.logging package in case of a regular client application that does 
> not use/enable logging explicitly?
Yes, minimally they should be created lazily (this is one of the 
suggestions that Mandy listed in 6880089). That would at least avoid 
initializing all these loggers. The static dependency remains.

-Alan.

From Anthony.Petrov at Sun.COM  Wed Sep 23 05:08:29 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 23 Sep 2009 16:08:29 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4ABA0977.8060501@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
	<4AB9F96C.90303@sun.com> <4ABA0977.8060501@sun.com>
Message-ID: <4ABA0FBD.5030901@sun.com>

On 09/23/2009 03:41 PM, Alan Bateman wrote:
>> If AWT initialized the loggers lazily, and only did it when the 
>> logging is actually enabled (checking for some system property, or 
>> whatever other way), would we still be statically linked to the 
>> j.u.logging package in case of a regular client application that does 
>> not use/enable logging explicitly?
> Yes, minimally they should be created lazily (this is one of the 
> suggestions that Mandy listed in 6880089). That would at least avoid 
> initializing all these loggers. The static dependency remains.

Ah, I just looked over the PlatformLogger code, and now I see it uses 
reflection to access the j.u.logging.* classes. Now this point is clear.

Have it been discussed whether that is feasible to modify the VM in 
order to eliminate the static dependency if a particular object never 
gets initialized?

It just looks kind of artificial to create such proxy classes. I bet 
we'll need plenty of them for other modules. Won't the code be messed up 
too much?

--
best regards,
Anthony

From Mandy.Chung at Sun.COM  Wed Sep 23 09:15:12 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Wed, 23 Sep 2009 09:15:12 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4ABA0FBD.5030901@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
	<4AB9F96C.90303@sun.com>
	<4ABA0977.8060501@sun.com> <4ABA0FBD.5030901@sun.com>
Message-ID: <4ABA4990.9060501@Sun.com>

Anthony Petrov wrote:
> On 09/23/2009 03:41 PM, Alan Bateman wrote:
>>> If AWT initialized the loggers lazily, and only did it when the 
>>> logging is actually enabled (checking for some system property, or 
>>> whatever other way), would we still be statically linked to the 
>>> j.u.logging package in case of a regular client application that does 
>>> not use/enable logging explicitly?
>> Yes, minimally they should be created lazily (this is one of the 
>> suggestions that Mandy listed in 6880089). That would at least avoid 
>> initializing all these loggers. The static dependency remains.
> 
> Ah, I just looked over the PlatformLogger code, and now I see it uses 
> reflection to access the j.u.logging.* classes. Now this point is clear.
> 
> Have it been discussed whether that is feasible to modify the VM in 
> order to eliminate the static dependency if a particular object never 
> gets initialized?

The HotSpot VM does lazy resolution and it doesn't load the type of an 
object if it's not initialized.

Static dependency refers to the types referenced in a class file (i.e. 
any types directly referenced in the source).

Mandy

> It just looks kind of artificial to create such proxy classes. I bet 
> we'll need plenty of them for other modules. Won't the code be messed up 
> too much?
> 
> -- 
> best regards,
> Anthony

From mwong at redhat.com  Wed Sep 23 10:54:08 2009
From: mwong at redhat.com (Man Wong)
Date: Wed, 23 Sep 2009 13:54:08 -0400 (EDT)
Subject: <AWT Dev> Patch for review: TestDialogTypeAhead
In-Reply-To: <1038136880.488901253728315944.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1523174107.489001253728448422.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hi,

Webrev: http://icedtea.classpath.org/~mwong/webrevs/index.html

Summary: This is about jtreg bug in openjdk7, TestDialogTypeAhead ({openjdkdir}/jdk/test/java/awt/KeyboardFocusManager/TypeAhead
         /TestDialogTypeAhead.java). It relates to bug ID 6446952, which in the test itself includes a workaround and that causes it to fail in fedora
         10/11. After removing the work around, as in my webrev, the test passes. Does the fix look ok to push to the awt forest? Any comments? 
         Thanks.     

Man Lung Wong

From Anthony.Petrov at Sun.COM  Wed Sep 23 11:58:32 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 23 Sep 2009 22:58:32 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]  Review Request for 6879044
In-Reply-To: <4ABA4990.9060501@Sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
	<4AB9F96C.90303@sun.com>
	<4ABA0977.8060501@sun.com> <4ABA0FBD.5030901@sun.com>
	<4ABA4990.9060501@Sun.com>
Message-ID: <4ABA6FD8.1020202@sun.com>

On 9/23/2009 8:15 PM Mandy Chung wrote:
>> Have it been discussed whether that is feasible to modify the VM in 
>> order to eliminate the static dependency if a particular object never 
>> gets initialized?
> 
> The HotSpot VM does lazy resolution and it doesn't load the type of an 
> object if it's not initialized.
> 
> Static dependency refers to the types referenced in a class file (i.e. 
> any types directly referenced in the source).

So my question is: would it be possible to modify the component 
responsible for this sort of dependency (I presume it must be some class 
loader, right?) so that it would not load the classes until an instance 
of a class gets initialized, or static methods get accessed, or the type 
information gets requested (like Logger.class...)? In other words, if a 
class has an *unused* field of type 'reference to an object of type T', 
the class T would not be loaded at all until it really gets used in some 
way.

Has that kind of solution been discussed?

--
best regards,
Anthony

From Andrei.Dmitriev at Sun.COM  Fri Sep 25 04:26:14 2009
From: Andrei.Dmitriev at Sun.COM (Andrei Dmitriev)
Date: Fri, 25 Sep 2009 15:26:14 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev]    Review Request for 6879044
In-Reply-To: <4AB931EC.9010207@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
	<4AB910D9.2090709@sun.com> <4AB917BB.4060403@sun.com>
	<4AB931EC.9010207@sun.com>
Message-ID: <4ABCA8D6.6060203@sun.com>

We've chatted with Igor and I see no concern. Ok from my side.
Thanks,
  Andrei

Andrei V. Dmitriev wrote:
>
> Igor Nekrestyanov wrote:
>> Let me clarify this as it is does not directly translate into 3x 
>> footprint.
>> But savings are not just "size of classes to be loaded".
>>
>>  Common "core" classes are also included into shared archive 
>> (classes.jsa) and removing logging classes
>> from the "core" will reduce size of classes.jsa (which is mmap-ed to 
>> the memory on Windows).
>> Note that we may read same class from rt.jar too if it happens to be 
>> in the same block as other class we need.
> Oh, I got it. In other words you are trying not to cache Loggers in 
> classes.jsa and nothing else classes.jsa will be mmap-ed to the 
> memory? That sounds promising.
>
>>
>> It will also reduce java quickstarter "read set" and this will make 
>> jqs more user friendly (less load on the system,
>> smaller portion of disk cache taken for java stuff).
>>
>> None of these changes is "stunning" per se. But they sum up.
>> (This does not mean that Mandy's approach is the only way to go, if 
>> someone can suggest how to improve logging package to
>> get same savings and preserve backward compatibility - this will be 
>> even better.)
> We could make local to AWT changes with respect to loggers as 
> described in 7).
> Thanks,
>  Andrei
>
>> -igor
>>
>> On 9/22/09 11:00 AM, Igor Nekrestyanov wrote:
>>> BTW, note that reducing set of required core classes will save 3x of 
>>> memory at least (think of jqs and classes.jsa in addition to rt.jar 
>>> (on windows)).
>>>
>>> -igor
>>>
>>> On 9/22/09 10:19 AM, Mandy Chung wrote:
>>>> (I took the core-libs-dev off as this is about awt/2d/swing 
>>>> discussion).
>>>>
>>>> The main question is whether the client stack wants to require the 
>>>> dependency on logging when the JDK is broken down into fine-grained 
>>>> module.   It is fine to wait until the jigsaw module system is 
>>>> ready to provide the performance numbers for you to evaluate.
>>>>
>>>> Some clarification inlined below.
>>>>
>>>> Andrei Dmitriev wrote:
>>>>> Hi Mandy, Oleg,
>>>>>
>>>>> I'm going to summarize pros and cons of this change just to make 
>>>>> judge (basically for myself).
>>>>>
>>>>> 1) we can't expect a significant memory gain (the numbers are 
>>>>> ~90Kb). That's a minus.
>>>>
>>>> I would not say it's a minus as it doesn't have negative impact.
>>>>
>>>>> 2) we decouple awt/swing/2d with logging package which is a Plus 
>>>>> in a view of jigsaw. See 6) for more.
>>>>> 3) we don't have time measures for this change. That's a minus.
>>>>
>>>> This statement isn't true.  This should be "no significant perf 
>>>> improvement" for this fix and the perf improvment is not the goal 
>>>> for this fix.
>>>>
>>>> I did run the refworkload startup benchmark.  But the numbers 
>>>> confirm that there is no significant improvement as expected.
>>>>
>>>> ============================================================================== 
>>>>
>>>> mchung.baseline.b70:
>>>>   Benchmark           Samples        Mean     Stdev             
>>>> Geomean Weight
>>>>   startup3                 30        2.33      0.05
>>>>     Framer                 30        0.30      0.01             0.03
>>>>     JEdit                  30        1.71      0.11             0.30
>>>>     LimeWire               30        2.21      0.06             0.30
>>>>     NetBeans               30        7.38      0.14             0.30
>>>>     Noop                   30        0.11      0.00             0.03
>>>>     XFramer                30        0.30      0.00             0.04
>>>> ============================================================================== 
>>>>
>>>> mchung.platform.logging:
>>>>   Benchmark           Samples        Mean     Stdev   %Diff     P 
>>>> Significant
>>>>   startup3                 30        2.34      0.05   -0.22 
>>>> 0.684       *
>>>>     Framer                 30        0.30      0.00    0.33 
>>>> 0.326       *
>>>>     JEdit                  30        1.70      0.09    0.99 
>>>> 0.522       *
>>>>     LimeWire               30        2.24      0.05   -1.56 
>>>> 0.025       *
>>>>     NetBeans               30        7.37      0.06    0.08 
>>>> 0.833       *
>>>>     Noop                   30        0.11      0.02   -3.94 
>>>> 0.326       *
>>>>     XFramer                30        0.30      0.00    0.22 
>>>> 0.310       *
>>>> ============================================================================== 
>>>>
>>>>   * - Not Significant: A non-zero %Diff for the mean could be 
>>>> noise. If the
>>>>       %Diff is 0, an actual difference may still exist. In either 
>>>> case, more
>>>>       samples would be needed to detect an actual difference in 
>>>> sample means.
>>>>
>>>>> 4) nobody measured anything else than Framer and SwingSet. That's 
>>>>> a minus.
>>>>
>>>> As I said, the fix is to eliminate the dependency on logging.  I'm 
>>>> not sure what measurement you want to do.
>>>>
>>>>> 5) we lose flexibility on debugging. That's a minus.
>>>>
>>>> This statement isn't true.  AWT debugging ability is unchanged.
>>>>
>>>> Mandy
>>>>
>>>>> 6) this fix don't decouple anything else awt/swing/2d.
>>>>> I made a grep on "Logger.getLogger" and there are entries from 
>>>>> xml, jmx, etc. That means we have to deal with them as well too 
>>>>> (as it causes the class to be loaded anyway), if we aware of jigsaw.
>>>>> 7) In most cases AWT initiates classes statically but basically 
>>>>> may want to do that lazily. That's minus. I'd consider 
>>>>> initialization in CTOR at first and see the impact. Believe 
>>>>> SwingSet would show enough here. If not, that's the reason to go 
>>>>> further to... well to check if the Java property set.
>>>>>
>>>>> Now, I don't see the evaluation is completed to make the decision. 
>>>>> And if we could modify client code in the way that Framer will 
>>>>> never initialize or/and load Logger (et al) classes so we achieved 
>>>>> the goal.
>>>>>
>>>>> Thanks,
>>>>>  Andrei
>>>>>
>>>>> Oleg Sukhodolsky wrote:
>>>>>> HI Mandy,
>>>>>>
>>>>>> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung 
>>>>>> <Mandy.Chung at sun.com> wrote:
>>>>>>
>>>>>>> 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 the 
>>>>>>> logging API is
>>>>>>> to support maintaining and servicing software at customer 
>>>>>>> sites.   Adding
>>>>>>> debugging code in the awt implementation using logging API is 
>>>>>>> reasonable but
>>>>>>> it's not the requirement for the logging API.  If there were a 
>>>>>>> better option
>>>>>>> to add debugging code, I believe you have no problem changing 
>>>>>>> the awt
>>>>>>> debugging code not to use the logging API.
>>>>>>>
>>>>>>> Server-type applications are typical use cases that logging 
>>>>>>> information is
>>>>>>> very important and useful for diagnosis in the field - long 
>>>>>>> running apps,
>>>>>>> hard to reproduce problems until running for many days/months.  
>>>>>>> It is hard
>>>>>>> to imagine how the logging information is important in client 
>>>>>>> applications.
>>>>>>
>>>>>> as ex-AWT developer I can confirm that there were number of cases 
>>>>>> when
>>>>>> logging had helped us to diagnose problem on client's site.  Even
>>>>>> though you usually
>>>>>> do not need to run an application for a long time to reproduce a 
>>>>>> problem
>>>>>> it can be very hard to reproduce it because the problem depends on
>>>>>> window manager
>>>>>> and other environment which is hard to re-create.
>>>>>>
>>>>>>
>>>>>>>   But you seem to know many client applications use the logging 
>>>>>>> API that I
>>>>>>> would also be interested to follow up with their requirements.
>>>>>>
>>>>>> I do not know many client applications which uses logging API 
>>>>>> (because I have
>>>>>> never write real client application) and it is hard to say if it 
>>>>>> uses
>>>>>> logging or not.
>>>>>> I hoped that you who saying that suggested changes will help to 
>>>>>> client
>>>>>> application
>>>>>> has some statistic to confirm your expectation
>>>>>>
>>>>>>
>>>>>>>> Ok, so this fix is only about modules.  But why AWT should not 
>>>>>>>> depend
>>>>>>>> on logging module?
>>>>>>>> The qiestion is: how many application we want to run doesn't use
>>>>>>>> logging& Because if an application
>>>>>>>> uses logging there is no reasons for AWT to not use it.  Please 
>>>>>>>> note
>>>>>>>> that even if logging is turned
>>>>>>>> off, the application still needs logging package/module.  So, 
>>>>>>>> though
>>>>>>>> end-user doesn't need logging output
>>>>>>>> she may need logging module to run the application.
>>>>>>> This is exactly why we want to decouple the dependency on 
>>>>>>> logging.  When an
>>>>>>> application uses logging, the application knows clearly what 
>>>>>>> module they
>>>>>>> require and that's fine.  When an application doesn't logging, 
>>>>>>> if the awt
>>>>>>> component requires logging for debugging purpose only, it 
>>>>>>> increases the
>>>>>>> download size, footprint and startup performance (class lookup 
>>>>>>> time,
>>>>>>> loading, init, etc) - please see my performance analysis report; 
>>>>>>> otherwise,
>>>>>>> it's not fruitful to discuss the details in this thread without the
>>>>>>> background info.  Just to mention it what we care about.
>>>>>>
>>>>>> I have found only two links to some performance analysis:
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html 
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64 
>>>>>>
>>>>>>
>>>>>> but they say about -Xverify and -Xshare and do not understand how 
>>>>>> they
>>>>>> can be related
>>>>>> to our topic :(  If they do, please explain (I have never been an
>>>>>> expert in this area :(
>>>>>> Or, if I missed something could you please point me what I have 
>>>>>> missed.
>>>>>>
>>>>>>
>>>>>>>> So, it is really
>>>>>>>> important to understand
>>>>>>>> what number of application will get advantage of suggested 
>>>>>>>> changes.
>>>>>>>>
>>>>>>>>
>>>>>>> You are suggesting the client applications always have a 
>>>>>>> dependency on
>>>>>>> logging.   Many client team engineers are happy to see the 
>>>>>>> dependency on
>>>>>>> logging being eliminated from the client stack requirement and 
>>>>>>> approve this
>>>>>>> fix :)
>>>>>>
>>>>>> I do not see how this can be considered as prove that the changes 
>>>>>> will
>>>>>> help client applications.
>>>>>> Unless we have some statistic it is all just our guess (which, as we
>>>>>> know, usually wrong ;)
>>>>>>
>>>>>>
>>>>>>>> Second question is: how big logging module is going to be? How 
>>>>>>>> big the
>>>>>>>> benefit for end-user will be?
>>>>>>>>
>>>>>>>>
>>>>>>> The size of the logging API is not big (~90K) but the size is 
>>>>>>> not the only
>>>>>>> one factor determining what benefit the end-user will have.
>>>>>>
>>>>>> what other factors do you know?
>>>>>>
>>>>>>
>>>>>>>  It's not
>>>>>>> necessary to logging API as one single module and details are to 
>>>>>>> be worked
>>>>>>> out.   Subscribe to the jigsaw project to follow the discussion 
>>>>>>> and progress
>>>>>>> there.   Serviceability includes other API as well.  If awt 
>>>>>>> started using
>>>>>>> other serviceability API (java.lang.management, 
>>>>>>> java.lang.instrument) for
>>>>>>> whatever reason, your argument would apply there as well.  I 
>>>>>>> don't think you
>>>>>>> wanted the awt module depends on all the serviceability APIs.
>>>>>>
>>>>>> I agree that usage of any API should be done after careful 
>>>>>> consideration.
>>>>>> Logging API provides us exactly what we need (ability to create 
>>>>>> log of
>>>>>> an application
>>>>>> executed on client)  this is why we started to use it.
>>>>>>
>>>>>>
>>>>>>>> I'm asking so many question mainly because the changes you 
>>>>>>>> suggested
>>>>>>>> create rather unnatural code (we can not
>>>>>>>> use standard logging machinery any more), so such changes 
>>>>>>>> should be
>>>>>>>> well-justified.
>>>>>>>>
>>>>>>>>
>>>>>>> That's what we pay for to modularize the JDK after many years of 
>>>>>>> JDK
>>>>>>> development without module support in the platform.  Otherwise, 
>>>>>>> if there
>>>>>>> were module support in the platform, you would consider very 
>>>>>>> carefully when
>>>>>>> adding a dependency on another module.
>>>>>>
>>>>>> perhaps you are right, but in case of logging I would expect that 
>>>>>> we'd use it
>>>>>> anyway.
>>>>>>
>>>>>> Oleg.
>>>>>>
>>>>>>
>>>>>>> If you have further issue, I suggest to start a different thread 
>>>>>>> on the
>>>>>>> awt-dev alias.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Mandy
>>>>>>> [1] 
>>>>>>> http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
>>>>>>>
>>>>>
>>>
>>
>


From Igor.Nekrestyanov at Sun.COM  Fri Sep 25 04:47:49 2009
From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov)
Date: Fri, 25 Sep 2009 04:47:49 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]    Review Request for 6879044
In-Reply-To: <4ABA0FBD.5030901@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
	<4AB9F96C.90303@sun.com>
	<4ABA0977.8060501@sun.com> <4ABA0FBD.5030901@sun.com>
Message-ID: <4ABCADE5.9080401@sun.com>

We have discussed this with Anthony and Andrei offline and they do not 
seem to have any blocking concerns.

There is one suggestion though - there should be simple explanation for 
"are there any changes required on the end user side
to enable logging and if so, what are they". Logging is mostly used to 
get details from remote user and ideally
instructions that were sent to such users (i.e. "if you have 
focus-related issue please do this and send us this") should not change
(or it should be explained how they are changing).

Anthony/Andrei, please speak up if you have other concerns.

-igor

On 9/23/09 5:08 AM, Anthony Petrov wrote:
> On 09/23/2009 03:41 PM, Alan Bateman wrote:
>>> If AWT initialized the loggers lazily, and only did it when the 
>>> logging is actually enabled (checking for some system property, or 
>>> whatever other way), would we still be statically linked to the 
>>> j.u.logging package in case of a regular client application that 
>>> does not use/enable logging explicitly?
>> Yes, minimally they should be created lazily (this is one of the 
>> suggestions that Mandy listed in 6880089). That would at least avoid 
>> initializing all these loggers. The static dependency remains.
>
> Ah, I just looked over the PlatformLogger code, and now I see it uses 
> reflection to access the j.u.logging.* classes. Now this point is clear.
>
> Have it been discussed whether that is feasible to modify the VM in 
> order to eliminate the static dependency if a particular object never 
> gets initialized?
>
> It just looks kind of artificial to create such proxy classes. I bet 
> we'll need plenty of them for other modules. Won't the code be messed 
> up too much?
>
> -- 
> best regards,
> Anthony


From Anthony.Petrov at Sun.COM  Fri Sep 25 07:16:09 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 25 Sep 2009 18:16:09 +0400
Subject: <AWT Dev> Review request #4: 6852592 (invalidate() must be smarter)
Message-ID: <4ABCD0A9.2040807@sun.com>

It's been a long time since we discussed the issue. Now is the time for 
revival.

Last time we came across a failing test [1] that had a JApplet embedded 
in a JFrame. The frame was expected to be validated upon showing. 
However, the components in the JApplet were not validated, since the 
JApplet itself was marked valid, but the invalidate() requests from the 
children of the applet stopped on the RootPane of the JApplet because it 
was a validate root.

Later we found out a possible solution for that problem [2]: the show() 
(as well as the pack()) should validate the whole component hierarchy 
unconditionally.

So, here's the fix with this solution implemented. Please review:

http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.3/

The fix has been tested quite thoroughly: all sort of related automatic 
tests for both Swing and AWT areas have been run (including 
layout-related tests, bare (J)Component and Container-related tests, and 
some other.) All manual layout-related tests from AWT and Swing have 
also been run and passed. Mixing-related regression tests pass as well.

Please note that I've also changed the synopsis of the change request by 
replacing revalidate() with invalidate() because the fix actually 
affects the invalidate() method only.

[1] http://mail.openjdk.java.net/pipermail/awt-dev/2009-August/000831.html

[2] http://mail.openjdk.java.net/pipermail/awt-dev/2009-August/000835.html

--
best regards,
Anthony

From Mandy.Chung at Sun.COM  Fri Sep 25 08:41:56 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Fri, 25 Sep 2009 08:41:56 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]    Review Request for 6879044
In-Reply-To: <4ABCADE5.9080401@sun.com>
References: <4AAD9D2D.6000502@sun.com> <4AB1F9CA.40309@sun.com>
	<4AB208E9.8020900@sun.com> <4AB212BA.6040405@sun.com>
	<271e55d20909170417x2bb1495bu6d93216c5141501e@mail.gmail.com>
	<4AB21B68.90603@sun.com>
	<271e55d20909170432s2c4e5f18sa7d3291f6e789dcb@mail.gmail.com>
	<4AB277C2.8030603@Sun.com>
	<271e55d20909171945l48544a5cjf6a61d36362285fa@mail.gmail.com>
	<4AB3EB60.7050600@sun.com>
	<271e55d20909182059y4610d01at4cc8a2a935aa6cff@mail.gmail.com>
	<4AB73E0D.3000600@sun.com> <4AB90721.2060509@Sun.com>
	<4AB9F96C.90303@sun.com>
	<4ABA0977.8060501@sun.com> <4ABA0FBD.5030901@sun.com>
	<4ABCADE5.9080401@sun.com>
Message-ID: <4ABCE4C4.1010607@sun.com>

There is no change to the log messages emitted from awt/2d/swing.  The 
only impact to the end users is if they enable logging by modifying the 
system-wide logging.properties (see below); otherwise, the end users 
will not notice any change due to this fix.

The following are the common ways to enable logging:
1)  set -Djava.util.logging.config.file=<your own logging.properties> 
system properties in the command-line

This fix has no impact to the end user.   Typically for debugging 
purpose, a user will have their custom logging.properties instead of 
modify the system-wide logging.properties as they would impact all Java 
apps.

2) Modify the system-wide logging.properties in the JRE local copy ( 
<JRE>/lib/logging.properties)

This fix has impact to the end user and they will need to add 
-Djava.util.logging.config.file=<JRE>/lib/logging.properties option in 
the command-line.

3) Have their own java.util.logging.config.class implementation

This fix has no impact to the end user.

Thanks
Mandy

Igor Nekrestyanov wrote:
> We have discussed this with Anthony and Andrei offline and they do not 
> seem to have any blocking concerns.
>
> There is one suggestion though - there should be simple explanation 
> for "are there any changes required on the end user side
> to enable logging and if so, what are they". Logging is mostly used to 
> get details from remote user and ideally
> instructions that were sent to such users (i.e. "if you have 
> focus-related issue please do this and send us this") should not change
> (or it should be explained how they are changing).
>
> Anthony/Andrei, please speak up if you have other concerns.
>
> -igor
>
> On 9/23/09 5:08 AM, Anthony Petrov wrote:
>> On 09/23/2009 03:41 PM, Alan Bateman wrote:
>>>> If AWT initialized the loggers lazily, and only did it when the 
>>>> logging is actually enabled (checking for some system property, or 
>>>> whatever other way), would we still be statically linked to the 
>>>> j.u.logging package in case of a regular client application that 
>>>> does not use/enable logging explicitly?
>>> Yes, minimally they should be created lazily (this is one of the 
>>> suggestions that Mandy listed in 6880089). That would at least avoid 
>>> initializing all these loggers. The static dependency remains.
>>
>> Ah, I just looked over the PlatformLogger code, and now I see it uses 
>> reflection to access the j.u.logging.* classes. Now this point is clear.
>>
>> Have it been discussed whether that is feasible to modify the VM in 
>> order to eliminate the static dependency if a particular object never 
>> gets initialized?
>>
>> It just looks kind of artificial to create such proxy classes. I bet 
>> we'll need plenty of them for other modules. Won't the code be messed 
>> up too much?
>>
>> -- 
>> best regards,
>> Anthony
>


From chrriis at gmail.com  Fri Sep 25 09:39:17 2009
From: chrriis at gmail.com (Christopher Deckers)
Date: Fri, 25 Sep 2009 18:39:17 +0200
Subject: <AWT Dev> Review request #4: 6852592 (invalidate() must be
	smarter)
In-Reply-To: <4ABCD0A9.2040807@sun.com>
References: <4ABCD0A9.2040807@sun.com>
Message-ID: <4f9903f0909250939g16481311j63154639cc74bd45@mail.gmail.com>

Hi Anthony,

> It's been a long time since we discussed the issue. Now is the time for
> revival.

Thanks for raising the undead! :)

> The fix has been tested quite thoroughly

I had a look at the code and I don't see anything wrong with the
logic. Good work!

If all is well, in which build should we expect to see that change?

Cheers,
-Christopher

From Anthony.Petrov at Sun.COM  Mon Sep 28 03:49:21 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Mon, 28 Sep 2009 14:49:21 +0400
Subject: <AWT Dev> Review request #4: 6852592 (invalidate() must
	be	smarter)
In-Reply-To: <4f9903f0909250939g16481311j63154639cc74bd45@mail.gmail.com>
References: <4ABCD0A9.2040807@sun.com>
	<4f9903f0909250939g16481311j63154639cc74bd45@mail.gmail.com>
Message-ID: <4AC094B1.7070707@sun.com>

Hi Chris,

On 9/25/2009 8:39 PM Christopher Deckers wrote:
> If all is well, in which build should we expect to see that change?

Well, the fix should be reviewed here first. Then we need to get an 
approval for the specification changes which might take a few weeks. So 
I guess not earlier than in about 3 builds from now.

--
best regards,
Anthony

From dmitry.cherepanov at sun.com  Wed Sep 30 03:03:18 2009
From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com)
Date: Wed, 30 Sep 2009 10:03:18 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6853592: VM test
	nsk.regression.b4261880 fails with	"X Error of failed
	request: BadWindow" inconsistently.
Message-ID: <20090930100338.0F7D241577@hg.openjdk.java.net>

Changeset: b6980b0d8440
Author:    dcherepanov
Date:      2009-09-30 13:21 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b6980b0d8440

6853592: VM test nsk.regression.b4261880  fails with "X Error of failed request:  BadWindow" inconsistently.
Reviewed-by: art, anthony

! src/solaris/classes/sun/awt/X11/XToolkit.java


From dmitry.cherepanov at sun.com  Wed Sep 30 04:53:50 2009
From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com)
Date: Wed, 30 Sep 2009 11:53:50 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6878284:
	Sometimes	test/javax/swing/system/6799345/TestShutdown.java "hangs"
Message-ID: <20090930115410.4B7D641580@hg.openjdk.java.net>

Changeset: a21d00087df9
Author:    dcherepanov
Date:      2009-09-30 15:48 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/a21d00087df9

6878284: Sometimes test/javax/swing/system/6799345/TestShutdown.java "hangs"
Reviewed-by: art, ant

! src/share/classes/java/awt/EventQueue.java
! src/share/classes/sun/awt/AWTAutoShutdown.java