From stuart.marks at oracle.com Thu Dec 1 00:27:34 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 01 Dec 2011 00:27:34 -0800
Subject: JDK8 Warnings Cleanup Day: Coding Guideline
Message-ID: <4ED73A76.6050004@oracle.com>
Warnings Cleanup Day is here!
When you're cleaning up warnings today, we'd like you to focus on one thing:
==> simple, minimal, and risk-free warnings fixes <==
Most of the warnings can be eliminated with such changes. For example, take a
look at Alan Bateman's recent changeset [1]. The vast majority of these are
one-line changes. These should be close to obviously correct by inspection, so
that we can push in as many warning fixes as we can with only minimal testing.
Along the way you'll inevitably run across opportunities to do other cleanups,
do some refactoring, reformatting, fixing little bugs you run across, and so
forth. Please avoid this temptation and stay focused on minimal warning fixes.
Another thing you'll probably run into is warnings that can be removed by
changing public APIs. In some cases APIs aren't very well designed
(particularly with generics and wildcards) so using them always generates
warning messages. Unfortunately, because of compatibility constraints and
processes for evolving Java's public APIs, any such changes are out of scope
for Cleanup Day. If you run across such cases, please note them so that we can
file a bug, and move on.
It's not a goal of cleanup day to eliminate every last warning. We expect that
there will be a small number of warnings that are caused by poor APIs, or that
are too difficult to fix or that require too much discussion to deal with in a
single day. Again, make a note of these, keep things simple, and move on.
OK, enough talk. Let's code!
s'marks
[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7795c41ed54c
From stuart.marks at oracle.com Thu Dec 1 01:16:29 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 01 Dec 2011 01:16:29 -0800
Subject: Request for Review of 7116890 (Warning Cleanup java.io)
In-Reply-To: <4ED7039A.2080903@gmx.de>
References: <4ED7039A.2080903@gmx.de>
Message-ID: <4ED745ED.6080409@oracle.com>
Hi Sebastian,
Thanks for submitting this patch! I've filed bug 7116890 to cover this set of
changes.
Regarding webrev, it probably does get confused by merges in the history. By
default it tries to show differences between the tip of the target repository
and tip + uncommitted changes in your local repository. This isn't always the
right thing. One thing you might try is to use the -r option to specify a
particular revision in the history against which to generate the diffs. But,
having a few extra files isn't a big deal.
On to your changes.
Most of them are really good and are exactly the kind of simple change we're
looking for, as I posted a little while ago. [1]
The ExpiringCache.java case is an interesting one. I think it's possible to add
a static serialVersionUID field within the anonymous class. It's hard to run
serialver over an anonymous class (actually it might be possible to run the
checksum algorithm on the loaded class) but if in practice it's never
serialized, who cares what the "correct" value is? You could just use a value
of 0L.
An alternative would also be to use @SuppressWarnings("serial"). Since the
constructor is so short, you could just put it on the constructor.
Actually I prefer @SuppressWarnings, since adding serialVersionUID adds to the
system's footprint. If it's never used, we shouldn't bother defining it.
Given these alternatives, it's not necessary to create a static
CacheHashMapImpl class.
Regarding the FilePermission.java change, yes, I see that the
skipBeforePreviousComma() change is problematic. I puzzled over it for a while
too. I wish I had sent out the Coding Guideline [1] earlier; it might have
saved you an hour. :-) Sorry about that.
A cleanup/rewrite of this code would indeed be better done separate from
Warnings Cleanup Day. But I think there might be a simple way to get rid of the
warning without doing a cleanup or refactoring. The warning message in question
is at line 535 of the original code, about falling through to the next case.
But the next case doesn't actually do anything but break. Could we just change
the /*FALLTHROUGH*/ comment to a break statement? I think that would fix the
warning without changing the logic at all.
s'marks
[1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000380.html
On 11/30/11 8:33 PM, Sebastian Sickelmann wrote:
> Hi,
>
> i have a webrev[0] that contains some warning cleanup for java.io
> It is based on rev 7795c41ed54c http://hg.openjdk.java.net/jdk8/tl/jdk/
>
> Some comments to the changes:
>
> ExpiringCache.java: Changed anonymous inner class to inner class with the
> intention to put serialversion inside of it. But serialver doesn't want to give
> my the serialver. I also think that ExpiringCache is not serializable but the
> warning was clear: the anonymous inner class is seriallizable and has no
> explicit serialversionuid.
>
> FilePermission.java: I have starred at the code between line 453 and 547 for
> over an hour, because i thought that there is a bug within the expression "i >=
> matchlen" in line 530 and the both "i != -1" in lines 457 and 461. But there is
> no bug. But i wanted to left this code slightly more readable. I introduced the
> method skipBeforePreviousComma to make it possible to work-around the
> fallthought warning with an return statement. This code-change need's some more
> review attention. Maybe we should split this up for another cleanup. I think
> the whole method needs some rewrite.
>
> Some classes had no change at all. Maybe webrev created them because there
> where changes in my history/branches. There were some patches from alan i saw
> to late. Maybe webrev is confused of the multiple merges.
>
> Can someone please create a CR for this and
>
> [0]
> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/Warning_Cleanup_Java_io/webrev0_based_on_7795c41ed54c/index.html
>
>
From develop4lasu at gmail.com Thu Dec 1 02:21:00 2011
From: develop4lasu at gmail.com (=?UTF-8?Q?Marek_Kozie=C5=82?=)
Date: Thu, 1 Dec 2011 11:21:00 +0100
Subject: Syntactic sugar for method chaining / fluent interfaces Syntactic
sugar for method chaining / fluent interfaces Syntactic sugar for
method chaining / fluent interfaces
In-Reply-To: <CAHJmSV-tRZF6CJR0_exgtQzHEJpWd96nnC=sXugDJQdmv=iQdg@mail.gmail.com>
References: <CAHJmSV_dnAgEin9TVuBytY-hKrGQFf5P-UhGfghxaTLkjyAdxw@mail.gmail.com>
<CABnvQsEZzGwpe_EXGoEy90BSRLpdA4Ve1K+3C=SVcwdGm58Efg@mail.gmail.com>
<CAHJmSV-tRZF6CJR0_exgtQzHEJpWd96nnC=sXugDJQdmv=iQdg@mail.gmail.com>
Message-ID: <CABnvQsFhEhCFAjXtFdE9MX6ysx4AiqSFT3_DAYvZes1SE2_a5Q@mail.gmail.com>
Hi.
I can agree that many ppl would be happy about such solution. But
while it's language change the main question is: "What harm can it
bring to language?"
Problem lay on interfaces/classes that already exists.
'void' have more than one meaning now time:
1st: there is no need to return anything.
2nd: creator wanted to prevent from chaining - to force one line-one
call formating.
3rd: space for future return type was left.
what's more
allowing mixing void with this would bring ppl to use DoNotTouch class
as force to maintain previous void meaning.
because of above reasons I suggested void+this solution.
I really wonder if language can be harmed in order to fix things that
was written in wrong way.
Unfortunately any change into types system can be pretty heavy as well.
2011/11/22 Eirik Lygre <eirik.lygre at gmail.com>:
>
>
> On Mon, Nov 21, 2011 at 3:07 PM, Marek Kozie? <develop4lasu at gmail.com>
> wrote:
>>
>> 2011/11/20 Eirik Lygre <eirik.lygre at gmail.com>:
>> > It seems that the various Java SE 8 projects have lots of care for
>> > simple
>> > and expressive code, for example as demonstrated by the "Language /
>> > Library
>> > / VM co-evolution in Java SE 8" presentation from Devoxx. Hence, I
>> > wonder
>> > if there is any interest for reviving an older suggestion about simple
>> > method chaining / fluent interface.
>> >
>> > I'm not really qualified to suggest the formal syntax, but it probably
>> > boils down to this:
>> >
>> > ? ?A void method call "object.function(...)" evaluates to the object
>> > itself
>> >
>> > This will be syntactic sugar (compiler only, no jvm changes), making it
>> > possible to chain method calls across void methods. For example:
>> >
>> > ? ?Socket so = new SSLSocket()
>> > ? ? ? ? ? ? ? ?.setSendBufferSize(1024) ? ? ? ?// void
>> > Socket.setSendBufferSize(int)
>> > ? ? ? ? ? ? ? ?.setReceiveBufferSize(1024) ? ? // void
>> > Socket.setSendBufferSize(int)
>> > ? ? ? ? ? ? ? ?.setNeedClientAuth(true); ? ? ? // void
>> > SSLSocket.setNeedClientAuth(boolean)
>> >
>> > A couple of points on the rationale for the suggestion:
>> >
>> > * First, it will enable method chaining on a large body of existing
>> > code.
>> > The javabeans spec says that setters should return void, and this
>> > suggestion would automatically allow fluent use of such beans.
>> >
>> > * It will allow a level of fluent interfaces that are otherwise not
>> > possible, in that it will simulate a "self" return type. If you want to
>> > ?implement a fluent interface today, you would return your own type. If
>> > somebody then created a subclass, and wanted to maintain fluency, they
>> > would have to override all parent methods, as shown below. Of course,
>> > this
>> > means that fluent methods added to the superclass must also be added to
>> > all
>> > subclasses, which isn't really an ideal situation if you want to evolve
>> > an
>> > api.
>> >
>> > ? ?class Socket {
>> > ? ? ? ?Socket setSendBufferSize(...); ? // Can be chained
>> > ? ?}
>> >
>> > ? ?class SSLSocket extends Socket {
>> > ? ? ? ?SSLSocket setSendBufferSize(...) { ? ? ? ? ? ? ? ? ? ? ?// Change
>> > return type, to maintain chainability
>> > ? ? ? ? ? ?return (SSLSocket)super.setSendBufferSize(...); ? ? // Cast
>> > required.
>> > ? ? ? ?}
>> > ? ?}
>> >
>> > This is not a new idea. It was suggested for project coin, where there
>> > are
>> > more references:
>> >
>> > * It was suggested for project coin by Ulf Zibis (
>> > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html).
>> > * I've not found much discussion, other than a quick email from Joe
>> > Darcy (
>> > http://mail.openjdk.java.net/pipermail/coin-dev/2009-May/001768.html),
>> > where the idea is rejected: "While fluent interfaces are fine, I don't
>> > think using a language change ?to retrofit this pattern of API usage on
>> > code not written that way is ?the best use of the language change
>> > budget."
>> >
>> > While it was considered (and rejected) for SE 7, it might still be
>> > proper
>> > for SE 8. Method chaning / fluent interfaces are used in pretty much all
>> > lambda examples, as a useful code pattern. I think it's useful, too, and
>> > think it should be made easier accessible across the language.
>> >
>> > I've got two hopes for this email:
>> >
>> > * First, feedback on whether the community considers this to be useful,
>> > or
>> > not
>> > * Second, feedback on how to proceed, if it is in fact considered useful
>> >
>> > Eirik Lygre
>> > eirik.lygre at gmail.com
>> >
>>
>>
>> There are more reasons against.
>> One of the most important problem occurs when void will be changed
>> into other type in future.
>>
>> How hard to track bugs can be when new return type will have same
>> methods as 'this'? 'Return 'this' proposal' was made to fill that gap.
>> Some of discussion can be found under (but there where more about it):
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000523.html
>>
>>
>> and little under:
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000107.html
>>
>> --
>> Regards.
>> Lasu aka Marek Kozie?
>
> Since you give only one example, I'll have to limit my comment to that
> one. On the other hand, you have a suggestion for an alternative syntax
> to the same problem, so I guess we have a common goal :-)
> You say that the problem occurs when "void will be changed into
> other type in the future". That problem, however, applies to any fluent
> interface, whether manually specified, using the mechanism I described,
> or the mechanism you described. For example, using an abstract
> class that writes to somewhere:
> ? ? class Output {
> ? ? ? ? public Output append (char c); ?// Manual fluent interface
> ? ? ? ? public void append (CharSeq csq); // My suggestion
> ? ? ? ? public this append (CharSeq csq, int s, int e); // Your suggestion
> ? ? }
> Now, all of these would suffer from hard debugging if the return type
> was changed from one of Output, void or append to, say,
> java.lang.Appendable, as the following would all compile:
> ? ? // All of these will first call Output.append(), then
> ? ? // Appendable.append
> ? ? new Output().append('a').append('b');
> ? ? new Output().append("a").append("b");
> ? ? new Output().append("a",0,1).append("a",0.1);
> My suggestion has the advantage, or disadvantage, of "just
> working" with a lot of existing api's (including all api's that
> comply to the javabeans specification). To me, that is a
> great advantage.
> It is correct that opening for auto-fluency using void methods,
> or?whatever this proposal should be called, will "lock down"
> existing?void?methods. However, that?is?pretty much the
> case already today, since changing the?return type of a
> method will invalidate any subclass which?tries to override
> the method ("sub cannot override func() in?super;
> attempting to use incompatible return type")
> And, the benefits are there. They are not purely cosmetic,
> but also functional.
> * It will significantly simplify fluent programming
> * It will enable fluent apis that cannot be made today
> * It will enable fluent thinking on existing code
> * No?existing programs will fail or change behavior
> --
> Eirik
>
>
--
Pozdrowionka. / Regards.
Lasu aka Marek Kozie?
http://na-chlodno.blogspot.com/
http://lasu2string.blogspot.com/
From sebastian.sickelmann at gmx.de Thu Dec 1 08:27:47 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Thu, 01 Dec 2011 17:27:47 +0100
Subject: Request for Review of 7116890 (Warning Cleanup java.io)
In-Reply-To: <4ED745ED.6080409@oracle.com>
References: <4ED7039A.2080903@gmx.de> <4ED745ED.6080409@oracle.com>
Message-ID: <4ED7AB03.6000006@gmx.de>
Am 01.12.2011 10:16, schrieb Stuart Marks:
> Hi Sebastian,
>
> Thanks for submitting this patch! I've filed bug 7116890 to cover this
> set of changes.
>
> Regarding webrev, it probably does get confused by merges in the
> history. By default it tries to show differences between the tip of
> the target repository and tip + uncommitted changes in your local
> repository. This isn't always the right thing. One thing you might try
> is to use the -r option to specify a particular revision in the
> history against which to generate the diffs. But, having a few extra
> files isn't a big deal.
>
> On to your changes.
>
> Most of them are really good and are exactly the kind of simple change
> we're looking for, as I posted a little while ago. [1]
>
> The ExpiringCache.java case is an interesting one. I think it's
> possible to add a static serialVersionUID field within the anonymous
> class. It's hard to run serialver over an anonymous class (actually it
> might be possible to run the checksum algorithm on the loaded class)
> but if in practice it's never serialized, who cares what the "correct"
> value is? You could just use a value of 0L.
>
> An alternative would also be to use @SuppressWarnings("serial"). Since
> the constructor is so short, you could just put it on the constructor.
>
> Actually I prefer @SuppressWarnings, since adding serialVersionUID
> adds to the system's footprint. If it's never used, we shouldn't
> bother defining it.
>
> Given these alternatives, it's not necessary to create a static
> CacheHashMapImpl class.
>
> Regarding the FilePermission.java change, yes, I see that the
> skipBeforePreviousComma() change is problematic. I puzzled over it for
> a while too. I wish I had sent out the Coding Guideline [1] earlier;
> it might have saved you an hour. :-) Sorry about that.
>
> A cleanup/rewrite of this code would indeed be better done separate
> from Warnings Cleanup Day. But I think there might be a simple way to
> get rid of the warning without doing a cleanup or refactoring. The
> warning message in question is at line 535 of the original code, about
> falling through to the next case. But the next case doesn't actually
> do anything but break. Could we just change the /*FALLTHROUGH*/
> comment to a break statement? I think that would fix the warning
> without changing the logic at all.
>
> s'marks
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000380.html
>
>
> On 11/30/11 8:33 PM, Sebastian Sickelmann wrote:
>> Hi,
>>
>> i have a webrev[0] that contains some warning cleanup for java.io
>> It is based on rev 7795c41ed54c http://hg.openjdk.java.net/jdk8/tl/jdk/
>>
>> Some comments to the changes:
>>
>> ExpiringCache.java: Changed anonymous inner class to inner class with
>> the
>> intention to put serialversion inside of it. But serialver doesn't
>> want to give
>> my the serialver. I also think that ExpiringCache is not serializable
>> but the
>> warning was clear: the anonymous inner class is seriallizable and has no
>> explicit serialversionuid.
>>
>> FilePermission.java: I have starred at the code between line 453 and
>> 547 for
>> over an hour, because i thought that there is a bug within the
>> expression "i >=
>> matchlen" in line 530 and the both "i != -1" in lines 457 and 461.
>> But there is
>> no bug. But i wanted to left this code slightly more readable. I
>> introduced the
>> method skipBeforePreviousComma to make it possible to work-around the
>> fallthought warning with an return statement. This code-change need's
>> some more
>> review attention. Maybe we should split this up for another cleanup.
>> I think
>> the whole method needs some rewrite.
>>
>> Some classes had no change at all. Maybe webrev created them because
>> there
>> where changes in my history/branches. There were some patches from
>> alan i saw
>> to late. Maybe webrev is confused of the multiple merges.
>>
>> Can someone please create a CR for this and
>>
>> [0]
>> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/Warning_Cleanup_Java_io/webrev0_based_on_7795c41ed54c/index.html
>>
>>
>>
Thanks for the good feedback.
I splitted my change to the trivial part and will start discussion of
FilePermission change on core-libs-dev after the cleanup event.
I created a new webrev with the suggested changes here[2]
[2]
http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/Warning_Cleanup_Java_io/CR7116890_0/index.html
-- Sebastian
From chris.hegarty at oracle.com Thu Dec 1 08:39:58 2011
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 01 Dec 2011 16:39:58 +0000
Subject: Request for Review of 7116890 (Warning Cleanup java.io)
In-Reply-To: <4ED7AB03.6000006@gmx.de>
References: <4ED7039A.2080903@gmx.de> <4ED745ED.6080409@oracle.com>
<4ED7AB03.6000006@gmx.de>
Message-ID: <4ED7ADDE.8000602@oracle.com>
On 01/12/2011 16:27, Sebastian Sickelmann wrote:
> ....
> Thanks for the good feedback.
>
> I splitted my change to the trivial part and will start discussion of
> FilePermission change on core-libs-dev after the cleanup event.
> I created a new webrev with the suggested changes here[2]
>
> [2]
> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/Warning_Cleanup_Java_io/CR7116890_0/index.html
Looks fine to me.
-Chris.
>
>
> -- Sebastian
From jonathan.gibbons at oracle.com Thu Dec 1 08:49:50 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 01 Dec 2011 08:49:50 -0800
Subject: Request for Review of 7116890 (Warning Cleanup java.io)
In-Reply-To: <4ED7AB03.6000006@gmx.de>
References: <4ED7039A.2080903@gmx.de> <4ED745ED.6080409@oracle.com>
<4ED7AB03.6000006@gmx.de>
Message-ID: <4ED7B02E.8060805@oracle.com>
On 12/01/2011 08:27 AM, Sebastian Sickelmann wrote:
> Am 01.12.2011 10:16, schrieb Stuart Marks:
>> Hi Sebastian,
>>
>> Thanks for submitting this patch! I've filed bug 7116890 to cover
>> this set of changes.
>>
>> Regarding webrev, it probably does get confused by merges in the
>> history. By default it tries to show differences between the tip of
>> the target repository and tip + uncommitted changes in your local
>> repository. This isn't always the right thing. One thing you might
>> try is to use the -r option to specify a particular revision in the
>> history against which to generate the diffs. But, having a few extra
>> files isn't a big deal.
>>
>> On to your changes.
>>
>> Most of them are really good and are exactly the kind of simple
>> change we're looking for, as I posted a little while ago. [1]
>>
>> The ExpiringCache.java case is an interesting one. I think it's
>> possible to add a static serialVersionUID field within the anonymous
>> class. It's hard to run serialver over an anonymous class (actually
>> it might be possible to run the checksum algorithm on the loaded
>> class) but if in practice it's never serialized, who cares what the
>> "correct" value is? You could just use a value of 0L.
>>
>> An alternative would also be to use @SuppressWarnings("serial").
>> Since the constructor is so short, you could just put it on the
>> constructor.
>>
>> Actually I prefer @SuppressWarnings, since adding serialVersionUID
>> adds to the system's footprint. If it's never used, we shouldn't
>> bother defining it.
>>
>> Given these alternatives, it's not necessary to create a static
>> CacheHashMapImpl class.
>>
>> Regarding the FilePermission.java change, yes, I see that the
>> skipBeforePreviousComma() change is problematic. I puzzled over it
>> for a while too. I wish I had sent out the Coding Guideline [1]
>> earlier; it might have saved you an hour. :-) Sorry about that.
>>
>> A cleanup/rewrite of this code would indeed be better done separate
>> from Warnings Cleanup Day. But I think there might be a simple way to
>> get rid of the warning without doing a cleanup or refactoring. The
>> warning message in question is at line 535 of the original code,
>> about falling through to the next case. But the next case doesn't
>> actually do anything but break. Could we just change the
>> /*FALLTHROUGH*/ comment to a break statement? I think that would fix
>> the warning without changing the logic at all.
>>
>> s'marks
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000380.html
>>
>>
>> On 11/30/11 8:33 PM, Sebastian Sickelmann wrote:
>>> Hi,
>>>
>>> i have a webrev[0] that contains some warning cleanup for java.io
>>> It is based on rev 7795c41ed54c http://hg.openjdk.java.net/jdk8/tl/jdk/
>>>
>>> Some comments to the changes:
>>>
>>> ExpiringCache.java: Changed anonymous inner class to inner class
>>> with the
>>> intention to put serialversion inside of it. But serialver doesn't
>>> want to give
>>> my the serialver. I also think that ExpiringCache is not
>>> serializable but the
>>> warning was clear: the anonymous inner class is seriallizable and
>>> has no
>>> explicit serialversionuid.
>>>
>>> FilePermission.java: I have starred at the code between line 453 and
>>> 547 for
>>> over an hour, because i thought that there is a bug within the
>>> expression "i >=
>>> matchlen" in line 530 and the both "i != -1" in lines 457 and 461.
>>> But there is
>>> no bug. But i wanted to left this code slightly more readable. I
>>> introduced the
>>> method skipBeforePreviousComma to make it possible to work-around the
>>> fallthought warning with an return statement. This code-change
>>> need's some more
>>> review attention. Maybe we should split this up for another cleanup.
>>> I think
>>> the whole method needs some rewrite.
>>>
>>> Some classes had no change at all. Maybe webrev created them because
>>> there
>>> where changes in my history/branches. There were some patches from
>>> alan i saw
>>> to late. Maybe webrev is confused of the multiple merges.
>>>
>>> Can someone please create a CR for this and
>>>
>>> [0]
>>> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/Warning_Cleanup_Java_io/webrev0_based_on_7795c41ed54c/index.html
>>>
>>>
>>>
> Thanks for the good feedback.
>
> I splitted my change to the trivial part and will start discussion of
> FilePermission change on core-libs-dev after the cleanup event.
> I created a new webrev with the suggested changes here[2]
>
> [2]
> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/Warning_Cleanup_Java_io/CR7116890_0/index.html
>
> -- Sebastian
Sebastian,
I would expect you are still getting warnings, which can easily be
fixed, from the use of raw types in ExpiringCache.java, lines 67,68.
-- Jon
From xiomara.jayasena at oracle.com Thu Dec 1 10:31:18 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Thu, 1 Dec 2011 10:31:18 -0800 (PST)
Subject: JDK8 Warnings Cleanup Day (WCD) -- Sign up
In-Reply-To: <71af17d2-86d1-427d-a08a-768ad867e841@default>
References: <868c0635-11fc-4bc7-9ee9-64513092526e@default>
<b26a573f-c4c6-46f6-92d8-3250af008c4e@default
71af17d2-86d1-427d-a08a-768ad867e841@default>
Message-ID: <123c245d-cae7-40ba-aed6-2cdd446be15b@default>
Hi,
I have consolidated the responses I have seen on, regarding areas that people have signed up for.
There are a couple of areas such as java.util.concurrent that need to be sort out and those individuals can follow up with the respective people for those areas.
The sing up sheet can be found from the WCD wiki (http://wikis.sun.com/display/OpenJDK/JDK8+Warnings+Cleanup+Day ) or from this direct link here:
http://wikis.sun.com/pages/editpage.action?pageId=250714453
-Xiomara
From xiomara.jayasena at oracle.com Thu Dec 1 10:57:19 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Thu, 1 Dec 2011 10:57:19 -0800 (PST)
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <4ED7CD0C.8050506@oracle.com>
References: <391b7649-4f85-47c2-805c-03aecc0ce5ac@default
4ED5AAAB.6070404@gmx.de> <c2fb78d9-7420-445c-945a-9315c8d9c5cd@default>
<4ED70A25.2030609@gmx.de 4ED7CD0C.8050506@oracle.com>
Message-ID: <66068043-ac5a-4826-81cd-4fd6ca8f9809@default>
Thanks Jim.
I am including the webrev so that people can see the file changes:
http://cr.openjdk.java.net/~jjh/7117053-FixSomeJDIWarnings/
-Xiomara
> -----Original Message-----
> From: Jim Holmlund
> Sent: Thursday, December 01, 2011 10:53 AM
> To: Xiomara Jayasena
> Cc: jdk8-dev at openjdk.java.net; Serguei Spitsyn
> Subject: Re: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
>
>
> Xiomara, I have started fixing warnings in com/sun/tools/jdi. I will
> continue fixing more of them today, but I no longer know how to run all
> the JDI tests, so after I get the warnings fixed, I will turn over the
> patch to the serviceability team to run the tests and assuming no
> problems appear, commit the changes.
>
> - jjh
>
From sebastian.sickelmann at gmx.de Thu Dec 1 11:20:35 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Thu, 01 Dec 2011 20:20:35 +0100
Subject: Fwd: Re: Request for Review of 7116890 (Warning Cleanup java.io)
Message-ID: <4ED7D383.7010309@gmx.de>
Am 01.12.2011 18:15, schrieb Alan Bateman:
> On 01/12/2011 16:27, Sebastian Sickelmann wrote:
>> :
>> Thanks for the good feedback.
>>
>> I splitted my change to the trivial part and will start discussion of
>> FilePermission change on core-libs-dev after the cleanup event.
>> I created a new webrev with the suggested changes here[2]
>>
>> [2]
>> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/Warning_Cleanup_Java_io/CR7116890_0/index.html
>>
>> -- Sebastian
> In ExpiringCache L67-68 it looks like you are missing the type
> parameters. Also I assume we can change L119-120 to be for(String key:
> keySet) { ... } (I realize this is not strictly a warnings change).
>
> Otherwise I think it's okay.
>
> -Alan.
>
>
>
Thanks Alan,
L67-68 was a backporting (from a more complex solution to a small
warning cleanup) issue. I missed the type parameters here.
I changed L119-120 also.
New webrev is here:
http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/Warning_Cleanup_Java_io/CR7116890_1/index.html
-- Sebastian
From dl at cs.oswego.edu Thu Dec 1 12:01:15 2011
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 01 Dec 2011 15:01:15 -0500
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <CALwNKeQGkH5TXBJAxSLOGtO3AqW3=jjMw1ZZo0T=DBKC2eGygg@mail.gmail.com>
References: <CALwNKeQGkH5TXBJAxSLOGtO3AqW3=jjMw1ZZo0T=DBKC2eGygg@mail.gmail.com>
Message-ID: <4ED7DD0B.8000604@cs.oswego.edu>
On 11/30/11 04:03, Michael Barker wrote:
> I can't seem to see anybody claim anything other than swing and awt
> packages, so if no one has taken them we'll look at the subpackages of
> java.util:
>
> java.util.concurrent
> java.util.concurrent.atomic
Sorry for the delay in responding. We've actually done some
warning cleanups in our CVS base versions, so we'll work with
Chris and David to get these integrated into current OpenJDK,
although possibly not in time for Cleanup Day.
-Doug
From brandon.passanisi at oracle.com Thu Dec 1 12:54:39 2011
From: brandon.passanisi at oracle.com (Brandon Passanisi)
Date: Thu, 01 Dec 2011 12:54:39 -0800
Subject: Review Request for 7116993 (warning cleanup java.applet)
Message-ID: <4ED7E98F.3040200@oracle.com>
I have a webrev pertaining to the warning cleanup changes for
java.applet ready for review. Here's the info:
Bug: 7116993
Webrev:
http://cr.openjdk.java.net/~dmocek/bpassanisi/7116993/webrev.00/
<http://cr.openjdk.java.net/%7Edmocek/bpassanisi/7116993/webrev.00/>
Thanks.
--
Oracle <http://www.oracle.com>
Brandon Passanisi | Principle Member of Technical Staff
Oracle Java Standards Conformance
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
From brandon.passanisi at oracle.com Thu Dec 1 13:14:38 2011
From: brandon.passanisi at oracle.com (Brandon Passanisi)
Date: Thu, 01 Dec 2011 13:14:38 -0800
Subject: Review Request for 7116993 (warning cleanup java.applet)
In-Reply-To: <4ED7E98F.3040200@oracle.com>
References: <4ED7E98F.3040200@oracle.com>
Message-ID: <4ED7EE3E.6020109@oracle.com>
I'll withdraw this review request as I was notified by Xiomara that
someone else has been working on java.applet. I had sent an e-mail to
the alias yesterday about taking on java.applet though. Luckily, there
aren't many warnings in java.applet.
On 12/1/2011 12:54 PM, Brandon Passanisi wrote:
> I have a webrev pertaining to the warning cleanup changes for
> java.applet ready for review. Here's the info:
>
> Bug: 7116993
> Webrev:
> http://cr.openjdk.java.net/~dmocek/bpassanisi/7116993/webrev.00/
> <http://cr.openjdk.java.net/%7Edmocek/bpassanisi/7116993/webrev.00/>
>
> Thanks.
--
Oracle <http://www.oracle.com>
Brandon Passanisi | Principle Member of Technical Staff
Oracle Java Standards Conformance
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
From ddadacha at redhat.com Thu Dec 1 13:39:35 2011
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Thu, 01 Dec 2011 16:39:35 -0500
Subject: Review Request for 7116993 (warning cleanup java.applet)
In-Reply-To: <4ED7EE3E.6020109@oracle.com>
References: <4ED7E98F.3040200@oracle.com> <4ED7EE3E.6020109@oracle.com>
Message-ID: <4ED7F417.4040204@redhat.com>
Hi,
On 01/12/11 04:14 PM, Brandon Passanisi wrote:
> I'll withdraw this review request as I was notified by Xiomara that
> someone else has been working on java.applet. I had sent an e-mail to
> the alias yesterday about taking on java.applet though. Luckily, there
> aren't many warnings in java.applet.
Once again, I apologize for the confusion. I assumed sending a private
email would be fine with the info being on the wiki.
In any case, the changes I made are identical to yours so that's
promising! One thing that I noticed is that resize(int, int) calls a
deprecated Component.size() and Component.resize(int, int). Changing the
calls of size and super.resize to getSize and super.setSize respectively
might be better. However, that changes functionality. Comments on this?
As Brandon requested, I'll reuse the bug ID (7116993). My webrev is here:
http://icedtea.classpath.org/~ddadacha/warnings-cleanup-java-applet/
Regards,
Danesh
From kurchi.subhra.hazra at oracle.com Thu Dec 1 13:44:36 2011
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Thu, 01 Dec 2011 13:44:36 -0800
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <4ED7DD0B.8000604@cs.oswego.edu>
References: <CALwNKeQGkH5TXBJAxSLOGtO3AqW3=jjMw1ZZo0T=DBKC2eGygg@mail.gmail.com>
<4ED7DD0B.8000604@cs.oswego.edu>
Message-ID: <4ED7F544.1030104@oracle.com>
I am just moving to some other area for now. sun.management.* seems to
be having many warnings and no takers. I will work on that.
- Kurchi
On 12/1/2011 12:01 PM, Doug Lea wrote:
> On 11/30/11 04:03, Michael Barker wrote:
>> I can't seem to see anybody claim anything other than swing and awt
>> packages, so if no one has taken them we'll look at the subpackages of
>> java.util:
>>
>> java.util.concurrent
>> java.util.concurrent.atomic
>
> Sorry for the delay in responding. We've actually done some
> warning cleanups in our CVS base versions, so we'll work with
> Chris and David to get these integrated into current OpenJDK,
> although possibly not in time for Cleanup Day.
>
> -Doug
>
--
-Kurchi
From john.r.rose at oracle.com Thu Dec 1 14:34:44 2011
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 1 Dec 2011 14:34:44 -0800
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <4ED58A21.4040005@oracle.com>
References: <391b7649-4f85-47c2-805c-03aecc0ce5ac@default>
<CABKW8Rhf6au+Og==KviSDkZhM65vUdcn=HNayNEvpbbQHoMXGA@mail.gmail.com>
<4ED58A21.4040005@oracle.com>
Message-ID: <7BDBA743-080F-47CB-99F7-B2A74A01F35D@oracle.com>
I am cleaning up warnings in java.lang.invoke. -- John
From xiomara.jayasena at oracle.com Thu Dec 1 14:39:53 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Thu, 1 Dec 2011 14:39:53 -0800 (PST)
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <7BDBA743-080F-47CB-99F7-B2A74A01F35D@oracle.com>
References: <391b7649-4f85-47c2-805c-03aecc0ce5ac@default>
<CABKW8Rhf6au+Og==KviSDkZhM65vUdcn=HNayNEvpbbQHoMXGA@mail.gmail.com>
<4ED58A21.4040005@oracle.com
7BDBA743-080F-47CB-99F7-B2A74A01F35D@oracle.com>
Message-ID: <b813344d-b500-4f6f-b39f-9d47245497b7@default>
Hi John,
I think Jon van Alten has already said that he will work on that, see wiki:
http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
-Xiomara
> -----Original Message-----
> From: John Rose
> Sent: Thursday, December 01, 2011 2:35 PM
> To: jdk8-dev at openjdk.java.net
> Subject: Re: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
>
> I am cleaning up warnings in java.lang.invoke. -- John
From david.katleman at sun.com Thu Dec 1 14:48:48 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 01 Dec 2011 22:48:48 +0000
Subject: hg: jdk8/jdk8: Added tag jdk8-b15 for changeset a4f28069d44a
Message-ID: <20111201224848.DF8BB474F0@hg.openjdk.java.net>
Changeset: 4e06ae613e99
Author: katleman
Date: 2011-12-01 10:33 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/4e06ae613e99
Added tag jdk8-b15 for changeset a4f28069d44a
! .hgtags
From david.katleman at sun.com Thu Dec 1 14:48:54 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 01 Dec 2011 22:48:54 +0000
Subject: hg: jdk8/jdk8/corba: Added tag jdk8-b15 for changeset 7da69e7175a7
Message-ID: <20111201224855.94D1E474F1@hg.openjdk.java.net>
Changeset: 82dc033975bb
Author: katleman
Date: 2011-12-01 10:33 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/82dc033975bb
Added tag jdk8-b15 for changeset 7da69e7175a7
! .hgtags
From jon.vanalten at redhat.com Thu Dec 1 14:49:21 2011
From: jon.vanalten at redhat.com (Jon VanAlten)
Date: Thu, 01 Dec 2011 17:49:21 -0500 (EST)
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <b813344d-b500-4f6f-b39f-9d47245497b7@default>
Message-ID: <e3d78cee-d23f-427d-9974-0c9032d686f5@zmail13.collab.prod.int.phx2.redhat.com>
Hi John and Xiomara,
Unfortunately some urgent things came across my plate today, and then I seemed to hit every possible bit of jdk-building-weirdness. I'm not going to be getting anything in before today's deadline, it looks like. If you'd like to take over java.lang.invoke John, I won't mind. I will still do some part at least and submit something for the other two small groups of errors. (and maybe follow up with picking at the carrion still remaining tomorrow, to make up for today!).
cheers,
jon
----- Original Message -----
> From: "Xiomara Jayasena" <xiomara.jayasena at oracle.com>
> To: "John Rose" <john.r.rose at oracle.com>, jdk8-dev at openjdk.java.net
> Sent: Thursday, December 1, 2011 5:39:53 PM
> Subject: RE: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
>
>
> Hi John,
>
> I think Jon van Alten has already said that he will work on that, see
> wiki:
> http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
>
> -Xiomara
>
>
> > -----Original Message-----
> > From: John Rose
> > Sent: Thursday, December 01, 2011 2:35 PM
> > To: jdk8-dev at openjdk.java.net
> > Subject: Re: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
> >
> > I am cleaning up warnings in java.lang.invoke. -- John
>
From david.katleman at sun.com Thu Dec 1 14:49:22 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 01 Dec 2011 22:49:22 +0000
Subject: hg: jdk8/jdk8/hotspot: Added tag jdk8-b15 for changeset fde2a39ed7f3
Message-ID: <20111201224926.4AE0C474F2@hg.openjdk.java.net>
Changeset: d1f29d4e0bc6
Author: katleman
Date: 2011-12-01 10:33 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d1f29d4e0bc6
Added tag jdk8-b15 for changeset fde2a39ed7f3
! .hgtags
From david.katleman at sun.com Thu Dec 1 14:50:11 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 01 Dec 2011 22:50:11 +0000
Subject: hg: jdk8/jdk8/jaxp: Added tag jdk8-b15 for changeset 804f666d6d44
Message-ID: <20111201225011.4C440474F3@hg.openjdk.java.net>
Changeset: 8181f7634e4a
Author: katleman
Date: 2011-12-01 10:33 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/8181f7634e4a
Added tag jdk8-b15 for changeset 804f666d6d44
! .hgtags
From david.katleman at sun.com Thu Dec 1 14:50:17 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 01 Dec 2011 22:50:17 +0000
Subject: hg: jdk8/jdk8/jaxws: Added tag jdk8-b15 for changeset c9ab96ff23d5
Message-ID: <20111201225017.50BCE474F4@hg.openjdk.java.net>
Changeset: 76e37e606354
Author: katleman
Date: 2011-12-01 10:33 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/76e37e606354
Added tag jdk8-b15 for changeset c9ab96ff23d5
! .hgtags
From david.katleman at sun.com Thu Dec 1 14:50:29 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 01 Dec 2011 22:50:29 +0000
Subject: hg: jdk8/jdk8/jdk: Added tag jdk8-b15 for changeset 3c248d0e2c48
Message-ID: <20111201225039.13427474F5@hg.openjdk.java.net>
Changeset: 929597c6e777
Author: katleman
Date: 2011-12-01 10:33 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/929597c6e777
Added tag jdk8-b15 for changeset 3c248d0e2c48
! .hgtags
From david.katleman at sun.com Thu Dec 1 14:51:33 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 01 Dec 2011 22:51:33 +0000
Subject: hg: jdk8/jdk8/langtools: Added tag jdk8-b15 for changeset 07599bd780ca
Message-ID: <20111201225136.D5E1E474F6@hg.openjdk.java.net>
Changeset: ec2c0973cc31
Author: katleman
Date: 2011-12-01 10:33 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ec2c0973cc31
Added tag jdk8-b15 for changeset 07599bd780ca
! .hgtags
From john.r.rose at oracle.com Thu Dec 1 14:55:34 2011
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 1 Dec 2011 14:55:34 -0800
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <2f23622d-8671-4924-ac10-511215892161@zmail13.collab.prod.int.phx2.redhat.com>
References: <2f23622d-8671-4924-ac10-511215892161@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <2A94C4E0-DA3A-44DB-99A2-F36C532E6EB2@oracle.com>
OK, thanks Jon. Here's the webrev of what I have so far:
http://cr.openjdk.java.net/~jrose/7117167/webrev.00/
I filed 7117167 to deal with just the JSR 292 code warnings.
Best wishes,
-- John
On Dec 1, 2011, at 2:47 PM, Jon VanAlten wrote:
> Hi John and Xiomara,
>
> Unfortunately some urgent things came across my plate today, and then I seemed to hit every possible bit of jdk-building-weirdness. I'm not going to be getting anything in before today's deadline, it looks like. If you'd like to take over java.lang.invoke John, I won't mind. I will still do some part at least and submit something for the other two small groups of errors. (and maybe follow up with picking at the carrion still remaining tomorrow, to make up for today!).
>
> cheers,
> jon
>
> ----- Original Message -----
>> From: "Xiomara Jayasena" <xiomara.jayasena at oracle.com>
>> To: "John Rose" <john.r.rose at oracle.com>, jdk8-dev at openjdk.java.net
>> Sent: Thursday, December 1, 2011 5:39:53 PM
>> Subject: RE: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
>>
>>
>> Hi John,
>>
>> I think Jon van Alten has already said that he will work on that, see
>> wiki:
>> http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
>>
>> -Xiomara
>>
>>
>>> -----Original Message-----
>>> From: John Rose
>>> Sent: Thursday, December 01, 2011 2:35 PM
>>> To: jdk8-dev at openjdk.java.net
>>> Subject: Re: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
>>>
>>> I am cleaning up warnings in java.lang.invoke. -- John
>>
From john.r.rose at oracle.com Thu Dec 1 15:12:05 2011
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 1 Dec 2011 15:12:05 -0800
Subject: review request (M): 7117167: Misc warnings in java.lang.invoke and
sun.invoke.*
Message-ID: <454EA54E-6326-4621-A9DC-D03688F1B9AD@oracle.com>
7117167: Misc warnings in java.lang.invoke and sun.invoke.*
http://cr.openjdk.java.net/~jrose/7117167/webrev.00/
Removing build warnings from java.lang.invoke and sun.invoke.*, as part of the December 2011 cleanup effort.
-- John
P.S. The M is an informal convention for "medium complexity"; reviewers typically choose from XS, S, M, L, XL, etc.
From forax at univ-mlv.fr Thu Dec 1 15:13:10 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 02 Dec 2011 00:13:10 +0100
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <2A94C4E0-DA3A-44DB-99A2-F36C532E6EB2@oracle.com>
References: <2f23622d-8671-4924-ac10-511215892161@zmail13.collab.prod.int.phx2.redhat.com>
<2A94C4E0-DA3A-44DB-99A2-F36C532E6EB2@oracle.com>
Message-ID: <4ED80A06.90903@univ-mlv.fr>
On 12/01/2011 11:55 PM, John Rose wrote:
> OK, thanks Jon. Here's the webrev of what I have so far:
> http://cr.openjdk.java.net/~jrose/7117167/webrev.00/
>
> I filed 7117167 to deal with just the JSR 292 code warnings.
>
> Best wishes,
> -- John
Hi John,
I think you should remove the declared type(s) parameter(s) of
AllocateObject
and FieldAccessor because it's weird to have a parametrized class
which is only used as a raw type.
generics are a compiler artefact, not a runtime one.
cheers,
R?mi
>
> On Dec 1, 2011, at 2:47 PM, Jon VanAlten wrote:
>
>> Hi John and Xiomara,
>>
>> Unfortunately some urgent things came across my plate today, and then I seemed to hit every possible bit of jdk-building-weirdness. I'm not going to be getting anything in before today's deadline, it looks like. If you'd like to take over java.lang.invoke John, I won't mind. I will still do some part at least and submit something for the other two small groups of errors. (and maybe follow up with picking at the carrion still remaining tomorrow, to make up for today!).
>>
>> cheers,
>> jon
>>
>> ----- Original Message -----
>>> From: "Xiomara Jayasena"<xiomara.jayasena at oracle.com>
>>> To: "John Rose"<john.r.rose at oracle.com>, jdk8-dev at openjdk.java.net
>>> Sent: Thursday, December 1, 2011 5:39:53 PM
>>> Subject: RE: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
>>>
>>>
>>> Hi John,
>>>
>>> I think Jon van Alten has already said that he will work on that, see
>>> wiki:
>>> http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
>>>
>>> -Xiomara
>>>
>>>
>>>> -----Original Message-----
>>>> From: John Rose
>>>> Sent: Thursday, December 01, 2011 2:35 PM
>>>> To: jdk8-dev at openjdk.java.net
>>>> Subject: Re: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
>>>>
>>>> I am cleaning up warnings in java.lang.invoke. -- John
From dbhole at redhat.com Thu Dec 1 15:19:19 2011
From: dbhole at redhat.com (Deepak Bhole)
Date: Thu, 1 Dec 2011 18:19:19 -0500
Subject: Review request for java.text.** warning cleanup
Message-ID: <20111201231919.GQ2461@redhat.com>
Hi All,
Here are all the warning fixes for java.text.**:
http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.00/
I have added suppressions where fixes would cause compatibility
breakage, or where fixes would be too convoluted (e.g the ever so fun
genericized array creation :)).
Cheers,
Deepak
From john.r.rose at oracle.com Thu Dec 1 15:34:50 2011
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 1 Dec 2011 15:34:50 -0800
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <4ED80A06.90903@univ-mlv.fr>
References: <2f23622d-8671-4924-ac10-511215892161@zmail13.collab.prod.int.phx2.redhat.com>
<2A94C4E0-DA3A-44DB-99A2-F36C532E6EB2@oracle.com>
<4ED80A06.90903@univ-mlv.fr>
Message-ID: <C6170FCA-9C01-400E-91F9-4373B0CFE155@oracle.com>
On Dec 1, 2011, at 3:13 PM, R?mi Forax wrote:
> I think you should remove the declared type(s) parameter(s) of AllocateObject
> and FieldAccessor because it's weird to have a parametrized class
> which is only used as a raw type.
The type params are weird, but they do serve a purpose. I'll think again about taking them off.
-- John
From forax at univ-mlv.fr Thu Dec 1 15:59:22 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 02 Dec 2011 00:59:22 +0100
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <C6170FCA-9C01-400E-91F9-4373B0CFE155@oracle.com>
References: <2f23622d-8671-4924-ac10-511215892161@zmail13.collab.prod.int.phx2.redhat.com>
<2A94C4E0-DA3A-44DB-99A2-F36C532E6EB2@oracle.com>
<4ED80A06.90903@univ-mlv.fr>
<C6170FCA-9C01-400E-91F9-4373B0CFE155@oracle.com>
Message-ID: <4ED814DA.1000501@univ-mlv.fr>
On 12/02/2011 12:34 AM, John Rose wrote:
> On Dec 1, 2011, at 3:13 PM, R?mi Forax wrote:
>
>> I think you should remove the declared type(s) parameter(s) of
>> AllocateObject
>> and FieldAccessor because it's weird to have a parametrized class
>> which is only used as a raw type.
>
> The type params are weird, but they do serve a purpose. I'll think
> again about taking them off.
In my opinion, doc comments are better in this case.
>
> -- John
R?mi
From mikeb01 at gmail.com Thu Dec 1 15:58:42 2011
From: mikeb01 at gmail.com (Michael Barker)
Date: Thu, 1 Dec 2011 23:58:42 +0000
Subject: Warnings Cleanup in java.util.<various>
Message-ID: <CALwNKeRhUTkBj3EeNmST=Acecnf1F7kifwwNbug5uW1U23Nh7A@mail.gmail.com>
Hi,
Here is the output of our (unfortunately short) hack session. There
are warnings fixed in 4 files. A patch is included in each. Mostly
just generics and deprecation warnings.
Regards,
Michael Barker.
Contributor/UserId: mikeb2701
From mikeb01 at gmail.com Thu Dec 1 16:06:18 2011
From: mikeb01 at gmail.com (Michael Barker)
Date: Fri, 2 Dec 2011 00:06:18 +0000
Subject: Warnings Cleanup in java.util.<various>
In-Reply-To: <CALwNKeRhUTkBj3EeNmST=Acecnf1F7kifwwNbug5uW1U23Nh7A@mail.gmail.com>
References: <CALwNKeRhUTkBj3EeNmST=Acecnf1F7kifwwNbug5uW1U23Nh7A@mail.gmail.com>
Message-ID: <CALwNKeRYO7m278NfpTtXoSaLQjTJkAxDJG9O98_3QuQKjmMsdw@mail.gmail.com>
Looks like the list software has stripped off the attachments from my
previous mail (my outbox shows them attached).
Here's a second attempt.
On Thu, Dec 1, 2011 at 11:58 PM, Michael Barker <mikeb01 at gmail.com> wrote:
> Hi,
>
> Here is the output of our (unfortunately short) hack session. ?There
> are warnings fixed in 4 files. ?A patch is included in each. ?Mostly
> just generics and deprecation warnings.
>
> Regards,
> Michael Barker.
> Contributor/UserId: mikeb2701
From ddadacha at redhat.com Thu Dec 1 16:09:18 2011
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Thu, 01 Dec 2011 19:09:18 -0500
Subject: Areas of work: JDK8 Warnings Cleanup Day (WCD)
In-Reply-To: <868c0635-11fc-4bc7-9ee9-64513092526e@default>
References: <868c0635-11fc-4bc7-9ee9-64513092526e@default>
Message-ID: <4ED8172E.1090804@redhat.com>
Hi,
I'd also like to try my hand at javax/imageio/ImageReader.java and
javax/imageio/ImageWriter.java
Hopefully I'll have enough time tomorrow to do some more imageio/*.java
classes but for now, I'll stick to these.
Regards,
Danesh
From mikeb01 at gmail.com Thu Dec 1 16:11:46 2011
From: mikeb01 at gmail.com (Michael Barker)
Date: Fri, 2 Dec 2011 00:11:46 +0000
Subject: Warnings Cleanup in java.util.<various>
In-Reply-To: <CALwNKeRYO7m278NfpTtXoSaLQjTJkAxDJG9O98_3QuQKjmMsdw@mail.gmail.com>
References: <CALwNKeRhUTkBj3EeNmST=Acecnf1F7kifwwNbug5uW1U23Nh7A@mail.gmail.com>
<CALwNKeRYO7m278NfpTtXoSaLQjTJkAxDJG9O98_3QuQKjmMsdw@mail.gmail.com>
Message-ID: <CALwNKeSBmnpPLr0hSWdDzCVYo7mjizi207Nj6ayVDKc1QaAdMw@mail.gmail.com>
Trying once more with a .txt extension. If that fails I'll inline the patch.
Mike.
On Fri, Dec 2, 2011 at 12:06 AM, Michael Barker <mikeb01 at gmail.com> wrote:
> Looks like the list software has stripped off the attachments from my
> previous mail (my outbox shows them attached).
>
> Here's a second attempt.
>
> On Thu, Dec 1, 2011 at 11:58 PM, Michael Barker <mikeb01 at gmail.com> wrote:
>> Hi,
>>
>> Here is the output of our (unfortunately short) hack session. ?There
>> are warnings fixed in 4 files. ?A patch is included in each. ?Mostly
>> just generics and deprecation warnings.
>>
>> Regards,
>> Michael Barker.
>> Contributor/UserId: mikeb2701
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/jar/JarFile.java
--- a/src/share/classes/java/util/jar/JarFile.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/jar/JarFile.java Thu Dec 01 23:50:32 2011 +0000
@@ -183,7 +183,7 @@
} else {
man = new Manifest(super.getInputStream(manEntry));
}
- manRef = new SoftReference(man);
+ manRef = new SoftReference<Manifest>(man);
}
}
return man;
@@ -233,7 +233,7 @@
* Returns an enumeration of the zip file entries.
*/
public Enumeration<JarEntry> entries() {
- final Enumeration enum_ = super.entries();
+ final Enumeration<? extends ZipEntry> enum_ = super.entries();
return new Enumeration<JarEntry>() {
public boolean hasMoreElements() {
return enum_.hasMoreElements();
@@ -608,7 +608,7 @@
}
// screen out entries which are never signed
- final Enumeration enum_ = super.entries();
+ final Enumeration<? extends ZipEntry> enum_ = super.entries();
return new Enumeration<JarEntry>() {
ZipEntry entry;
@@ -649,7 +649,7 @@
* JAR file has no signed content. Is there a non-signing
* code source?
*/
- Enumeration unsigned = unsignedEntryNames();
+ Enumeration<String> unsigned = unsignedEntryNames();
if (unsigned.hasMoreElements()) {
return new CodeSource[]{JarVerifier.getUnsignedCS(url)};
} else {
@@ -658,7 +658,7 @@
}
private Enumeration<String> unsignedEntryNames() {
- final Enumeration entries = entries();
+ final Enumeration<JarEntry> entries = entries();
return new Enumeration<String>() {
String name;
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/logging/LogManager.java
--- a/src/share/classes/java/util/logging/LogManager.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/logging/LogManager.java Thu Dec 01 23:51:52 2011 +0000
@@ -179,10 +179,10 @@
cname = System.getProperty("java.util.logging.manager");
if (cname != null) {
try {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(cname);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(cname);
manager = (LogManager) clz.newInstance();
} catch (ClassNotFoundException ex) {
- Class clz = Thread.currentThread().getContextClassLoader().loadClass(cname);
+ Class<?> clz = Thread.currentThread().getContextClassLoader().loadClass(cname);
manager = (LogManager) clz.newInstance();
}
}
@@ -200,8 +200,8 @@
// Adding the global Logger. Doing so in the Logger.<clinit>
// would deadlock with the LogManager.<clinit>.
- Logger.global.setLogManager(manager);
- manager.addLogger(Logger.global);
+ Logger.getGlobal().setLogManager(manager);
+ manager.addLogger(Logger.getGlobal());
// We don't call readConfiguration() here, as we may be running
// very early in the JVM startup sequence. Instead readConfiguration
@@ -415,7 +415,7 @@
for (int i = 0; i < names.length; i++) {
String word = names[i];
try {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(word);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(word);
Handler hdl = (Handler) clz.newInstance();
try {
// Check if there is a property defining the
@@ -782,11 +782,11 @@
// responsibility to initialize the logging configuration, by
// calling readConfiguration(InputStream) with a suitable stream.
try {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(cname);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(cname);
clz.newInstance();
return;
} catch (ClassNotFoundException ex) {
- Class clz = Thread.currentThread().getContextClassLoader().loadClass(cname);
+ Class<?> clz = Thread.currentThread().getContextClassLoader().loadClass(cname);
clz.newInstance();
return;
}
@@ -837,9 +837,9 @@
// the global handlers, if they haven't been initialized yet.
initializedGlobalHandlers = true;
}
- Enumeration enum_ = getLoggerNames();
+ Enumeration<String> enum_ = getLoggerNames();
while (enum_.hasMoreElements()) {
- String name = (String)enum_.nextElement();
+ String name = enum_.nextElement();
resetLogger(name);
}
}
@@ -926,7 +926,7 @@
for (int i = 0; i < names.length; i++) {
String word = names[i];
try {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(word);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(word);
clz.newInstance();
} catch (Exception ex) {
System.err.println("Can't load config class \"" + word + "\"");
@@ -1024,7 +1024,7 @@
String val = getProperty(name);
try {
if (val != null) {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(val);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(val);
return (Filter) clz.newInstance();
}
} catch (Exception ex) {
@@ -1045,7 +1045,7 @@
String val = getProperty(name);
try {
if (val != null) {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(val);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(val);
return (Formatter) clz.newInstance();
}
} catch (Exception ex) {
@@ -1163,9 +1163,9 @@
// Private method to be called when the configuration has
// changed to apply any level settings to any pre-existing loggers.
synchronized private void setLevelsOnExistingLoggers() {
- Enumeration enum_ = props.propertyNames();
- while (enum_.hasMoreElements()) {
- String key = (String)enum_.nextElement();
+ Iterator<String> it_ = props.stringPropertyNames().iterator();
+ while (it_.hasNext()) {
+ String key = it_.next();
if (!key.endsWith(".level")) {
// Not a level definition.
continue;
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/prefs/Preferences.java
--- a/src/share/classes/java/util/prefs/Preferences.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/prefs/Preferences.java Thu Dec 01 23:51:06 2011 +0000
@@ -413,7 +413,7 @@
* @throws IllegalArgumentException if the package has node preferences
* node associated with it.
*/
- private static String nodeName(Class c) {
+ private static String nodeName(Class<?> c) {
if (c.isArray())
throw new IllegalArgumentException(
"Arrays have no associated preferences node.");
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/prefs/XmlSupport.java
--- a/src/share/classes/java/util/prefs/XmlSupport.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/prefs/XmlSupport.java Thu Dec 01 23:51:21 2011 +0000
@@ -106,7 +106,7 @@
xmlRoot.setAttribute("type", (p.isUserNode() ? "user" : "system"));
// Get bottom-up list of nodes from p to root, excluding root
- List ancestors = new ArrayList();
+ List<Preferences> ancestors = new ArrayList<>();
for (Preferences kid = p, dad = kid.parent(); dad != null;
kid = dad, dad = kid.parent()) {
@@ -116,7 +116,7 @@
for (int i=ancestors.size()-1; i >= 0; i--) {
e.appendChild(doc.createElement("map"));
e = (Element) e.appendChild(doc.createElement("node"));
- e.setAttribute("name", ((Preferences)ancestors.get(i)).name());
+ e.setAttribute("name", ancestors.get(i).name());
}
putPreferencesInXml(e, doc, p, subTree);
@@ -339,17 +339,17 @@
* @throws IOException if writing to the specified output stream
* results in an <tt>IOException</tt>.
*/
- static void exportMap(OutputStream os, Map map) throws IOException {
+ static void exportMap(OutputStream os, Map<String, String> map) throws IOException {
Document doc = createPrefsDoc("map");
Element xmlMap = doc.getDocumentElement( ) ;
xmlMap.setAttribute("MAP_XML_VERSION", MAP_XML_VERSION);
- for (Iterator i = map.entrySet().iterator(); i.hasNext(); ) {
- Map.Entry e = (Map.Entry) i.next();
+ for (Iterator<Map.Entry<String, String>> i = map.entrySet().iterator(); i.hasNext(); ) {
+ Map.Entry<String, String> e = i.next();
Element xe = (Element)
xmlMap.appendChild(doc.createElement("entry"));
- xe.setAttribute("key", (String) e.getKey());
- xe.setAttribute("value", (String) e.getValue());
+ xe.setAttribute("key", e.getKey());
+ xe.setAttribute("value", e.getValue());
}
writeDoc(doc, os);
@@ -368,7 +368,7 @@
* @throws InvalidPreferencesFormatException Data on input stream does not
* constitute a valid XML document with the mandated document type.
*/
- static void importMap(InputStream is, Map m)
+ static void importMap(InputStream is, Map<String, String> m)
throws IOException, InvalidPreferencesFormatException
{
try {
From john.r.rose at oracle.com Thu Dec 1 16:49:11 2011
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 1 Dec 2011 16:49:11 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <20111201231919.GQ2461@redhat.com>
References: <20111201231919.GQ2461@redhat.com>
Message-ID: <1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
On Dec 1, 2011, at 3:19 PM, Deepak Bhole wrote:
> Hi All,
>
> Here are all the warning fixes for java.text.**:
>
> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.00/
>
> I have added suppressions where fixes would cause compatibility
> breakage, or where fixes would be too convoluted (e.g the ever so fun
> genericized array creation :)).
Thanks for doing all this work! I have some review comments.
Bottom line: In some few cases, I think the the @SuppressWarnings annotations can be refined. Also, I am worried that there are one or two API signature changes or behavior changes.
Details:
On chunks like this:
- HashSet keys = new HashSet();
+ HashSet<Attribute> keys = new HashSet<Attribute>();
consider using new HashSet<>().
See also occurrences of new Vector<Attribute>, new HashSet<Map.Entry<Attribute, Object>>, SoftReference<BreakIteratorCache>, etc.
(Netbeans can find opportunities for diamond operators, BTW.)
The new parameters <K extends Attribute, V> are clearly more correct, but they look like an API change on a public method or constructor. If so, I think you'll have to find a different approach. (But I'm not an API change and generics expert.)
A trivial refactoring to use a private parameterized method might work nicely, but we're not doing refactorings today.
For createRunAttributeDataVectors, ensureRunBreak, etc. consider pushing the @SuppressWarnings down onto the individual declarations. It is best to put @SuppressWarnings on the smallest program unit possible, and a local variable declaration is often the right spot. I see that createRunAttributeDataVectors could be viewed as simple enough to mark as a whole, but ensureRunBreak is probably too complex to mark as a whole.
In the same way, consider pushing the annotation into the body of class AttributeEntry, even though that class is very simple.
For generic array creation, I suggest that you get rid of the "rawtypes" warning on the array element type by adding <?>, before suppressing the "unchecked" warning. Basically, when you find yourself writing new Foo<Bar>[len], change it to new Foo<?>[len]. Then, if you still get an unchecked warning, add SuppressWarnings.
- Vector newRunAttributes[] = new Vector[newArraySize];
- Vector newRunAttributeValues[] = new Vector[newArraySize];
+ @SuppressWarnings("unchecked") // generic array creation
+ Vector<Attribute> newRunAttributes[] = new Vector<?>[newArraySize];
+ @SuppressWarnings("unchecked") // generic array creation
+ Vector<Object> newRunAttributeValues[] = new Vector<?>[newArraySize];
It is probably a good idea to put a comment on most @SuppressWarnings annotations.
Similarly:
- private static final SoftReference[] iterCache = new SoftReference[4];
+
+ @SuppressWarnings({"unchecked","rawtypes"})
+ private static final SoftReference<BreakIteratorCache>[] iterCache = new SoftReference[4];
++ @SuppressWarnings("unchecked")
++ private static final SoftReference<BreakIteratorCache>[] iterCache = new SoftReference<?>[4];
There is an apparent behavior change in CollationElementIterator.setOffset, in this chunk:
- int c = text.setIndex(newOffset);
+ text.setIndexOnly(newOffset);
+ int c = text.current();
(About 50% through. More to come...)
Best wishes,
-- John
From stuart.marks at oracle.com Thu Dec 1 17:17:55 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 01 Dec 2011 17:17:55 -0800
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <4ED5F821.3040906@oracle.com>
References: <391b7649-4f85-47c2-805c-03aecc0ce5ac@default>
<4ED5F821.3040906@oracle.com>
Message-ID: <4ED82743.6030209@oracle.com>
Hi Max,
It looks like you filed 7116857 to cover this already. Great.
On the ServicePermission.java change, it seems to me like it would be better to
change the /*FALLTHROUGH*/ comment to a "break" and then remove
@SuppressWarnings. Is there a reason we can't do this? It looks like the code
would behave the same and we can get rid of the warning.
(Incidentally, this is the third time I've reviewed code today that looks
exactly like this. The other cases are in java.io.FilePermission and
java.util.PropertyPermission. They each have the /*FALLTHROUGH*/ into a set of
cases that do nothing but break; and they have similar ("ackbarfaccept")
comments. It would be nice if these chunks of code could be unified, but they
differ in a number of fiddly details.)
(The string "ackbarfaccept" occurs in the following files:
1. java/io/FilePermission.java
2. java/net/SocketPermission.java
3. java/util/PropertyPermission.java
4. javax/management/MBeanPermission.java
5. javax/security/auth/kerberos/ServicePermission.java
Hmmm.)
Note that ChrisH has already done the BASE64Decoder.java change.
The other changes look fine.
s'marks
On 11/30/11 1:32 AM, Weijun Wang wrote:
> On 11/29/2011 10:10 AM, Xiomara Jayasena wrote:
>> 6. In order to streamlines the process, Stuart Marks will be consolidating
>> patches and running build and test jobs - thanks to Stuart for doing this!
>
> I cd into several security-related directories, call make clobber, and then
> call make. Only one warning in javax/security, others are inside sun/misc. The
> fix is trivial so I won't create a CR or a webrev.
>
> Thanks
> Max
>
>
> diff --git
> a/src/share/classes/javax/security/auth/kerberos/ServicePermission.java
> b/src/share/classes/javax/security/auth/kerberos/ServicePermission.java
> --- a/src/share/classes/javax/security/auth/kerberos/ServicePermission.java
> +++ b/src/share/classes/javax/security/auth/kerberos/ServicePermission.java
> @@ -301,7 +301,7 @@
> * @param action the action string
> * @return the action mask
> */
> -
> + @SuppressWarnings("fallthrough")
> private static int getMask(String action) {
>
> if (action == null) {
> diff --git a/src/share/classes/sun/misc/BASE64Decoder.java
> b/src/share/classes/sun/misc/BASE64Decoder.java
> --- a/src/share/classes/sun/misc/BASE64Decoder.java
> +++ b/src/share/classes/sun/misc/BASE64Decoder.java
> @@ -102,6 +102,7 @@
> /**
> * Decode one BASE64 atom into 1, 2, or 3 bytes of data.
> */
> + @SuppressWarnings({"fallthrough"})
> protected void decodeAtom(PushbackInputStream inStream, OutputStream outStream,
> int rem)
> throws java.io.IOException
> {
> diff --git a/src/share/classes/sun/misc/CEFormatException.java
> b/src/share/classes/sun/misc/CEFormatException.java
> --- a/src/share/classes/sun/misc/CEFormatException.java
> +++ b/src/share/classes/sun/misc/CEFormatException.java
> @@ -28,7 +28,9 @@
> import java.io.IOException;
>
> public class CEFormatException extends IOException {
> - public CEFormatException(String s) {
> - super(s);
> - }
> + static final long serialVersionUID = -7139121221067081482L;
> + public CEFormatException(String s) {
> + super(s);
> + }
> }
> +
> diff --git a/src/share/classes/sun/misc/CEStreamExhausted.java
> b/src/share/classes/sun/misc/CEStreamExhausted.java
> --- a/src/share/classes/sun/misc/CEStreamExhausted.java
> +++ b/src/share/classes/sun/misc/CEStreamExhausted.java
> @@ -27,4 +27,7 @@
> import java.io.IOException;
>
> /** This exception is thrown when EOF is reached */
> -public class CEStreamExhausted extends IOException { };
> +public class CEStreamExhausted extends IOException {
> + static final long serialVersionUID = -5889118049525891904L;
> +}
> +
From john.r.rose at oracle.com Thu Dec 1 17:17:57 2011
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 1 Dec 2011 17:17:57 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
Message-ID: <6000B656-E38B-478E-A467-508F9A1CC13B@oracle.com>
On Dec 1, 2011, at 4:49 PM, John Rose wrote:
> On Dec 1, 2011, at 3:19 PM, Deepak Bhole wrote:
>
>> Hi All,
>>
>> Here are all the warning fixes for java.text.**:
>>
>> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.00/
>>
>> I have added suppressions where fixes would cause compatibility
>> breakage, or where fixes would be too convoluted (e.g the ever so fun
>> genericized array creation :)).
>
> Thanks for doing all this work! I have some review comments.
> ...
>
> (About 50% through. More to come...)
Here's the rest.
I think the method divideUpDictionaryRange is too complex (181 LOC) to be covered by one @SuppressWarnings. Even adding 30 annotations in the body would be better, since then the other 151 LOC would remain protected.
I do like the informative comment on @SuppressWarnings:
+ @SuppressWarnings("unchecked") // suppress unchecked warning for cloning stack
Extra parens (only needed when there was a cast) can go away:
+ cachedBreakPositions[i + 1] = (currentBreakPositions.elementAt(i)).intValue();
++ cachedBreakPositions[i + 1] = currentBreakPositions.elementAt(i).intValue();
This one has to be on the method level, of course. Good comment; suggest s/fallthrough/fallthrough in switch/.
+ @SuppressWarnings("fallthrough") // fallthrough is expected, suppress it
Diamond operator, again:
+ ArrayList<AttributedCharacterIterator> iterators = new ArrayList<AttributedCharacterIterator>();
++ ArrayList<AttributedCharacterIterator> iterators = new ArrayList<>();
and:
+ private static final Hashtable<Locale, String[]> cachedLocaleData = new Hashtable<Locale, String[]>(3);
++ private static final Hashtable<Locale, String[]> cachedLocaleData = new Hashtable<>(3);
+ private static final Map<String, Field> instanceMap = new HashMap<String, Field>(11);
++ private static final Map<String, Field> instanceMap = new HashMap<>(11);
+ entryTable = new Vector<EntryPair>(INITIALTABLESIZE);
++ entryTable = new Vector<>(INITIALTABLESIZE);
This one has to be at class level; good comment:
+ at SuppressWarnings("serial") // Adding serial ID will break compatibility. Suppress it.
There is a peculiar space in the "int []" type name; consider removing it:
+ Vector<int []> eTbl,
++ Vector<int[]> eTbl,
+ private Vector<int []> expandTable = null;
++ private Vector<int[]> expandTable = null;
+ expandTable = new Vector<int []>(INITIALTABLESIZE);
++ expandTable = new Vector<int[]>(INITIALTABLESIZE);
+ private Vector<int []> expandTable = null;
(etc.)
Majority usage in that package omits the space, and you delete the minority cases.
Regarding majority usage see M2 in http://blogs.oracle.com/jrose/entry/on_coding_style .
I'm done commenting.
Thanks for taking this on!
Best,
-- John
P.S. My recommendations about @SuppressWarnings are off the top of my head. See Josh Bloch's Effective Java for more and better of that sort of thing. (Hat tip to Stuart M. and Andrew Hughes.)
From stuart.marks at oracle.com Thu Dec 1 17:24:04 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 01 Dec 2011 17:24:04 -0800
Subject: quick Warnings Cleanup Day update
In-Reply-To: <20111202001420.0DAB8474F8@hg.openjdk.java.net>
References: <20111202001420.0DAB8474F8@hg.openjdk.java.net>
Message-ID: <4ED828B4.4070805@oracle.com>
At this point four warnings cleanup changesets have been pushed into the TL
forest. These reduce the number of warnings from a little over 10,000 to less
than 9,500. Pretty good!
There are a bunch of changesets that have been posted and are pending review. I
haven't gotten to those yet. I'm sure they knock off even more warnings.
I've created a little table with the running tally of warnings vs changesets as
they're integrated into the TL forest. It's on the wiki here [1].
s'marks
[1] http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
-------- Original Message --------
Subject: hg: jdk8/tl/jdk: 7116890: additional warnings fixes for java.io
Date: Fri, 02 Dec 2011 00:14:10 +0000
From: stuart.marks at oracle.com
To: jdk8-changes at openjdk.java.net, compiler-dev at openjdk.java.net,
core-libs-dev at openjdk.java.net, serviceability-dev at openjdk.java.net,
security-dev at openjdk.java.net, net-dev at openjdk.java.net
Changeset: 0e3f706741ca
Author: smarks
Date: 2011-12-01 16:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e3f706741ca
7116890: additional warnings fixes for java.io
Reviewed-by: alanb, smarks
Contributed-by: Sebastian Sickelmann <sebastian.sickelmann at gmx.de>
! src/share/classes/java/io/ExpiringCache.java
! src/share/classes/java/io/LineNumberInputStream.java
! src/share/classes/java/io/LineNumberReader.java
! src/share/classes/java/io/ObjectOutputStream.java
! src/share/classes/java/io/RandomAccessFile.java
From stuart.marks at oracle.com Thu Dec 1 17:27:14 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 01 Dec 2011 17:27:14 -0800
Subject: quick Warnings Cleanup Day update
In-Reply-To: <4ED828B4.4070805@oracle.com>
References: <20111202001420.0DAB8474F8@hg.openjdk.java.net>
<4ED828B4.4070805@oracle.com>
Message-ID: <4ED82972.5010305@oracle.com>
I forgot to mention... one of the four initial changesets was contributed by
Sebastian Sickelmann (change notification below) which is the first warnings
cleanup changeset contributed from outside of Oracle. Congratulations
Sebastian, and thanks.
s'marks
On 12/1/11 5:24 PM, Stuart Marks wrote:
> At this point four warnings cleanup changesets have been pushed into the TL
> forest. These reduce the number of warnings from a little over 10,000 to less
> than 9,500. Pretty good!
>
> There are a bunch of changesets that have been posted and are pending review. I
> haven't gotten to those yet. I'm sure they knock off even more warnings.
>
> I've created a little table with the running tally of warnings vs changesets as
> they're integrated into the TL forest. It's on the wiki here [1].
>
> s'marks
>
> [1] http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
>
> -------- Original Message --------
> Subject: hg: jdk8/tl/jdk: 7116890: additional warnings fixes for java.io
> Date: Fri, 02 Dec 2011 00:14:10 +0000
> From: stuart.marks at oracle.com
> To: jdk8-changes at openjdk.java.net, compiler-dev at openjdk.java.net,
> core-libs-dev at openjdk.java.net, serviceability-dev at openjdk.java.net,
> security-dev at openjdk.java.net, net-dev at openjdk.java.net
>
> Changeset: 0e3f706741ca
> Author: smarks
> Date: 2011-12-01 16:14 -0800
> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e3f706741ca
>
> 7116890: additional warnings fixes for java.io
> Reviewed-by: alanb, smarks
> Contributed-by: Sebastian Sickelmann <sebastian.sickelmann at gmx.de>
>
> ! src/share/classes/java/io/ExpiringCache.java
> ! src/share/classes/java/io/LineNumberInputStream.java
> ! src/share/classes/java/io/LineNumberReader.java
> ! src/share/classes/java/io/ObjectOutputStream.java
> ! src/share/classes/java/io/RandomAccessFile.java
>
From weijun.wang at oracle.com Thu Dec 1 17:41:44 2011
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 02 Dec 2011 09:41:44 +0800
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <4ED82743.6030209@oracle.com>
References: <391b7649-4f85-47c2-805c-03aecc0ce5ac@default>
<4ED5F821.3040906@oracle.com> <4ED82743.6030209@oracle.com>
Message-ID: <4ED82CD8.5080404@oracle.com>
On 12/02/2011 09:17 AM, Stuart Marks wrote:
> Hi Max,
>
> It looks like you filed 7116857 to cover this already. Great.
>
> On the ServicePermission.java change, it seems to me like it would be
> better to change the /*FALLTHROUGH*/ comment to a "break" and then
> remove @SuppressWarnings. Is there a reason we can't do this? It looks
> like the code would behave the same and we can get rid of the warning.
Yes, you are right. Sorry I haven't read the code carefully.
>
> (Incidentally, this is the third time I've reviewed code today that
> looks exactly like this. The other cases are in java.io.FilePermission
> and java.util.PropertyPermission. They each have the /*FALLTHROUGH*/
> into a set of cases that do nothing but break; and they have similar
> ("ackbarfaccept") comments. It would be nice if these chunks of code
> could be unified, but they differ in a number of fiddly details.)
>
> (The string "ackbarfaccept" occurs in the following files:
> 1. java/io/FilePermission.java
> 2. java/net/SocketPermission.java
> 3. java/util/PropertyPermission.java
> 4. javax/management/MBeanPermission.java
> 5. javax/security/auth/kerberos/ServicePermission.java
> Hmmm.)
This is funny. We might do something later.
>
> Note that ChrisH has already done the BASE64Decoder.java change.
Yes, I saw that. BTW, I've included some other sun.misc files and
created a webrev at
http://cr.openjdk.java.net/~weijun/7116857/webrev.00/
Some classes inside sun.misc are not touched, mainly
SoftCache/Ref/Cache. I tried them but not very successful.
Thanks
Max
>
> The other changes look fine.
>
> s'marks
>
> On 11/30/11 1:32 AM, Weijun Wang wrote:
>> On 11/29/2011 10:10 AM, Xiomara Jayasena wrote:
>>> 6. In order to streamlines the process, Stuart Marks will be
>>> consolidating
>>> patches and running build and test jobs - thanks to Stuart for doing
>>> this!
>>
>> I cd into several security-related directories, call make clobber, and
>> then
>> call make. Only one warning in javax/security, others are inside
>> sun/misc. The
>> fix is trivial so I won't create a CR or a webrev.
>>
>> Thanks
>> Max
>>
>>
>> diff --git
>> a/src/share/classes/javax/security/auth/kerberos/ServicePermission.java
>> b/src/share/classes/javax/security/auth/kerberos/ServicePermission.java
>> ---
>> a/src/share/classes/javax/security/auth/kerberos/ServicePermission.java
>> +++
>> b/src/share/classes/javax/security/auth/kerberos/ServicePermission.java
>> @@ -301,7 +301,7 @@
>> * @param action the action string
>> * @return the action mask
>> */
>> -
>> + @SuppressWarnings("fallthrough")
>> private static int getMask(String action) {
>>
>> if (action == null) {
>> diff --git a/src/share/classes/sun/misc/BASE64Decoder.java
>> b/src/share/classes/sun/misc/BASE64Decoder.java
>> --- a/src/share/classes/sun/misc/BASE64Decoder.java
>> +++ b/src/share/classes/sun/misc/BASE64Decoder.java
>> @@ -102,6 +102,7 @@
>> /**
>> * Decode one BASE64 atom into 1, 2, or 3 bytes of data.
>> */
>> + @SuppressWarnings({"fallthrough"})
>> protected void decodeAtom(PushbackInputStream inStream, OutputStream
>> outStream,
>> int rem)
>> throws java.io.IOException
>> {
>> diff --git a/src/share/classes/sun/misc/CEFormatException.java
>> b/src/share/classes/sun/misc/CEFormatException.java
>> --- a/src/share/classes/sun/misc/CEFormatException.java
>> +++ b/src/share/classes/sun/misc/CEFormatException.java
>> @@ -28,7 +28,9 @@
>> import java.io.IOException;
>>
>> public class CEFormatException extends IOException {
>> - public CEFormatException(String s) {
>> - super(s);
>> - }
>> + static final long serialVersionUID = -7139121221067081482L;
>> + public CEFormatException(String s) {
>> + super(s);
>> + }
>> }
>> +
>> diff --git a/src/share/classes/sun/misc/CEStreamExhausted.java
>> b/src/share/classes/sun/misc/CEStreamExhausted.java
>> --- a/src/share/classes/sun/misc/CEStreamExhausted.java
>> +++ b/src/share/classes/sun/misc/CEStreamExhausted.java
>> @@ -27,4 +27,7 @@
>> import java.io.IOException;
>>
>> /** This exception is thrown when EOF is reached */
>> -public class CEStreamExhausted extends IOException { };
>> +public class CEStreamExhausted extends IOException {
>> + static final long serialVersionUID = -5889118049525891904L;
>> +}
>> +
From david.holmes at oracle.com Thu Dec 1 17:56:15 2011
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 02 Dec 2011 11:56:15 +1000
Subject: Warnings Cleanup in java.util.<various>
In-Reply-To: <CALwNKeSBmnpPLr0hSWdDzCVYo7mjizi207Nj6ayVDKc1QaAdMw@mail.gmail.com>
References: <CALwNKeRhUTkBj3EeNmST=Acecnf1F7kifwwNbug5uW1U23Nh7A@mail.gmail.com>
<CALwNKeRYO7m278NfpTtXoSaLQjTJkAxDJG9O98_3QuQKjmMsdw@mail.gmail.com>
<CALwNKeSBmnpPLr0hSWdDzCVYo7mjizi207Nj6ayVDKc1QaAdMw@mail.gmail.com>
Message-ID: <4ED8303F.30108@oracle.com>
Michael,
The change to java/util/logging/LogManager.java that switches from an
Enumeration to an Iterator may be out of scope for this cleanup session.
David
On 2/12/2011 10:11 AM, Michael Barker wrote:
> Trying once more with a .txt extension. If that fails I'll inline the patch.
>
> Mike.
>
> On Fri, Dec 2, 2011 at 12:06 AM, Michael Barker<mikeb01 at gmail.com> wrote:
>> Looks like the list software has stripped off the attachments from my
>> previous mail (my outbox shows them attached).
>>
>> Here's a second attempt.
>>
>> On Thu, Dec 1, 2011 at 11:58 PM, Michael Barker<mikeb01 at gmail.com> wrote:
>>> Hi,
>>>
>>> Here is the output of our (unfortunately short) hack session. There
>>> are warnings fixed in 4 files. A patch is included in each. Mostly
>>> just generics and deprecation warnings.
>>>
>>> Regards,
>>> Michael Barker.
>>> Contributor/UserId: mikeb2701
From stuart.marks at oracle.com Thu Dec 1 18:46:04 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 01 Dec 2011 18:46:04 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <6000B656-E38B-478E-A467-508F9A1CC13B@oracle.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<6000B656-E38B-478E-A467-508F9A1CC13B@oracle.com>
Message-ID: <4ED83BEC.4090807@oracle.com>
I've filed bug 7117230 to cover this work. I've made John the responsible
engineer since he's doing the review. John, I hope that's OK.
I have a question about this change to ParseException.java:
+ at SuppressWarnings("serial") // Adding serial ID will break compatibility.
Suppress it.
Is it really the case that adding the serialVersionUID will break
compatibility? We've added this to other throwables, e.g. see
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/624cc18a6cf9
The value declared here is the same as the unmodified version of the class.
Unless there's something really weird going on with this class that I don't
see, adding a serialVersionUID should improve compatibility, not break it.
s'marks
On 12/1/11 5:17 PM, John Rose wrote:
> On Dec 1, 2011, at 4:49 PM, John Rose wrote:
>
>> On Dec 1, 2011, at 3:19 PM, Deepak Bhole wrote:
>>
>>> Hi All,
>>>
>>> Here are all the warning fixes for java.text.**:
>>>
>>> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.00/
>>>
>>> I have added suppressions where fixes would cause compatibility
>>> breakage, or where fixes would be too convoluted (e.g the ever so fun
>>> genericized array creation :)).
>>
>> Thanks for doing all this work! I have some review comments.
>> ...
>>
>> (About 50% through. More to come...)
>
> Here's the rest.
>
> I think the method divideUpDictionaryRange is too complex (181 LOC) to be covered by one @SuppressWarnings. Even adding 30 annotations in the body would be better, since then the other 151 LOC would remain protected.
>
> I do like the informative comment on @SuppressWarnings:
> + @SuppressWarnings("unchecked") // suppress unchecked warning for cloning stack
>
> Extra parens (only needed when there was a cast) can go away:
> + cachedBreakPositions[i + 1] = (currentBreakPositions.elementAt(i)).intValue();
> ++ cachedBreakPositions[i + 1] = currentBreakPositions.elementAt(i).intValue();
>
> This one has to be on the method level, of course. Good comment; suggest s/fallthrough/fallthrough in switch/.
> + @SuppressWarnings("fallthrough") // fallthrough is expected, suppress it
>
> Diamond operator, again:
> + ArrayList<AttributedCharacterIterator> iterators = new ArrayList<AttributedCharacterIterator>();
> ++ ArrayList<AttributedCharacterIterator> iterators = new ArrayList<>();
>
> and:
> + private static final Hashtable<Locale, String[]> cachedLocaleData = new Hashtable<Locale, String[]>(3);
> ++ private static final Hashtable<Locale, String[]> cachedLocaleData = new Hashtable<>(3);
> + private static final Map<String, Field> instanceMap = new HashMap<String, Field>(11);
> ++ private static final Map<String, Field> instanceMap = new HashMap<>(11);
> + entryTable = new Vector<EntryPair>(INITIALTABLESIZE);
> ++ entryTable = new Vector<>(INITIALTABLESIZE);
>
>
> This one has to be at class level; good comment:
> + at SuppressWarnings("serial") // Adding serial ID will break compatibility. Suppress it.
>
> There is a peculiar space in the "int []" type name; consider removing it:
> + Vector<int []> eTbl,
> ++ Vector<int[]> eTbl,
>
> + private Vector<int []> expandTable = null;
> ++ private Vector<int[]> expandTable = null;
> + expandTable = new Vector<int []>(INITIALTABLESIZE);
> ++ expandTable = new Vector<int[]>(INITIALTABLESIZE);
> + private Vector<int []> expandTable = null;
> (etc.)
>
> Majority usage in that package omits the space, and you delete the minority cases.
>
> Regarding majority usage see M2 in http://blogs.oracle.com/jrose/entry/on_coding_style .
>
> I'm done commenting.
>
> Thanks for taking this on!
>
> Best,
> -- John
>
> P.S. My recommendations about @SuppressWarnings are off the top of my head. See Josh Bloch's Effective Java for more and better of that sort of thing. (Hat tip to Stuart M. and Andrew Hughes.)
From stuart.marks at oracle.com Thu Dec 1 19:40:11 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 01 Dec 2011 19:40:11 -0800
Subject: Warnings Cleanup in java.util.<various>
In-Reply-To: <CALwNKeSBmnpPLr0hSWdDzCVYo7mjizi207Nj6ayVDKc1QaAdMw@mail.gmail.com>
References: <CALwNKeRhUTkBj3EeNmST=Acecnf1F7kifwwNbug5uW1U23Nh7A@mail.gmail.com>
<CALwNKeRYO7m278NfpTtXoSaLQjTJkAxDJG9O98_3QuQKjmMsdw@mail.gmail.com>
<CALwNKeSBmnpPLr0hSWdDzCVYo7mjizi207Nj6ayVDKc1QaAdMw@mail.gmail.com>
Message-ID: <4ED8489B.8090800@oracle.com>
Hi Mike,
Thanks for pulling together the London JUG on short notice to bring up folks on
building OpenJDK to the point of being able to generate patches! That's a great
accomplishment.
Sorry for the trouble with the attachments. As you notice, most everything
except text attachments is stripped (though I believe some of the OpenJDK lists
will pass zip attachments).
I've filed bug 7117249 to track these changes. David Holmes mentioned that he
thought the change in LogManager from Enumeration to Iterator might be out of
scope for warnings cleanup. He might be right. I saw some questions from
Martijn about other aspects of this code as well. I'll bring in somebody who's
more familiar with the logging area to look this over, and then we'll figure
out what to do.
Thanks again.
s'marks
On 12/1/11 4:11 PM, Michael Barker wrote:
> Trying once more with a .txt extension. If that fails I'll inline the patch.
>
> Mike.
>
> On Fri, Dec 2, 2011 at 12:06 AM, Michael Barker<mikeb01 at gmail.com> wrote:
>> Looks like the list software has stripped off the attachments from my
>> previous mail (my outbox shows them attached).
>>
>> Here's a second attempt.
>>
>> On Thu, Dec 1, 2011 at 11:58 PM, Michael Barker<mikeb01 at gmail.com> wrote:
>>> Hi,
>>>
>>> Here is the output of our (unfortunately short) hack session. There
>>> are warnings fixed in 4 files. A patch is included in each. Mostly
>>> just generics and deprecation warnings.
>>>
>>> Regards,
>>> Michael Barker.
>>> Contributor/UserId: mikeb2701
From stuart.marks at oracle.com Thu Dec 1 20:05:44 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 01 Dec 2011 20:05:44 -0800
Subject: quick Warnings Cleanup Day update
In-Reply-To: <4ED82972.5010305@oracle.com>
References: <20111202001420.0DAB8474F8@hg.openjdk.java.net>
<4ED828B4.4070805@oracle.com> <4ED82972.5010305@oracle.com>
Message-ID: <4ED84E98.1070905@oracle.com>
OK all,
It's the end of my day here in California. Here's a quick recap.
In addition to the four changesets that have been integrated, I see that ten
patches have been submitted and are in varying stages of review. Please check
out the wiki status page [1] to make sure that there's a row in the table with
a bugid, the code area, your name, and a link to a webrev or patch. If you're
working on something that's not listed here, please let us know (or update the
page if you have access).
I and others will be continuing to review these patches and get them integrated
over the new few days.
Thanks to all who have put effort into this.
s'marks
[1] http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
On 12/1/11 5:27 PM, Stuart Marks wrote:
> I forgot to mention... one of the four initial changesets was contributed by
> Sebastian Sickelmann (change notification below) which is the first warnings
> cleanup changeset contributed from outside of Oracle. Congratulations
> Sebastian, and thanks.
>
> s'marks
>
> On 12/1/11 5:24 PM, Stuart Marks wrote:
>> At this point four warnings cleanup changesets have been pushed into the TL
>> forest. These reduce the number of warnings from a little over 10,000 to less
>> than 9,500. Pretty good!
>>
>> There are a bunch of changesets that have been posted and are pending review. I
>> haven't gotten to those yet. I'm sure they knock off even more warnings.
>>
>> I've created a little table with the running tally of warnings vs changesets as
>> they're integrated into the TL forest. It's on the wiki here [1].
>>
>> s'marks
>>
>> [1]
>> http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
>>
>> -------- Original Message --------
>> Subject: hg: jdk8/tl/jdk: 7116890: additional warnings fixes for java.io
>> Date: Fri, 02 Dec 2011 00:14:10 +0000
>> From: stuart.marks at oracle.com
>> To: jdk8-changes at openjdk.java.net, compiler-dev at openjdk.java.net,
>> core-libs-dev at openjdk.java.net, serviceability-dev at openjdk.java.net,
>> security-dev at openjdk.java.net, net-dev at openjdk.java.net
>>
>> Changeset: 0e3f706741ca
>> Author: smarks
>> Date: 2011-12-01 16:14 -0800
>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e3f706741ca
>>
>> 7116890: additional warnings fixes for java.io
>> Reviewed-by: alanb, smarks
>> Contributed-by: Sebastian Sickelmann <sebastian.sickelmann at gmx.de>
>>
>> ! src/share/classes/java/io/ExpiringCache.java
>> ! src/share/classes/java/io/LineNumberInputStream.java
>> ! src/share/classes/java/io/LineNumberReader.java
>> ! src/share/classes/java/io/ObjectOutputStream.java
>> ! src/share/classes/java/io/RandomAccessFile.java
>>
From xiomara.jayasena at oracle.com Thu Dec 1 20:51:52 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Thu, 1 Dec 2011 20:51:52 -0800 (PST)
Subject: JDK8 Warnings Cleanup Day (WCD)
Message-ID: <53ab03dd-e51e-4a74-816d-b3b54954fbe4@default>
A huge thanks to all of you who participated!!
This was indeed a fun undertaking. I am sending this e-mail to delineate the working time frames of the JDK8 Warnings Cleanup Day. Of course, I know that work still continues in many areas, so please continue those efforts.
I believe we have most names in the wiki for the project [1] but if you are working on fixing warnings in the next couple of days then please send me your name (no need to send message to the entire alias :-) )
Thanks again!
-Xiomara
[1] http://wikis.sun.com/display/OpenJDK/JDK8+Warnings+Cleanup+Day
From john.r.rose at oracle.com Thu Dec 1 22:30:07 2011
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 1 Dec 2011 22:30:07 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <4ED83BEC.4090807@oracle.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<6000B656-E38B-478E-A467-508F9A1CC13B@oracle.com>
<4ED83BEC.4090807@oracle.com>
Message-ID: <61736A1A-AD8A-489E-AF3C-C74C4B82799E@oracle.com>
On Dec 1, 2011, at 6:46 PM, Stuart Marks wrote:
> I have a question about this change to ParseException.java:
>
> + at SuppressWarnings("serial") // Adding serial ID will break compatibility. Suppress it.
>
> Is it really the case that adding the serialVersionUID will break compatibility? We've added this to other throwables, e.g. see
>
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/624cc18a6cf9
>
> The value declared here is the same as the unmodified version of the class. Unless there's something really weird going on with this class that I don't see, adding a serialVersionUID should improve compatibility, not break it.
Oops, good catch, Stuart. This @SuppressWarnings does not look safe. -- John
From mikeb01 at gmail.com Thu Dec 1 22:37:24 2011
From: mikeb01 at gmail.com (Michael Barker)
Date: Fri, 2 Dec 2011 06:37:24 +0000
Subject: Warnings Cleanup in java.util.<various>
In-Reply-To: <4ED8489B.8090800@oracle.com>
References: <CALwNKeRhUTkBj3EeNmST=Acecnf1F7kifwwNbug5uW1U23Nh7A@mail.gmail.com>
<CALwNKeRYO7m278NfpTtXoSaLQjTJkAxDJG9O98_3QuQKjmMsdw@mail.gmail.com>
<CALwNKeSBmnpPLr0hSWdDzCVYo7mjizi207Nj6ayVDKc1QaAdMw@mail.gmail.com>
<4ED8489B.8090800@oracle.com>
Message-ID: <CALwNKeSkB_QGe==p8nZXoZ+L4mm=0rLcytNV-ChWpsvkwOF6Rw@mail.gmail.com>
Hi Stuart,
Thanks, we were happy with the results we got. About 6 or so of the
people there got the JDK build up and running and a few writing code
in about 2 hours. We are going to do some more of these evenings and
build a little momentum in the community.
I have attached a second patch with just a the wildcard to the
Enumeration instead of using an Iterator. We did have a discussion
over that one. Both options are available, I'll let whoever it doing
the merge decide.
Mike.
On Fri, Dec 2, 2011 at 3:40 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
> Hi Mike,
>
> Thanks for pulling together the London JUG on short notice to bring up folks
> on building OpenJDK to the point of being able to generate patches! That's a
> great accomplishment.
>
> Sorry for the trouble with the attachments. As you notice, most everything
> except text attachments is stripped (though I believe some of the OpenJDK
> lists will pass zip attachments).
>
> I've filed bug 7117249 to track these changes. David Holmes mentioned that
> he thought the change in LogManager from Enumeration to Iterator might be
> out of scope for warnings cleanup. He might be right. I saw some questions
> from Martijn about other aspects of this code as well. I'll bring in
> somebody who's more familiar with the logging area to look this over, and
> then we'll figure out what to do.
>
> Thanks again.
>
> s'marks
>
>
> On 12/1/11 4:11 PM, Michael Barker wrote:
>>
>> Trying once more with a .txt extension. ?If that fails I'll inline the
>> patch.
>>
>> Mike.
>>
>> On Fri, Dec 2, 2011 at 12:06 AM, Michael Barker<mikeb01 at gmail.com> ?wrote:
>>>
>>> Looks like the list software has stripped off the attachments from my
>>> previous mail (my outbox shows them attached).
>>>
>>> Here's a second attempt.
>>>
>>> On Thu, Dec 1, 2011 at 11:58 PM, Michael Barker<mikeb01 at gmail.com>
>>> ?wrote:
>>>>
>>>> Hi,
>>>>
>>>> Here is the output of our (unfortunately short) hack session. ?There
>>>> are warnings fixed in 4 files. ?A patch is included in each. ?Mostly
>>>> just generics and deprecation warnings.
>>>>
>>>> Regards,
>>>> Michael Barker.
>>>> Contributor/UserId: mikeb2701
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/logging/LogManager.java
--- a/src/share/classes/java/util/logging/LogManager.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/logging/LogManager.java Fri Dec 02 06:31:37 2011 +0000
@@ -179,10 +179,10 @@
cname = System.getProperty("java.util.logging.manager");
if (cname != null) {
try {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(cname);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(cname);
manager = (LogManager) clz.newInstance();
} catch (ClassNotFoundException ex) {
- Class clz = Thread.currentThread().getContextClassLoader().loadClass(cname);
+ Class<?> clz = Thread.currentThread().getContextClassLoader().loadClass(cname);
manager = (LogManager) clz.newInstance();
}
}
@@ -200,8 +200,8 @@
// Adding the global Logger. Doing so in the Logger.<clinit>
// would deadlock with the LogManager.<clinit>.
- Logger.global.setLogManager(manager);
- manager.addLogger(Logger.global);
+ Logger.getGlobal().setLogManager(manager);
+ manager.addLogger(Logger.getGlobal());
// We don't call readConfiguration() here, as we may be running
// very early in the JVM startup sequence. Instead readConfiguration
@@ -415,7 +415,7 @@
for (int i = 0; i < names.length; i++) {
String word = names[i];
try {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(word);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(word);
Handler hdl = (Handler) clz.newInstance();
try {
// Check if there is a property defining the
@@ -782,11 +782,11 @@
// responsibility to initialize the logging configuration, by
// calling readConfiguration(InputStream) with a suitable stream.
try {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(cname);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(cname);
clz.newInstance();
return;
} catch (ClassNotFoundException ex) {
- Class clz = Thread.currentThread().getContextClassLoader().loadClass(cname);
+ Class<?> clz = Thread.currentThread().getContextClassLoader().loadClass(cname);
clz.newInstance();
return;
}
@@ -837,9 +837,9 @@
// the global handlers, if they haven't been initialized yet.
initializedGlobalHandlers = true;
}
- Enumeration enum_ = getLoggerNames();
+ Enumeration<String> enum_ = getLoggerNames();
while (enum_.hasMoreElements()) {
- String name = (String)enum_.nextElement();
+ String name = enum_.nextElement();
resetLogger(name);
}
}
@@ -926,7 +926,7 @@
for (int i = 0; i < names.length; i++) {
String word = names[i];
try {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(word);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(word);
clz.newInstance();
} catch (Exception ex) {
System.err.println("Can't load config class \"" + word + "\"");
@@ -1024,7 +1024,7 @@
String val = getProperty(name);
try {
if (val != null) {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(val);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(val);
return (Filter) clz.newInstance();
}
} catch (Exception ex) {
@@ -1045,7 +1045,7 @@
String val = getProperty(name);
try {
if (val != null) {
- Class clz = ClassLoader.getSystemClassLoader().loadClass(val);
+ Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(val);
return (Formatter) clz.newInstance();
}
} catch (Exception ex) {
@@ -1163,7 +1163,7 @@
// Private method to be called when the configuration has
// changed to apply any level settings to any pre-existing loggers.
synchronized private void setLevelsOnExistingLoggers() {
- Enumeration enum_ = props.propertyNames();
+ Enumeration<?> enum_ = props.propertyNames();
while (enum_.hasMoreElements()) {
String key = (String)enum_.nextElement();
if (!key.endsWith(".level")) {
From stuart.marks at oracle.com Fri Dec 2 00:06:54 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 02 Dec 2011 00:06:54 -0800
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <4ED82CD8.5080404@oracle.com>
References: <391b7649-4f85-47c2-805c-03aecc0ce5ac@default>
<4ED5F821.3040906@oracle.com> <4ED82743.6030209@oracle.com>
<4ED82CD8.5080404@oracle.com>
Message-ID: <4ED8871E.1010309@oracle.com>
On 12/1/11 5:41 PM, Weijun Wang wrote:
>> (Incidentally, this is the third time I've reviewed code today that
>> looks exactly like this. The other cases are in java.io.FilePermission
>> and java.util.PropertyPermission. They each have the /*FALLTHROUGH*/
>> into a set of cases that do nothing but break; and they have similar
>> ("ackbarfaccept") comments. It would be nice if these chunks of code
>> could be unified, but they differ in a number of fiddly details.)
>>
>> (The string "ackbarfaccept" occurs in the following files:
>> 1. java/io/FilePermission.java
>> 2. java/net/SocketPermission.java
>> 3. java/util/PropertyPermission.java
>> 4. javax/management/MBeanPermission.java
>> 5. javax/security/auth/kerberos/ServicePermission.java
>> Hmmm.)
>
> This is funny. We might do something later.
Yeah, this is a good thing to look at later. Looks like somebody long ago did
some cut-and-paste programming. Brandon and Sebastian were working on
FilePermission and PropertyPermission and might be considering how to
merge/unify or at least coordinate the code. Now it seems that there are a few
more instances to look at.
> BTW, I've included some other sun.misc files and created a
> webrev at
>
> http://cr.openjdk.java.net/~weijun/7116857/webrev.00/
Wow, lots more code. Comments below.
> Some classes inside sun.misc are not touched, mainly SoftCache/Ref/Cache. I
> tried them but not very successful.
Sure, no problem doing just a subset of sun.misc.
Comments on webrev:
ClassLoaderUtil.java --
The generic types for loaders, urls, and lmap are kind of strange. (This code
is kind of strange to begin with.) The urls variable is declared as Stack<URL>
and you had to import java.net.URL for this; but the URL type isn't actually
used anywhere. The lmap var is HashMap<String,?> but probably only because
String is already implicitly imported, and it didn't make sense to import
Loader (the type of the map's values). I guess since the values in any of these
containers aren't actually used, maybe it makes sense to make them ALL wildcard
types, i.e.
ArrayList<?> loaders = ucp.loaders;
Stack<?> urls = ucp.urls;
HashMap<?,?> lmap = ucp.lmap;
Makes a bit more sense, in a curious way. (Assuming it works, of course.) Up to
you whether you want to make it this way.
LRUCache.java --
You can reduce the scope of @SuppressWarnings by doing something like this:
@SuppressWarnings("unchecked")
V[] temp = (V[])new Object[size];
oa = temp;
Queue.java --
Wow, another queue implementation. The generic conversion looks right. I'm just
marveling at all the weird stuff off in the corner of sun.misc. Nothing to
change here.
RequestProcessor.java --
Now that the Queue instance contained here has been generified, the code here
can be assured that its contents are all subtypes of Request. There's logic in
here that checks items for instanceof Request, ignores that aren't, and casts
the remainder into Request. Just an observation that all this stuff is
unnecessary. However, it's probably not worth changing this dusty old code at
this point, if ever (and certainly not part of warnings fixes).
URLClassPath.java --
Now that jarFilesList is LinkedList<String> instead of a raw LinkedList, it
shouldn't be necessary to do any casts when fetching the contents. However, the
existing code copies the contents to an Object[] and then downcasts the
individual array elements to String. Ugh. This can be avoided by changing line
851ff to
int size = jarFilesList.size();
String[] jarFiles = jarFilesList.toArray(new String[size]);
**
If you have time today I'd appreciate it if you could build/test and push this
change yourself. I'm backlogged reviewing and integrating changes from external
folks.
thanks!
s'marks
From artem.ananiev at oracle.com Fri Dec 2 01:26:12 2011
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Fri, 02 Dec 2011 13:26:12 +0400
Subject: Review Request for 7116993 (warning cleanup java.applet)
In-Reply-To: <4ED7EE3E.6020109@oracle.com>
References: <4ED7E98F.3040200@oracle.com> <4ED7EE3E.6020109@oracle.com>
Message-ID: <4ED899B4.7000207@oracle.com>
I haven't seen anyone else working on java.applet. Your webrev looks fine.
Thanks,
Artem
On 12/2/2011 1:14 AM, Brandon Passanisi wrote:
> I'll withdraw this review request as I was notified by Xiomara that
> someone else has been working on java.applet. I had sent an e-mail to
> the alias yesterday about taking on java.applet though. Luckily, there
> aren't many warnings in java.applet.
>
> On 12/1/2011 12:54 PM, Brandon Passanisi wrote:
>> I have a webrev pertaining to the warning cleanup changes for
>> java.applet ready for review. Here's the info:
>>
>> Bug: 7116993
>> Webrev:
>> http://cr.openjdk.java.net/~dmocek/bpassanisi/7116993/webrev.00/
>> <http://cr.openjdk.java.net/%7Edmocek/bpassanisi/7116993/webrev.00/>
>>
>> Thanks.
>
From weijun.wang at oracle.com Fri Dec 2 02:18:42 2011
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 02 Dec 2011 18:18:42 +0800
Subject: JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
In-Reply-To: <4ED8871E.1010309@oracle.com>
References: <391b7649-4f85-47c2-805c-03aecc0ce5ac@default>
<4ED5F821.3040906@oracle.com> <4ED82743.6030209@oracle.com>
<4ED82CD8.5080404@oracle.com> <4ED8871E.1010309@oracle.com>
Message-ID: <4ED8A602.4040101@oracle.com>
>
> **
All suggestions accepted. Webrev updated. JPRT build and default testset
pass on all default platforms.
I'll push it tomorrow morning (your Friday afternoon) if no one has an
objection.
Thanks
Max
>
> If you have time today I'd appreciate it if you could build/test and
> push this change yourself. I'm backlogged reviewing and integrating
> changes from external folks.
>
> thanks!
>
> s'marks
From schlosna at gmail.com Fri Dec 2 03:06:00 2011
From: schlosna at gmail.com (David Schlosnagle)
Date: Fri, 2 Dec 2011 06:06:00 -0500
Subject: Request for Review: Warnings cleanup in java.lang.*, java.util.**
Message-ID: <CAGVnyzRNvKDpSN-TuKRDg+ckKEZcQj-EfLUnt1Ayfse0PeDk6g@mail.gmail.com>
I didn't have a chance to sign-up or submit during the official
warnings cleanup day, but I'm hoping that you'll still accept patches.
I do not have a bug number for this change.
The webrev [1] below should resolve 208 warnings in the java.lang.*
and java.util.** packages. I tried to stick to fixing warnings, but
OCD kicked in while editing in NetBeans, so there are a few additional
IDE warnings fixed as well for the modified files. For example,?adding
@Override on the relevant methods, removals of dead stores, conversion
to Strings in switch, StringBuffer -> StringBuilder where localized (I
realize lock elision in HotSpot and JRockit should make them
practically equivalent, but NetBeans still complains and I assume
there is still some unnecessary synchronization overhead).
ConditionalSpecialCasing.java also has some slight refactoring to
utilize the updated parameterized types.
Additionally, there was one change to
java.util.regex.Pattern#subFlag() that I'd like someone to review more
carefully as it was previously falling through the last case, but I
believe the last case should have had a break; to properly handle
other flags.
*** 3006,3015 ****
--- 3014,3024 ----
case 'x':
flags &= ~COMMENTS;
break;
case 'U':
flags &= ~(UNICODE_CHARACTER_CLASS | UNICODE_CASE);
+ break;
default:
return;
}
If you want any of the additional cleanup removed from the patch or
other changes, please let me know.
[1]:?http://dl.dropbox.com/u/23832908/openjdk/2011-12-01/index.html
Files modified:
? ? java/lang/Boolean.java
? ? java/lang/Byte.java
? ? java/lang/Character.java
? ? java/lang/Class.java
? ? java/lang/ConditionalSpecialCasing.java
? ? java/lang/Double.java
? ? java/lang/Float.java
? ? java/lang/Integer.java
? ? java/lang/Long.java
? ? java/lang/Short.java
? ? java/lang/System.java
? ? java/lang/ThreadLocal.java
? ? java/lang/Void.java
? ? java/util/IllegalFormatConversionException.java
? ? java/util/Locale.java
? ? java/util/regex/Matcher.java
? ? java/util/regex/Pattern.java
? ? java/util/regex/PatternSyntaxException.java
? ? java/util/regex/UnicodeProp.java
Thanks,
Dave
From Alan.Bateman at oracle.com Fri Dec 2 04:18:41 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 02 Dec 2011 12:18:41 +0000
Subject: Request for Review: Warnings cleanup in java.lang.*, java.util.**
In-Reply-To: <CAGVnyzRNvKDpSN-TuKRDg+ckKEZcQj-EfLUnt1Ayfse0PeDk6g@mail.gmail.com>
References: <CAGVnyzRNvKDpSN-TuKRDg+ckKEZcQj-EfLUnt1Ayfse0PeDk6g@mail.gmail.com>
Message-ID: <4ED8C221.7070603@oracle.com>
cc'ing core-libs-dev as that is the place to discuss these changes. I
see on the sign-up sheet [1] that omajid has signed up for java.lang,
maybe you are working together? I'll leave it to Stuart to say whether
he wants to refactor/other changes separated from the warnings changes.
One thing I'm curious about is
@SuppressWarnings("BooleanConstructorCall") as it suggests that some
other compiler, or maybe an extension in the NetBeans javac?
-Alan
[1]
http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
On 02/12/2011 11:06, David Schlosnagle wrote:
> I didn't have a chance to sign-up or submit during the official
> warnings cleanup day, but I'm hoping that you'll still accept patches.
> I do not have a bug number for this change.
>
> The webrev [1] below should resolve 208 warnings in the java.lang.*
> and java.util.** packages. I tried to stick to fixing warnings, but
> OCD kicked in while editing in NetBeans, so there are a few additional
> IDE warnings fixed as well for the modified files. For example, adding
> @Override on the relevant methods, removals of dead stores, conversion
> to Strings in switch, StringBuffer -> StringBuilder where localized (I
> realize lock elision in HotSpot and JRockit should make them
> practically equivalent, but NetBeans still complains and I assume
> there is still some unnecessary synchronization overhead).
> ConditionalSpecialCasing.java also has some slight refactoring to
> utilize the updated parameterized types.
>
> Additionally, there was one change to
> java.util.regex.Pattern#subFlag() that I'd like someone to review more
> carefully as it was previously falling through the last case, but I
> believe the last case should have had a break; to properly handle
> other flags.
>
> *** 3006,3015 ****
> --- 3014,3024 ----
> case 'x':
> flags&= ~COMMENTS;
> break;
> case 'U':
> flags&= ~(UNICODE_CHARACTER_CLASS | UNICODE_CASE);
> + break;
> default:
> return;
> }
>
> If you want any of the additional cleanup removed from the patch or
> other changes, please let me know.
>
> [1]: http://dl.dropbox.com/u/23832908/openjdk/2011-12-01/index.html
>
> Files modified:
> java/lang/Boolean.java
> java/lang/Byte.java
> java/lang/Character.java
> java/lang/Class.java
> java/lang/ConditionalSpecialCasing.java
> java/lang/Double.java
> java/lang/Float.java
> java/lang/Integer.java
> java/lang/Long.java
> java/lang/Short.java
> java/lang/System.java
> java/lang/ThreadLocal.java
> java/lang/Void.java
> java/util/IllegalFormatConversionException.java
> java/util/Locale.java
> java/util/regex/Matcher.java
> java/util/regex/Pattern.java
> java/util/regex/PatternSyntaxException.java
> java/util/regex/UnicodeProp.java
>
> Thanks,
> Dave
From martijnverburg at gmail.com Fri Dec 2 04:22:10 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 2 Dec 2011 12:22:10 +0000
Subject: Request for Review: Warnings cleanup in java.lang.*, java.util.**
In-Reply-To: <4ED8C221.7070603@oracle.com>
References: <CAGVnyzRNvKDpSN-TuKRDg+ckKEZcQj-EfLUnt1Ayfse0PeDk6g@mail.gmail.com>
<4ED8C221.7070603@oracle.com>
Message-ID: <CAP7YuARfkDAzNgOLyUjoqKmGBacMr1W9VJVtHkyQhFWNQmS8Hg@mail.gmail.com>
FYI - The London JUG did have java.util.regex listed, but we didn't
have time to produce a patch for that area, so no clash there -
Cheers, M
On 2 December 2011 12:18, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> cc'ing core-libs-dev as that is the place to discuss these changes. I see on
> the sign-up sheet [1] that omajid has signed up for java.lang, maybe you are
> working together? I'll leave it to Stuart to say whether he wants to
> refactor/other changes separated from the warnings changes.
>
> One thing I'm curious about is @SuppressWarnings("BooleanConstructorCall")
> as it suggests that some other compiler, or maybe an extension in the
> NetBeans javac?
>
> -Alan
>
> [1]
> http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
>
>
> On 02/12/2011 11:06, David Schlosnagle wrote:
>>
>> I didn't have a chance to sign-up or submit during the official
>> warnings cleanup day, but I'm hoping that you'll still accept patches.
>> I do not have a bug number for this change.
>>
>> The webrev [1] below should resolve 208 warnings in the java.lang.*
>> and java.util.** packages. I tried to stick to fixing warnings, but
>> OCD kicked in while editing in NetBeans, so there are a few additional
>> IDE warnings fixed as well for the modified files. For example, adding
>> @Override on the relevant methods, removals of dead stores, conversion
>> to Strings in switch, StringBuffer -> ?StringBuilder where localized (I
>> realize lock elision in HotSpot and JRockit should make them
>> practically equivalent, but NetBeans still complains and I assume
>> there is still some unnecessary synchronization overhead).
>> ConditionalSpecialCasing.java also has some slight refactoring to
>> utilize the updated parameterized types.
>>
>> Additionally, there was one change to
>> java.util.regex.Pattern#subFlag() that I'd like someone to review more
>> carefully as it was previously falling through the last case, but I
>> believe the last case should have had a break; to properly handle
>> other flags.
>>
>> *** 3006,3015 ****
>> --- 3014,3024 ----
>> ? ? ? ? ? ? ? case 'x':
>> ? ? ? ? ? ? ? ? ? flags&= ~COMMENTS;
>> ? ? ? ? ? ? ? ? ? break;
>> ? ? ? ? ? ? ? case 'U':
>> ? ? ? ? ? ? ? ? ? flags&= ~(UNICODE_CHARACTER_CLASS | UNICODE_CASE);
>> + ? ? ? ? ? ? ? ? break;
>> ? ? ? ? ? ? ? default:
>> ? ? ? ? ? ? ? ? ? return;
>> ? ? ? ? ? ? ? }
>>
>> If you want any of the additional cleanup removed from the patch or
>> other changes, please let me know.
>>
>> [1]: http://dl.dropbox.com/u/23832908/openjdk/2011-12-01/index.html
>>
>> Files modified:
>> ? ? java/lang/Boolean.java
>> ? ? java/lang/Byte.java
>> ? ? java/lang/Character.java
>> ? ? java/lang/Class.java
>> ? ? java/lang/ConditionalSpecialCasing.java
>> ? ? java/lang/Double.java
>> ? ? java/lang/Float.java
>> ? ? java/lang/Integer.java
>> ? ? java/lang/Long.java
>> ? ? java/lang/Short.java
>> ? ? java/lang/System.java
>> ? ? java/lang/ThreadLocal.java
>> ? ? java/lang/Void.java
>> ? ? java/util/IllegalFormatConversionException.java
>> ? ? java/util/Locale.java
>> ? ? java/util/regex/Matcher.java
>> ? ? java/util/regex/Pattern.java
>> ? ? java/util/regex/PatternSyntaxException.java
>> ? ? java/util/regex/UnicodeProp.java
>>
>> Thanks,
>> Dave
>
>
From dalibor.topic at oracle.com Fri Dec 2 05:12:41 2011
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 02 Dec 2011 14:12:41 +0100
Subject: Chat room for JDK8 bug hunt on Dec 1
In-Reply-To: <CAP7YuAQzvogy6Ezme6KYVttftDp0YuQP3O9MneFNR7_c=FoAfQ@mail.gmail.com>
References: <CAP7YuATNwakTepTbeh7qjVrXtxQS2oijf1u5n1puAXs6S19vbw@mail.gmail.com>
<E46DD3B8-A863-48C9-BECF-EFA6DB1DA0DC@gmail.com>
<CAP7YuAQzvogy6Ezme6KYVttftDp0YuQP3O9MneFNR7_c=FoAfQ@mail.gmail.com>
Message-ID: <4ED8CEC9.1080803@oracle.com>
On 11/30/11 10:56 PM, Martijn Verburg wrote:
> Hi all,
>
> I simply wasn't aware of #openjdk - what IRC server does that run on?
irc.oftc.net - http://openjdk.java.net/irc/ ;)
cheers,
dalibor topic
--
Oracle <http://www.oracle.com>
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738 <tel:+494023646738> | Mobile: +491772664192 <tel:+491772664192>
Oracle Java Platform Group
ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz
Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
From omajid at redhat.com Fri Dec 2 09:00:29 2011
From: omajid at redhat.com (Omair Majid)
Date: Fri, 02 Dec 2011 12:00:29 -0500
Subject: Request for Review: Warnings cleanup in java.lang.*, java.util.**
In-Reply-To: <4ED8C221.7070603@oracle.com>
References: <CAGVnyzRNvKDpSN-TuKRDg+ckKEZcQj-EfLUnt1Ayfse0PeDk6g@mail.gmail.com>
<4ED8C221.7070603@oracle.com>
Message-ID: <4ED9042D.3000307@redhat.com>
Hi,
On 12/02/2011 07:18 AM, Alan Bateman wrote:
>
> cc'ing core-libs-dev as that is the place to discuss these changes. I
> see on the sign-up sheet [1] that omajid has signed up for java.lang,
> maybe you are working together?
Unfortunately, David and I were not working together :(
Anyway, here is my webrev for java.lang.*
http://cr.openjdk.java.net/~omajid/webrevs/warnings-day-2011/01/
Sorry about the delay, building and testing this took longer than I had
expected it to. Also, this patch only addresses the warnings pointed out
by javac.
The classes java.lang.ThreadLocal and java.lang.ClassValue are not
included in the webrev. The fixes for ThreadLocal were basically
sprinkling @SuppressWarnings("unchecked") throughout and the fixes for
ClassValue looked slightly more complex when I tried to reduce the use
of rawtypes. I will post a separate webrev for those later.
Cheers,
Omair
From dbhole at redhat.com Fri Dec 2 10:47:26 2011
From: dbhole at redhat.com (Deepak Bhole)
Date: Fri, 2 Dec 2011 13:47:26 -0500
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
Message-ID: <20111202184726.GX2461@redhat.com>
* John Rose <john.r.rose at oracle.com> [2011-12-01 19:49]:
> On Dec 1, 2011, at 3:19 PM, Deepak Bhole wrote:
>
> > Hi All,
> >
> > Here are all the warning fixes for java.text.**:
> >
> > http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.00/
> >
> > I have added suppressions where fixes would cause compatibility
> > breakage, or where fixes would be too convoluted (e.g the ever so fun
> > genericized array creation :)).
>
> Thanks for doing all this work! I have some review comments.
>
> Bottom line: In some few cases, I think the the @SuppressWarnings annotations can be refined. Also, I am worried that there are one or two API signature changes or behavior changes.
>
> Details:
>
> On chunks like this:
> - HashSet keys = new HashSet();
> + HashSet<Attribute> keys = new HashSet<Attribute>();
> consider using new HashSet<>().
>
> See also occurrences of new Vector<Attribute>, new HashSet<Map.Entry<Attribute, Object>>, SoftReference<BreakIteratorCache>, etc.
>
Ah, I wasn't sure if I should have used 7-specific features so I stayed
away from them (when bootstrapping when ecj, we found diamond to be
problematic as older ecj versions cannot understand it). I will change
these then.
> (Netbeans can find opportunities for diamond operators, BTW.)
>
> The new parameters <K extends Attribute, V> are clearly more correct, but they look like an API change on a public method or constructor. If so, I think you'll have to find a different approach. (But I'm not an API change and generics expert.)
>
Do you mean the changes in the AttributedString constructor? I just
added names for the bounded and unbound wildcards so that they could be
used in the body (without it, the compiler was throwing errors).
I am not expert on these either -- I didn't know adding names could
change signature in an incompatible way.
I just wrote a small test case to try this out and everything seems to
work fine. Adding named parameters does not appear to break
compatibility in my test case.
> A trivial refactoring to use a private parameterized method might work nicely, but we're not doing refactorings today.
>
Yeah, I wanted to stay away from anything that added/removed any code :)
> For createRunAttributeDataVectors, ensureRunBreak, etc. consider pushing the @SuppressWarnings down onto the individual declarations. It is best to put @SuppressWarnings on the smallest program unit possible, and a local variable declaration is often the right spot. I see that createRunAttributeDataVectors could be viewed as simple enough to mark as a whole, but ensureRunBreak is probably too complex to mark as a whole.
>
Doh! Good point.
For DictionaryBasedBreakIterator.divideUpDictionaryRange, I cannot add
it above the
"bestBreakPositions = (Stack<Integer>)(currentBreakPositions.clone());" line
without refactoring. I done done a very minor refactor (use copy
constructor instead of clone) -- please let me know if it is
satisfactory.
As for others, I've narrowed it in the new webrev. Narrowing also
exposed a few more places I had missed in ensureRunBreak. Fixed now.
> In the same way, consider pushing the annotation into the body of class AttributeEntry, even though that class is very simple.
>
That one is for the declaration itself -- the warning is about the Map
supertype not being parameterized.
> For generic array creation, I suggest that you get rid of the "rawtypes" warning on the array element type by adding <?>, before suppressing the "unchecked" warning. Basically, when you find yourself writing new Foo<Bar>[len], change it to new Foo<?>[len]. Then, if you still get an unchecked warning, add SuppressWarnings.
>
> - Vector newRunAttributes[] = new Vector[newArraySize];
> - Vector newRunAttributeValues[] = new Vector[newArraySize];
> + @SuppressWarnings("unchecked") // generic array creation
> + Vector<Attribute> newRunAttributes[] = new Vector<?>[newArraySize];
> + @SuppressWarnings("unchecked") // generic array creation
> + Vector<Object> newRunAttributeValues[] = new Vector<?>[newArraySize];
>
I tried that yesterday, but the compiler threw errors:
../../../src/share/classes/java/text/AttributedString.java:420: error: incompatible types
Vector<Attribute> newRunAttributes[] = new Vector<?>[ARRAY_SIZE_INCREMENT];
^
required: Vector<Attribute>[]
found: Vector<?>[]
> It is probably a good idea to put a comment on most @SuppressWarnings annotations.
>
> Similarly:
>
> - private static final SoftReference[] iterCache = new SoftReference[4];
> +
> + @SuppressWarnings({"unchecked","rawtypes"})
> + private static final SoftReference<BreakIteratorCache>[] iterCache = new SoftReference[4];
> ++ @SuppressWarnings("unchecked")
> ++ private static final SoftReference<BreakIteratorCache>[] iterCache = new SoftReference<?>[4];
>
Similar error as above.
> There is an apparent behavior change in CollationElementIterator.setOffset, in this chunk:
> - int c = text.setIndex(newOffset);
> + text.setIndexOnly(newOffset);
> + int c = text.current();
>
setIndex is deprecated, so I looked into what the method did and did it
at the call site. Sorry, I should have specifically mentioned this
re-factor in the original email :(
I am fine with just suppressing deprecation warning there. I have done
so in the new copy by adding the annotation to the method.
> (About 50% through. More to come...)
>
(from the second email):
> Here's the rest.
>
> I think the method divideUpDictionaryRange is too complex (181 LOC) to be covered by one @SuppressWarnings. Even adding 30 annotations in the body would be better, since then the other 151 LOC would remain protected.
>
> I do like the informative comment on @SuppressWarnings:
> + @SuppressWarnings("unchecked") // suppress unchecked warning for cloning stack
>
Fixed with a minor re-factor as mentioned above.
> Extra parens (only needed when there was a cast) can go away:
> + cachedBreakPositions[i + 1] = (currentBreakPositions.elementAt(i)).intValue();
> ++ cachedBreakPositions[i + 1] = currentBreakPositions.elementAt(i).intValue();
>
Oops. Fixed in all locations (there were 3 others).
> This one has to be on the method level, of course. Good comment; suggest s/fallthrough/fallthrough in switch/.
> + @SuppressWarnings("fallthrough") // fallthrough is expected, suppress it
>
Done!
> Diamond operator, again:
> + ArrayList<AttributedCharacterIterator> iterators = new ArrayList<AttributedCharacterIterator>();
> ++ ArrayList<AttributedCharacterIterator> iterators = new ArrayList<>();
>
> and:
> + private static final Hashtable<Locale, String[]> cachedLocaleData = new Hashtable<Locale, String[]>(3);
> ++ private static final Hashtable<Locale, String[]> cachedLocaleData = new Hashtable<>(3);
> + private static final Map<String, Field> instanceMap = new HashMap<String, Field>(11);
> ++ private static final Map<String, Field> instanceMap = new HashMap<>(11);
> + entryTable = new Vector<EntryPair>(INITIALTABLESIZE);
> ++ entryTable = new Vector<>(INITIALTABLESIZE);
>
Fixed all updates in the patch to use diamond.
>
> This one has to be at class level; good comment:
> + at SuppressWarnings("serial") // Adding serial ID will break compatibility. Suppress it.
>
I saw Stuart's comments on this. Didn't know that there was a way to find
existing serialid (I thought Eclipse just generated a random one)! I have added
the class default id.
> There is a peculiar space in the "int []" type name; consider removing it:
> + Vector<int []> eTbl,
> ++ Vector<int[]> eTbl,
>
> + private Vector<int []> expandTable = null;
> ++ private Vector<int[]> expandTable = null;
> + expandTable = new Vector<int []>(INITIALTABLESIZE);
> ++ expandTable = new Vector<int[]>(INITIALTABLESIZE);
> + private Vector<int []> expandTable = null;
Ah, I copied what was there before in RBTableBuilder:
int[] valueList = (int [])expandTable.elementAt(i);
Fixed everywhere.
New webrev:
http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.01/
For convenience, I've also uploaded a diff between previous webrev and
new one to make it clear as to what changed:
http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.01/rev-00-01.patch
Thanks for the quick and detailed review!
Cheers,
Deepak
From naoto.sato at oracle.com Fri Dec 2 10:56:17 2011
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 02 Dec 2011 10:56:17 -0800
Subject: Review request for IMF classes and Locale related classes
Message-ID: <4ED91F51.2020502@oracle.com>
Hello,
Could you please review these two changesets for the WCD? One is for
classes that belongs to input method framework:
http://cr.openjdk.java.net/~naoto/7117465/webrev.00/
and the other is for (some of the) i18n related *.util.* classes:
http://cr.openjdk.java.net/~naoto/7117469/webrev.00/
Thanks!
Naoto
From forax at univ-mlv.fr Fri Dec 2 11:20:45 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 02 Dec 2011 20:20:45 +0100
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <20111202184726.GX2461@redhat.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<20111202184726.GX2461@redhat.com>
Message-ID: <4ED9250D.7000205@univ-mlv.fr>
Hi Deepak,
On 12/02/2011 07:47 PM, Deepak Bhole wrote:
> * John Rose<john.r.rose at oracle.com> [2011-12-01 19:49]:
>> On Dec 1, 2011, at 3:19 PM, Deepak Bhole wrote:
>>
>>> Hi All,
>>>
>>> Here are all the warning fixes for java.text.**:
>>>
>>> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.00/
>>>
>>> I have added suppressions where fixes would cause compatibility
>>> breakage, or where fixes would be too convoluted (e.g the ever so fun
>>> genericized array creation :)).
>> Thanks for doing all this work! I have some review comments.
>>
>> Bottom line: In some few cases, I think the the @SuppressWarnings annotations can be refined. Also, I am worried that there are one or two API signature changes or behavior changes.
>>
>> Details:
>>
>> On chunks like this:
>> - HashSet keys = new HashSet();
>> + HashSet<Attribute> keys = new HashSet<Attribute>();
>> consider using new HashSet<>().
>>
>> See also occurrences of new Vector<Attribute>, new HashSet<Map.Entry<Attribute, Object>>, SoftReference<BreakIteratorCache>, etc.
>>
> Ah, I wasn't sure if I should have used 7-specific features so I stayed
> away from them (when bootstrapping when ecj, we found diamond to be
> problematic as older ecj versions cannot understand it). I will change
> these then.
You can use them everywhere but in langtools because
the compiler need to bootstrap itself.
>
>> (Netbeans can find opportunities for diamond operators, BTW.)
>>
>> The new parameters<K extends Attribute, V> are clearly more correct, but they look like an API change on a public method or constructor. If so, I think you'll have to find a different approach. (But I'm not an API change and generics expert.)
>>
> Do you mean the changes in the AttributedString constructor? I just
> added names for the bounded and unbound wildcards so that they could be
> used in the body (without it, the compiler was throwing errors).
>
> I am not expert on these either -- I didn't know adding names could
> change signature in an incompatible way.
>
> I just wrote a small test case to try this out and everything seems to
> work fine. Adding named parameters does not appear to break
> compatibility in my test case.
>
>> A trivial refactoring to use a private parameterized method might work nicely, but we're not doing refactorings today.
>>
> Yeah, I wanted to stay away from anything that added/removed any code :)
>
>> For createRunAttributeDataVectors, ensureRunBreak, etc. consider pushing the @SuppressWarnings down onto the individual declarations. It is best to put @SuppressWarnings on the smallest program unit possible, and a local variable declaration is often the right spot. I see that createRunAttributeDataVectors could be viewed as simple enough to mark as a whole, but ensureRunBreak is probably too complex to mark as a whole.
>>
> Doh! Good point.
>
> For DictionaryBasedBreakIterator.divideUpDictionaryRange, I cannot add
> it above the
> "bestBreakPositions = (Stack<Integer>)(currentBreakPositions.clone());" line
> without refactoring. I done done a very minor refactor (use copy
> constructor instead of clone) -- please let me know if it is
> satisfactory.
It seems you still use clone,
you can't replace a call to clone with a call to a copy constructor because
if Stack is subclassed, clone will work but not the copy constructor.
>
> As for others, I've narrowed it in the new webrev. Narrowing also
> exposed a few more places I had missed in ensureRunBreak. Fixed now.
>
>> In the same way, consider pushing the annotation into the body of class AttributeEntry, even though that class is very simple.
>>
> That one is for the declaration itself -- the warning is about the Map
> supertype not being parameterized.
>
>> For generic array creation, I suggest that you get rid of the "rawtypes" warning on the array element type by adding<?>, before suppressing the "unchecked" warning. Basically, when you find yourself writing new Foo<Bar>[len], change it to new Foo<?>[len]. Then, if you still get an unchecked warning, add SuppressWarnings.
>>
>> - Vector newRunAttributes[] = new Vector[newArraySize];
>> - Vector newRunAttributeValues[] = new Vector[newArraySize];
>> + @SuppressWarnings("unchecked") // generic array creation
>> + Vector<Attribute> newRunAttributes[] = new Vector<?>[newArraySize];
>> + @SuppressWarnings("unchecked") // generic array creation
>> + Vector<Object> newRunAttributeValues[] = new Vector<?>[newArraySize];
>>
> I tried that yesterday, but the compiler threw errors:
>
> ../../../src/share/classes/java/text/AttributedString.java:420: error: incompatible types
> Vector<Attribute> newRunAttributes[] = new Vector<?>[ARRAY_SIZE_INCREMENT];
> ^
> required: Vector<Attribute>[]
> found: Vector<?>[]
Yes, you need to add a cast,
Vector<Attribute>[] newRunAttributes = (Vector<Attribute>[])new Vector<?>[ARRAY_SIZE_INCREMENT];
but if Java is reified in 1.9 as state the current plan, we will be in
trouble.
>
>> It is probably a good idea to put a comment on most @SuppressWarnings annotations.
>>
>> Similarly:
>>
>> - private static final SoftReference[] iterCache = new SoftReference[4];
>> +
>> + @SuppressWarnings({"unchecked","rawtypes"})
>> + private static final SoftReference<BreakIteratorCache>[] iterCache = new SoftReference[4];
>> ++ @SuppressWarnings("unchecked")
>> ++ private static final SoftReference<BreakIteratorCache>[] iterCache = new SoftReference<?>[4];
>>
> Similar error as above.
>
>> There is an apparent behavior change in CollationElementIterator.setOffset, in this chunk:
>> - int c = text.setIndex(newOffset);
>> + text.setIndexOnly(newOffset);
>> + int c = text.current();
>>
> setIndex is deprecated, so I looked into what the method did and did it
> at the call site. Sorry, I should have specifically mentioned this
> re-factor in the original email :(
>
> I am fine with just suppressing deprecation warning there. I have done
> so in the new copy by adding the annotation to the method.
>
>> (About 50% through. More to come...)
>>
> (from the second email):
>
>> Here's the rest.
>>
>> I think the method divideUpDictionaryRange is too complex (181 LOC) to be covered by one @SuppressWarnings. Even adding 30 annotations in the body would be better, since then the other 151 LOC would remain protected.
>>
>> I do like the informative comment on @SuppressWarnings:
>> + @SuppressWarnings("unchecked") // suppress unchecked warning for cloning stack
>>
> Fixed with a minor re-factor as mentioned above.
>
>> Extra parens (only needed when there was a cast) can go away:
>> + cachedBreakPositions[i + 1] = (currentBreakPositions.elementAt(i)).intValue();
>> ++ cachedBreakPositions[i + 1] = currentBreakPositions.elementAt(i).intValue();
>>
> Oops. Fixed in all locations (there were 3 others).
>
>> This one has to be on the method level, of course. Good comment; suggest s/fallthrough/fallthrough in switch/.
>> + @SuppressWarnings("fallthrough") // fallthrough is expected, suppress it
>>
> Done!
>
>> Diamond operator, again:
>> + ArrayList<AttributedCharacterIterator> iterators = new ArrayList<AttributedCharacterIterator>();
>> ++ ArrayList<AttributedCharacterIterator> iterators = new ArrayList<>();
>>
>> and:
>> + private static final Hashtable<Locale, String[]> cachedLocaleData = new Hashtable<Locale, String[]>(3);
>> ++ private static final Hashtable<Locale, String[]> cachedLocaleData = new Hashtable<>(3);
>> + private static final Map<String, Field> instanceMap = new HashMap<String, Field>(11);
>> ++ private static final Map<String, Field> instanceMap = new HashMap<>(11);
>> + entryTable = new Vector<EntryPair>(INITIALTABLESIZE);
>> ++ entryTable = new Vector<>(INITIALTABLESIZE);
>>
> Fixed all updates in the patch to use diamond.
>
>> This one has to be at class level; good comment:
>> + at SuppressWarnings("serial") // Adding serial ID will break compatibility. Suppress it.
>>
> I saw Stuart's comments on this. Didn't know that there was a way to find
> existing serialid (I thought Eclipse just generated a random one)! I have added
> the class default id.
>
>> There is a peculiar space in the "int []" type name; consider removing it:
>> + Vector<int []> eTbl,
>> ++ Vector<int[]> eTbl,
>>
>> + private Vector<int []> expandTable = null;
>> ++ private Vector<int[]> expandTable = null;
>> + expandTable = new Vector<int []>(INITIALTABLESIZE);
>> ++ expandTable = new Vector<int[]>(INITIALTABLESIZE);
>> + private Vector<int []> expandTable = null;
> Ah, I copied what was there before in RBTableBuilder:
> int[] valueList = (int [])expandTable.elementAt(i);
>
> Fixed everywhere.
>
>
> New webrev:
> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.01/
>
> For convenience, I've also uploaded a diff between previous webrev and
> new one to make it clear as to what changed:
> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.01/rev-00-01.patch
>
> Thanks for the quick and detailed review!
>
> Cheers,
> Deepak
cheers,
R?mi
From mikeb01 at gmail.com Fri Dec 2 11:24:29 2011
From: mikeb01 at gmail.com (Michael Barker)
Date: Fri, 2 Dec 2011 19:24:29 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
Message-ID: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
Hi,
We had some late submissions from our hack day participants. 2 more
patches. One (j.u.z.ZipEntry) is possibly a little more involved for
a warnings fix. It removes a usage of deprecated Date APIs in favour
of Calendar. However, the fix results in code that is very similar to
Apache Harmony implementation. The other is a couple of fixes for
generics (j.u.j.Manifest).
Thanks to:
- Prasannaa
Regards,
Michael Barker
mikeb2701
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/jar/Manifest.java
--- a/src/share/classes/java/util/jar/Manifest.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/jar/Manifest.java Fri Dec 02 19:15:58 2011 +0000
@@ -30,6 +30,7 @@
import java.io.InputStream;
import java.io.OutputStream;
import java.io.IOException;
+import java.nio.charset.StandardCharsets;
import java.util.Map;
import java.util.HashMap;
import java.util.Iterator;
@@ -51,7 +52,7 @@
private Attributes attr = new Attributes();
// manifest entries
- private Map entries = new HashMap();
+ private Map<String, Attributes> entries = new HashMap<>();
/**
* Constructs a new, empty Manifest.
@@ -148,20 +149,20 @@
// Write out the main attributes for the manifest
attr.writeMain(dos);
// Now write out the pre-entry attributes
- Iterator it = entries.entrySet().iterator();
+ Iterator<Map.Entry<String, Attributes>> it = entries.entrySet().iterator();
while (it.hasNext()) {
- Map.Entry e = (Map.Entry)it.next();
+ Map.Entry<String, Attributes> e = it.next();
StringBuffer buffer = new StringBuffer("Name: ");
- String value = (String)e.getKey();
+ String value = e.getKey();
if (value != null) {
- byte[] vb = value.getBytes("UTF8");
- value = new String(vb, 0, 0, vb.length);
+ byte[] vb = value.getBytes(StandardCharsets.UTF_8);
+ value = new String(vb, 0, 0, StandardCharsets.UTF_8);
}
buffer.append(value);
buffer.append("\r\n");
make72Safe(buffer);
dos.writeBytes(buffer.toString());
- ((Attributes)e.getValue()).write(dos);
+ e.getValue().write(dos);
}
dos.flush();
}
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/zip/ZipEntry.java
--- a/src/share/classes/java/util/zip/ZipEntry.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/zip/ZipEntry.java Fri Dec 02 19:12:54 2011 +0000
@@ -24,7 +24,7 @@
*/
package java.util.zip;
-
+import java.util.Calendar;
import java.util.Date;
/**
@@ -281,27 +281,33 @@
* Converts DOS time to Java time (number of milliseconds since epoch).
*/
private static long dosToJavaTime(long dtime) {
- Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
- (int)(((dtime >> 21) & 0x0f) - 1),
- (int)((dtime >> 16) & 0x1f),
- (int)((dtime >> 11) & 0x1f),
- (int)((dtime >> 5) & 0x3f),
- (int)((dtime << 1) & 0x3e));
- return d.getTime();
+ Calendar cal = Calendar.getInstance();
+ cal.set(Calendar.YEAR, (int) ((dtime >> 25) & 0x7f) + 1980);
+ cal.set(Calendar.MONTH, (int) ((dtime >> 21) & 0x0f) - 1);
+ cal.set(Calendar.DATE, (int) (dtime >> 16) & 0x1f);
+ cal.set(Calendar.HOUR_OF_DAY, (int) (dtime >> 11) & 0x1f);
+ cal.set(Calendar.MINUTE, (int) (dtime >> 5) & 0x3f);
+ cal.set(Calendar.SECOND, (int) (dtime << 1) & 0x3e);
+ return cal.getTimeInMillis();
}
/*
* Converts Java time to DOS time.
*/
private static long javaToDosTime(long time) {
- Date d = new Date(time);
- int year = d.getYear() + 1900;
+ Calendar cal = Calendar.getInstance();
+ cal.setTimeInMillis(time);
+ int year = cal.get(Calendar.YEAR);
if (year < 1980) {
return (1 << 21) | (1 << 16);
}
- return (year - 1980) << 25 | (d.getMonth() + 1) << 21 |
- d.getDate() << 16 | d.getHours() << 11 | d.getMinutes() << 5 |
- d.getSeconds() >> 1;
+ int month = cal.get(Calendar.MONTH) + 1;
+ return (year - 1980) << 25
+ | month << 21
+ | cal.get(Calendar.DAY_OF_MONTH) << 16
+ | cal.get(Calendar.HOUR_OF_DAY) << 11
+ | cal.get(Calendar.MINUTE) << 5
+ | cal.get(Calendar.SECOND) >> 1;
}
/**
From dbhole at redhat.com Fri Dec 2 11:32:43 2011
From: dbhole at redhat.com (Deepak Bhole)
Date: Fri, 2 Dec 2011 14:32:43 -0500
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <4ED9250D.7000205@univ-mlv.fr>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<20111202184726.GX2461@redhat.com> <4ED9250D.7000205@univ-mlv.fr>
Message-ID: <20111202193243.GY2461@redhat.com>
* R?mi Forax <forax at univ-mlv.fr> [2011-12-02 14:23]:
> Hi Deepak,
>
> On 12/02/2011 07:47 PM, Deepak Bhole wrote:
> >* John Rose<john.r.rose at oracle.com> [2011-12-01 19:49]:
> >>On Dec 1, 2011, at 3:19 PM, Deepak Bhole wrote:
> >>
[ ... ]
> >Ah, I wasn't sure if I should have used 7-specific features so I stayed
> >away from them (when bootstrapping when ecj, we found diamond to be
> >problematic as older ecj versions cannot understand it). I will change
> >these then.
>
> You can use them everywhere but in langtools because
> the compiler need to bootstrap itself.
Ah okay, thanks.
[ ... ]
> >
> >>For createRunAttributeDataVectors, ensureRunBreak, etc. consider pushing the @SuppressWarnings down onto the individual declarations. It is best to put @SuppressWarnings on the smallest program unit possible, and a local variable declaration is often the right spot. I see that createRunAttributeDataVectors could be viewed as simple enough to mark as a whole, but ensureRunBreak is probably too complex to mark as a whole.
> >>
> >Doh! Good point.
> >
> >For DictionaryBasedBreakIterator.divideUpDictionaryRange, I cannot add
> >it above the
> >"bestBreakPositions = (Stack<Integer>)(currentBreakPositions.clone());" line
> >without refactoring. I done done a very minor refactor (use copy
> >constructor instead of clone) -- please let me know if it is
> >satisfactory.
>
> It seems you still use clone,
> you can't replace a call to clone with a call to a copy constructor because
> if Stack is subclassed, clone will work but not the copy constructor.
>
Doh. Sorry, I forgot to update my reply before sending. Using copy constructor
was my intended approach, but then I realized that Stack itself doesn't have
one (for the exact reason you pointed out :) -- Stack's parent Vector has one).
What I did was create a temp copy object in the local scope (thus allowing
suppression) and then assign the outer scope stack to it.
Sorry for the unnecessary noise.
[ ... ]
> >>For generic array creation, I suggest that you get rid of the "rawtypes" warning on the array element type by adding<?>, before suppressing the "unchecked" warning. Basically, when you find yourself writing new Foo<Bar>[len], change it to new Foo<?>[len]. Then, if you still get an unchecked warning, add SuppressWarnings.
> >>
> >>- Vector newRunAttributes[] = new Vector[newArraySize];
> >>- Vector newRunAttributeValues[] = new Vector[newArraySize];
> >>+ @SuppressWarnings("unchecked") // generic array creation
> >>+ Vector<Attribute> newRunAttributes[] = new Vector<?>[newArraySize];
> >>+ @SuppressWarnings("unchecked") // generic array creation
> >>+ Vector<Object> newRunAttributeValues[] = new Vector<?>[newArraySize];
> >>
> >I tried that yesterday, but the compiler threw errors:
> >
> >../../../src/share/classes/java/text/AttributedString.java:420: error: incompatible types
> > Vector<Attribute> newRunAttributes[] = new Vector<?>[ARRAY_SIZE_INCREMENT];
> > ^
> > required: Vector<Attribute>[]
> > found: Vector<?>[]
>
> Yes, you need to add a cast,
>
> Vector<Attribute>[] newRunAttributes = (Vector<Attribute>[])new Vector<?>[ARRAY_SIZE_INCREMENT];
>
> but if Java is reified in 1.9 as state the current plan, we will be
> in trouble.
>
I see. Then perhaps it is just better to leave the code as it and keep
the suppressions in rev 01? Or should I change it regardless and then
let it be fixed again for 9?
Thanks for taking a look!
Cheers,
Deepak
From forax at univ-mlv.fr Fri Dec 2 11:39:08 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 02 Dec 2011 20:39:08 +0100
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
Message-ID: <4ED9295C.1080705@univ-mlv.fr>
On 12/02/2011 08:24 PM, Michael Barker wrote:
> Hi,
>
> We had some late submissions from our hack day participants. 2 more
> patches. One (j.u.z.ZipEntry) is possibly a little more involved for
> a warnings fix. It removes a usage of deprecated Date APIs in favour
> of Calendar. However, the fix results in code that is very similar to
> Apache Harmony implementation. The other is a couple of fixes for
> generics (j.u.j.Manifest).
>
> Thanks to:
> - Prasannaa
>
> Regards,
> Michael Barker
> mikeb2701
Hi Mickael,
one change to Manifest.java introduces a bug !
- byte[] vb = value.getBytes("UTF8");
- value = new String(vb, 0, 0, vb.length);
+ byte[] vb = value.getBytes(StandardCharsets.UTF_8);
+ value = new String(vb, 0, 0, StandardCharsets.UTF_8);
the last line should be:
value = new String(vb, 0, 0, vb.length);
cheers,
R?mi
From joe.darcy at oracle.com Fri Dec 2 11:48:56 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 02 Dec 2011 11:48:56 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <20111202193243.GY2461@redhat.com>
References: <20111201231919.GQ2461@redhat.com> <1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com> <20111202184726.GX2461@redhat.com>
<4ED9250D.7000205@univ-mlv.fr> <20111202193243.GY2461@redhat.com>
Message-ID: <4ED92BA8.8080504@oracle.com>
On 12/2/2011 11:32 AM, Deepak Bhole wrote:
> * R?mi Forax<forax at univ-mlv.fr> [2011-12-02 14:23]:
>> Hi Deepak,
>>
>> On 12/02/2011 07:47 PM, Deepak Bhole wrote:
>>> * John Rose<john.r.rose at oracle.com> [2011-12-01 19:49]:
>>>> On Dec 1, 2011, at 3:19 PM, Deepak Bhole wrote:
>>>>
> [ ... ]
>
>>> Ah, I wasn't sure if I should have used 7-specific features so I stayed
>>> away from them (when bootstrapping when ecj, we found diamond to be
>>> problematic as older ecj versions cannot understand it). I will change
>>> these then.
>> You can use them everywhere but in langtools because
>> the compiler need to bootstrap itself.
> Ah okay, thanks.
>
FYI, at least in prior incarnations of the JDK build process, there are
also small portions of the core libraries, e.g. the primitive wrapper
classes, that are built using the bootstrap compiler under an earlier
source level.
-Joe
From xueming.shen at oracle.com Fri Dec 2 11:58:06 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 02 Dec 2011 11:58:06 -0800
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
Message-ID: <4ED92DCE.3030108@oracle.com>
The j.u.z.ZipEntry change should NOT be in as a warning cleanup. Will
need further
evaluation/measurement, for example from performance point of view, the
change
now creates a new Calendar instance instead of a Date object (Date class
uses a
singleton BaseCalendar for the calculation, if I remember correctly) for
each invocation.
-Sherman
On 12/02/2011 11:24 AM, Michael Barker wrote:
> Hi,
>
> We had some late submissions from our hack day participants. 2 more
> patches. One (j.u.z.ZipEntry) is possibly a little more involved for
> a warnings fix. It removes a usage of deprecated Date APIs in favour
> of Calendar. However, the fix results in code that is very similar to
> Apache Harmony implementation. The other is a couple of fixes for
> generics (j.u.j.Manifest).
>
> Thanks to:
> - Prasannaa
>
> Regards,
> Michael Barker
> mikeb2701
From mikeb01 at gmail.com Fri Dec 2 12:02:22 2011
From: mikeb01 at gmail.com (Michael Barker)
Date: Fri, 2 Dec 2011 20:02:22 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <4ED9295C.1080705@univ-mlv.fr>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED9295C.1080705@univ-mlv.fr>
Message-ID: <CALwNKeS6ASGdgVcRNhU5zY_UQKioyS-n5BSt0=Djth3ppXr3LA@mail.gmail.com>
> one change to Manifest.java introduces a bug !
>
> - ? ? ? ? ? ? ? ?byte[] vb = value.getBytes("UTF8");
> - ? ? ? ? ? ? ? ?value = new String(vb, 0, 0, vb.length);
> + ? ? ? ? ? ? ? ?byte[] vb = value.getBytes(StandardCharsets.UTF_8);
> + ? ? ? ? ? ? ? ?value = new String(vb, 0, 0, StandardCharsets.UTF_8);
>
>
> the last line should be:
> value = new String(vb, 0, 0, vb.length);
Cheers, good spot. I've attached an updated patch.
Mike.
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/jar/Manifest.java
--- a/src/share/classes/java/util/jar/Manifest.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/jar/Manifest.java Fri Dec 02 19:59:38 2011 +0000
@@ -30,6 +30,7 @@
import java.io.InputStream;
import java.io.OutputStream;
import java.io.IOException;
+import java.nio.charset.StandardCharsets;
import java.util.Map;
import java.util.HashMap;
import java.util.Iterator;
@@ -51,7 +52,7 @@
private Attributes attr = new Attributes();
// manifest entries
- private Map entries = new HashMap();
+ private Map<String, Attributes> entries = new HashMap<>();
/**
* Constructs a new, empty Manifest.
@@ -148,20 +149,20 @@
// Write out the main attributes for the manifest
attr.writeMain(dos);
// Now write out the pre-entry attributes
- Iterator it = entries.entrySet().iterator();
+ Iterator<Map.Entry<String, Attributes>> it = entries.entrySet().iterator();
while (it.hasNext()) {
- Map.Entry e = (Map.Entry)it.next();
+ Map.Entry<String, Attributes> e = it.next();
StringBuffer buffer = new StringBuffer("Name: ");
- String value = (String)e.getKey();
+ String value = e.getKey();
if (value != null) {
- byte[] vb = value.getBytes("UTF8");
+ byte[] vb = value.getBytes(StandardCharsets.UTF_8);
value = new String(vb, 0, 0, vb.length);
}
buffer.append(value);
buffer.append("\r\n");
make72Safe(buffer);
dos.writeBytes(buffer.toString());
- ((Attributes)e.getValue()).write(dos);
+ e.getValue().write(dos);
}
dos.flush();
}
From jonathan.gibbons at oracle.com Fri Dec 2 12:16:55 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 02 Dec 2011 12:16:55 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <4ED92BA8.8080504@oracle.com>
References: <20111201231919.GQ2461@redhat.com> <1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com> <20111202184726.GX2461@redhat.com> <4ED9250D.7000205@univ-mlv.fr>
<20111202193243.GY2461@redhat.com> <4ED92BA8.8080504@oracle.com>
Message-ID: <4ED93237.2000904@oracle.com>
On 12/02/2011 11:48 AM, Joe Darcy wrote:
> On 12/2/2011 11:32 AM, Deepak Bhole wrote:
>> * R?mi Forax<forax at univ-mlv.fr> [2011-12-02 14:23]:
>>> Hi Deepak,
>>>
>>> On 12/02/2011 07:47 PM, Deepak Bhole wrote:
>>>> * John Rose<john.r.rose at oracle.com> [2011-12-01 19:49]:
>>>>> On Dec 1, 2011, at 3:19 PM, Deepak Bhole wrote:
>>>>>
>> [ ... ]
>>
>>>> Ah, I wasn't sure if I should have used 7-specific features so I
>>>> stayed
>>>> away from them (when bootstrapping when ecj, we found diamond to be
>>>> problematic as older ecj versions cannot understand it). I will change
>>>> these then.
>>> You can use them everywhere but in langtools because
>>> the compiler need to bootstrap itself.
>> Ah okay, thanks.
>>
>
> FYI, at least in prior incarnations of the JDK build process, there
> are also small portions of the core libraries, e.g. the primitive
> wrapper classes, that are built using the bootstrap compiler under an
> earlier source level.
>
> -Joe
That was true, and is no longer true. The dependency got "fixed" when
we moved langtools into a separate repo/build, and committed langtools
to being able to work on the boot JDK.
-- Jon
From xueming.shen at oracle.com Fri Dec 2 12:22:32 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 02 Dec 2011 12:22:32 -0800
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <CALwNKeS6ASGdgVcRNhU5zY_UQKioyS-n5BSt0=Djth3ppXr3LA@mail.gmail.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com> <4ED9295C.1080705@univ-mlv.fr>
<CALwNKeS6ASGdgVcRNhU5zY_UQKioyS-n5BSt0=Djth3ppXr3LA@mail.gmail.com>
Message-ID: <4ED93388.4020708@oracle.com>
Mike,
I would prefer to leave the "utf8" usage here un-changed.
From performance point of view, String.getBytes("UTF8") is faster
than String.getBytes(StandardCharsets.UTF_8).
I have some measurement when I did the related performance work at
http://cr.openjdk.java.net/~sherman/7040220/client
http://cr.openjdk.java.net/~sherman/7040220/server
#String.getBytes() is the "encoding".
-Sherman
On 12/02/2011 12:02 PM, Michael Barker wrote:
>> one change to Manifest.java introduces a bug !
>>
>> - byte[] vb = value.getBytes("UTF8");
>> - value = new String(vb, 0, 0, vb.length);
>> + byte[] vb = value.getBytes(StandardCharsets.UTF_8);
>> + value = new String(vb, 0, 0, StandardCharsets.UTF_8);
>>
>>
>> the last line should be:
>> value = new String(vb, 0, 0, vb.length);
> Cheers, good spot. I've attached an updated patch.
>
> Mike.
From ddadacha at redhat.com Fri Dec 2 12:29:14 2011
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Fri, 02 Dec 2011 15:29:14 -0500
Subject: Review request for javax.imageio (Warning Cleanup Day)
Message-ID: <4ED9351A.8040802@redhat.com>
Hi,
Here's a webrev with cleanup in some classes in the javax.imageio
package. I signed up for ImageReader and ImageWriter but cleaned up
ImageIO as well.
Bug: Can someone make one please, thanks!
Webrev:
http://icedtea.classpath.org/~ddadacha/warnings-cleanup-javax-imageio/
I've missed a few warnings in ImageReader and ImageWriter. Methods
addToList and removeFromList (and all their calls) give unchecked cast
warnings. I didn't want to change the method signatures but in doing so,
casting the returns of these method calls still leaves an unchecked
warning that I am not able to resolve. I'll try finding a solution and
will submit another webrev once I get further.
Regards,
Danesh
From mikeb01 at gmail.com Fri Dec 2 12:33:34 2011
From: mikeb01 at gmail.com (Michael Barker)
Date: Fri, 2 Dec 2011 20:33:34 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <4ED93388.4020708@oracle.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED9295C.1080705@univ-mlv.fr>
<CALwNKeS6ASGdgVcRNhU5zY_UQKioyS-n5BSt0=Djth3ppXr3LA@mail.gmail.com>
<4ED93388.4020708@oracle.com>
Message-ID: <CALwNKeTO4PHxqs6dGkwd=n+NMYM1YAb3Bj=J=zKbnCTkscTHrg@mail.gmail.com>
> I would prefer to leave the "utf8" usage here un-changed.
>
> From performance point of view, String.getBytes("UTF8") is faster
> than String.getBytes(StandardCharsets.UTF_8).
Okay, patch updated.
Mike.
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/jar/Manifest.java
--- a/src/share/classes/java/util/jar/Manifest.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/jar/Manifest.java Fri Dec 02 20:31:50 2011 +0000
@@ -30,6 +30,7 @@
import java.io.InputStream;
import java.io.OutputStream;
import java.io.IOException;
+import java.nio.charset.StandardCharsets;
import java.util.Map;
import java.util.HashMap;
import java.util.Iterator;
@@ -51,7 +52,7 @@
private Attributes attr = new Attributes();
// manifest entries
- private Map entries = new HashMap();
+ private Map<String, Attributes> entries = new HashMap<>();
/**
* Constructs a new, empty Manifest.
@@ -148,11 +149,11 @@
// Write out the main attributes for the manifest
attr.writeMain(dos);
// Now write out the pre-entry attributes
- Iterator it = entries.entrySet().iterator();
+ Iterator<Map.Entry<String, Attributes>> it = entries.entrySet().iterator();
while (it.hasNext()) {
- Map.Entry e = (Map.Entry)it.next();
+ Map.Entry<String, Attributes> e = it.next();
StringBuffer buffer = new StringBuffer("Name: ");
- String value = (String)e.getKey();
+ String value = e.getKey();
if (value != null) {
byte[] vb = value.getBytes("UTF8");
value = new String(vb, 0, 0, vb.length);
@@ -161,7 +162,7 @@
buffer.append("\r\n");
make72Safe(buffer);
dos.writeBytes(buffer.toString());
- ((Attributes)e.getValue()).write(dos);
+ e.getValue().write(dos);
}
dos.flush();
}
From philip.race at oracle.com Fri Dec 2 12:44:45 2011
From: philip.race at oracle.com (Phil Race)
Date: Fri, 02 Dec 2011 12:44:45 -0800
Subject: Review request for javax.imageio (Warning Cleanup Day)
In-Reply-To: <4ED9351A.8040802@redhat.com>
References: <4ED9351A.8040802@redhat.com>
Message-ID: <4ED938BD.2030209@oracle.com>
On 12/2/2011 12:29 PM, Danesh Dadachanji wrote:
> Hi,
>
> Here's a webrev with cleanup in some classes in the javax.imageio
> package. I signed up for ImageReader and ImageWriter but cleaned up
> ImageIO as well.
I don't see you on the wiki
http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
>
> Bug: Can someone make one please, thanks!
> Webrev:
> http://icedtea.classpath.org/~ddadacha/warnings-cleanup-javax-imageio/
I've bcc'ed the jdk8-dev on this email, as you should move the review to
the appropriate list (2d-dev).
I don't think we are doing the reviews on the main list, are we ?
>
> I've missed a few warnings in ImageReader and ImageWriter. Methods
> addToList and removeFromList (and all their calls) give unchecked cast
> warnings. I didn't want to change the method signatures but in doing
> so, casting the returns of these method calls still leaves an
> unchecked warning that I am not able to resolve. I'll try finding a
> solution and will submit another webrev once I get further.
>
Don't do anything that would mean an API visible change.
-phil.
> Regards,
> Danesh
From xiomara.jayasena at oracle.com Fri Dec 2 12:47:54 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Fri, 2 Dec 2011 12:47:54 -0800 (PST)
Subject: Review request for javax.imageio (Warning Cleanup Day)
In-Reply-To: <4ED938BD.2030209@oracle.com>
References: <4ED9351A.8040802@redhat.com 4ED938BD.2030209@oracle.com>
Message-ID: <307f8ad7-6a19-4486-b61c-11e31e0c6e59@default>
> -----Original Message-----
>
> I've bcc'ed the jdk8-dev on this email, as you should move the review
> to the appropriate list (2d-dev).
> I don't think we are doing the reviews on the main list, are we ?
In case someone doesn't know where are review should go it can be started here and then move off to the appropriate list.
-Xiomara
From xiomara.jayasena at oracle.com Fri Dec 2 12:53:31 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Fri, 2 Dec 2011 12:53:31 -0800 (PST)
Subject: Review request for javax.imageio (Warning Cleanup Day)
In-Reply-To: <4ED938BD.2030209@oracle.com>
References: <4ED9351A.8040802@redhat.com 4ED938BD.2030209@oracle.com>
Message-ID: <065b3cdd-3851-46d0-b1c2-70b8db5c0a12@default>
>
> I don't see you on the wiki
> http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-
> 12-01%29
> >
I just updated the wiki.
-Xiomara
From jon.vanalten at redhat.com Fri Dec 2 13:11:01 2011
From: jon.vanalten at redhat.com (Jon VanAlten)
Date: Fri, 02 Dec 2011 16:11:01 -0500 (EST)
Subject: Warnings cleanup in java.lang.instrument,
java.lang.management (late entry)
In-Reply-To: <9e2af559-922b-44e8-a34f-5c8c5a0ce4fb@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <d90afbb5-80ce-437f-974a-473e658c9aee@zmail13.collab.prod.int.phx2.redhat.com>
Hi,
This set is quite trivial, seemed almost not worth a webrev, but nonetheless:
http://icedtea.classpath.org/~vanaltj/webrevs/javalangwarnings/
I did make use of one @SuppressWarnings("unchecked") annotation; the same cause for this warning was being suppressed elsewhere in the file and it looked like it would be a messy refactor to do otherwise, if indeed it would even be possible.
Comments? Would anyone like to create a bug and sponsor this set?
Thanks,
jon
From masayoshi.okutsu at oracle.com Fri Dec 2 14:02:32 2011
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 02 Dec 2011 14:02:32 -0800
Subject: Review request for warnings cleanup: some i18n classes in java.util
and sun.util
Message-ID: <4ED94AF8.4080804@oracle.com>
Here are warnings cleanup fixes for some of the i18n classes in
java.util and sun.util.**.
http://cr.openjdk.java.net/~okutsu/8/7117487/webrev.00/
I made some more cleanup suggested by NetBeans (unused imports, private
final, etc.) in addition to the standard compiler warnings cleanup.
Thanks,
Masayoshi
From john.r.rose at oracle.com Fri Dec 2 14:12:04 2011
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 2 Dec 2011 14:12:04 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <20111202184726.GX2461@redhat.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<20111202184726.GX2461@redhat.com>
Message-ID: <21DB2F64-8352-4574-8EFB-58A0C563D907@oracle.com>
On Dec 2, 2011, at 10:47 AM, Deepak Bhole wrote:
>> (Netbeans can find opportunities for diamond operators, BTW.)
>>
>> The new parameters <K extends Attribute, V> are clearly more correct, but they look like an API change on a public method or constructor. If so, I think you'll have to find a different approach. (But I'm not an API change and generics expert.)
>>
>
> Do you mean the changes in the AttributedString constructor? I just
> added names for the bounded and unbound wildcards so that they could be
> used in the body (without it, the compiler was throwing errors).
>
> I am not expert on these either -- I didn't know adding names could
> change signature in an incompatible way.
>
> I just wrote a small test case to try this out and everything seems to
> work fine. Adding named parameters does not appear to break
> compatibility in my test case.
Since this is an important point, I checked into it. Result: Wildcards cannot (in general) be compatibly switched with named type parameters in public APIs.
See the demonstration here:
https://gist.github.com/1424776
(This is subject to correction by someone more expert than me in API evolution, like Alex Buckley, Joe Darcy, or Maurizio Cimadamore. I'm a JVM hacker!)
>> For createRunAttributeDataVectors, ensureRunBreak, etc. consider pushing the @SuppressWarnings down onto the individual declarations. It is best to put @SuppressWarnings on the smallest program unit possible, and a local variable declaration is often the right spot. I see that createRunAttributeDataVectors could be viewed as simple enough to mark as a whole, but ensureRunBreak is probably too complex to mark as a whole.
>>
>
> Doh! Good point.
>
> For DictionaryBasedBreakIterator.divideUpDictionaryRange, I cannot add
> it above the
> "bestBreakPositions = (Stack<Integer>)(currentBreakPositions.clone());" line
> without refactoring. I done done a very minor refactor (use copy
> constructor instead of clone) -- please let me know if it is
> satisfactory.
I'm OK with that. Replacing clone by an equivalent copy constructor looks trivial enough to me, even though it changes bytecode output.
> As for others, I've narrowed it in the new webrev. Narrowing also
> exposed a few more places I had missed in ensureRunBreak. Fixed now.
>
>> In the same way, consider pushing the annotation into the body of class AttributeEntry, even though that class is very simple.
>>
>
> That one is for the declaration itself -- the warning is about the Map
> supertype not being parameterized.
I didn't get that clearly from the comment. Suggest:
+// Suppress warning about raw Map.Entry. Parameterizing Map.Entry correctly
+// requires changing return of getKey
++// Must suppress the whole class to suppress warning about raw supertype Map.Entry.
++// Parameterizing Map.Entry correctly would requires changing return of getKey.
>> For generic array creation, I suggest that you get rid of the "rawtypes" warning on the array element type by adding <?>, before suppressing the "unchecked" warning. Basically, when you find yourself writing new Foo<Bar>[len], change it to new Foo<?>[len]. Then, if you still get an unchecked warning, add SuppressWarnings.
>>
>> - Vector newRunAttributes[] = new Vector[newArraySize];
>> - Vector newRunAttributeValues[] = new Vector[newArraySize];
>> + @SuppressWarnings("unchecked") // generic array creation
>> + Vector<Attribute> newRunAttributes[] = new Vector<?>[newArraySize];
>> + @SuppressWarnings("unchecked") // generic array creation
>> + Vector<Object> newRunAttributeValues[] = new Vector<?>[newArraySize];
>>
>
> I tried that yesterday, but the compiler threw errors:
>
> ../../../src/share/classes/java/text/AttributedString.java:420: error: incompatible types
> Vector<Attribute> newRunAttributes[] = new Vector<?>[ARRAY_SIZE_INCREMENT];
> ^
> required: Vector<Attribute>[]
> found: Vector<?>[]
Sorry, I was not explicit. You need a cast. Here's a complete account:
https://gist.github.com/1425032
>> It is probably a good idea to put a comment on most @SuppressWarnings annotations.
>>
>> Similarly:
>>
>> - private static final SoftReference[] iterCache = new SoftReference[4];
>> +
>> + @SuppressWarnings({"unchecked","rawtypes"})
>> + private static final SoftReference<BreakIteratorCache>[] iterCache = new SoftReference[4];
>> ++ @SuppressWarnings("unchecked")
>> ++ private static final SoftReference<BreakIteratorCache>[] iterCache = new SoftReference<?>[4];
>>
>
> Similar error as above.
My bad! See above.
>
>> There is an apparent behavior change in CollationElementIterator.setOffset, in this chunk:
>> - int c = text.setIndex(newOffset);
>> + text.setIndexOnly(newOffset);
>> + int c = text.current();
>>
>
> setIndex is deprecated, so I looked into what the method did and did it
> at the call site. Sorry, I should have specifically mentioned this
> re-factor in the original email :(
>
> I am fine with just suppressing deprecation warning there. I have done
> so in the new copy by adding the annotation to the method.
Right. Don't inline the deprecated method body. Just suppress the deprecation warning, with a comment. (Maybe put the body expressions in a comment, for the next person who touches the code.)
>> (About 50% through. More to come...)
>>
>
> (from the second email):
>
>> Here's the rest.
>>
>> I think the method divideUpDictionaryRange is too complex (181 LOC) to be covered by one @SuppressWarnings. Even adding 30 annotations in the body would be better, since then the other 151 LOC would remain protected.
>>
>> I do like the informative comment on @SuppressWarnings:
>> + @SuppressWarnings("unchecked") // suppress unchecked warning for cloning stack
>>
>
> Fixed with a minor re-factor as mentioned above.
OK. You could also have put on a cast plus @SW("unchecked").
>>
>> This one has to be at class level; good comment:
>> + at SuppressWarnings("serial") // Adding serial ID will break compatibility. Suppress it.
>>
>
> I saw Stuart's comments on this. Didn't know that there was a way to find
> existing serialid (I thought Eclipse just generated a random one)! I have added
> the class default id.
Yep. SW("serial") seems to be the wrong thing, almost everywhere.
> New webrev:
> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.01/
>
> For convenience, I've also uploaded a diff between previous webrev and
> new one to make it clear as to what changed:
> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.01/rev-00-01.patch
>
> Thanks for the quick and detailed review!
It looks good to me, after you get rid of SW(rawtypes) and remove (sadly!) the named type parameters.
-- John
From john.r.rose at oracle.com Fri Dec 2 14:19:48 2011
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 2 Dec 2011 14:19:48 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <4ED9250D.7000205@univ-mlv.fr>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<20111202184726.GX2461@redhat.com> <4ED9250D.7000205@univ-mlv.fr>
Message-ID: <97CB3872-A2F2-4013-8E7A-5D97CAFC072F@oracle.com>
On Dec 2, 2011, at 11:20 AM, R?mi Forax wrote:
> It seems you still use clone,
> you can't replace a call to clone with a call to a copy constructor because
> if Stack is subclassed, clone will work but not the copy constructor.
That's true in general, but this is private code with locally created Stack instances.
>> ../../../src/share/classes/java/text/AttributedString.java:420: error: incompatible types
>> Vector<Attribute> newRunAttributes[] = new Vector<?>[ARRAY_SIZE_INCREMENT];
>> ^
>> required: Vector<Attribute>[]
>> found: Vector<?>[]
>
> Yes, you need to add a cast,
>
> Vector<Attribute>[] newRunAttributes = (Vector<Attribute>[])new Vector<?>[ARRAY_SIZE_INCREMENT];
Yes. As far as I can see, that's the "best practices" way to deal with array-of-generic.
> but if Java is reified in 1.9 as state the current plan, we will be in trouble.
If the best practices have to change, then we'll have to change that code again. Or maybe the retrofit strategy will have to take account of the existing code idioms. In any case, we'll cross that bridge when we get to it. (Coping with reification in this case is a decision to make tomorrow, not today.)
-- John
From john.r.rose at oracle.com Fri Dec 2 14:20:38 2011
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 2 Dec 2011 14:20:38 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <20111202193243.GY2461@redhat.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<20111202184726.GX2461@redhat.com> <4ED9250D.7000205@univ-mlv.fr>
<20111202193243.GY2461@redhat.com>
Message-ID: <989F9845-8F24-4D19-9BC3-C6684FE0A6B3@oracle.com>
On Dec 2, 2011, at 11:32 AM, Deepak Bhole wrote:
> I see. Then perhaps it is just better to leave the code as it and keep
> the suppressions in rev 01? Or should I change it regardless and then
> let it be fixed again for 9?
Don't worry about 9 right now. -- John
From masayoshi.okutsu at oracle.com Fri Dec 2 14:24:24 2011
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 02 Dec 2011 14:24:24 -0800
Subject: Review request for IMF classes and Locale related classes
In-Reply-To: <4ED91F51.2020502@oracle.com>
References: <4ED91F51.2020502@oracle.com>
Message-ID: <4ED95018.3070808@oracle.com>
Looks good to me.
Thanks,
Masayoshi
On 2011/12/02 10:56, Naoto Sato wrote:
> Hello,
>
> Could you please review these two changesets for the WCD? One is for
> classes that belongs to input method framework:
>
> http://cr.openjdk.java.net/~naoto/7117465/webrev.00/
>
> and the other is for (some of the) i18n related *.util.* classes:
>
> http://cr.openjdk.java.net/~naoto/7117469/webrev.00/
>
> Thanks!
> Naoto
From martijnverburg at gmail.com Fri Dec 2 14:28:26 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 2 Dec 2011 22:28:26 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <4ED9295C.1080705@univ-mlv.fr>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED9295C.1080705@univ-mlv.fr>
Message-ID: <CAP7YuAQuEBFuvL8+hsw48wn_vsTYppDdAs23ofK-TBzZ2UG5Yg@mail.gmail.com>
Hi R?mi,
Doesn't that then use the deprecated String constructor?
Disclaimer - I was involved in that patch :)
Cheers,
Martijn
On Friday, 2 December 2011, R?mi Forax <forax at univ-mlv.fr> wrote:
> On 12/02/2011 08:24 PM, Michael Barker wrote:
>>
>> Hi,
>>
>> We had some late submissions from our hack day participants. 2 more
>> patches. One (j.u.z.ZipEntry) is possibly a little more involved for
>> a warnings fix. It removes a usage of deprecated Date APIs in favour
>> of Calendar. However, the fix results in code that is very similar to
>> Apache Harmony implementation. The other is a couple of fixes for
>> generics (j.u.j.Manifest).
>>
>> Thanks to:
>> - Prasannaa
>>
>> Regards,
>> Michael Barker
>> mikeb2701
>
> Hi Mickael,
> one change to Manifest.java introduces a bug !
>
> - byte[] vb = value.getBytes("UTF8");
> - value = new String(vb, 0, 0, vb.length);
> + byte[] vb = value.getBytes(StandardCharsets.UTF_8);
> + value = new String(vb, 0, 0, StandardCharsets.UTF_8);
>
>
> the last line should be:
> value = new String(vb, 0, 0, vb.length);
>
> cheers,
> R?mi
>
From martijnverburg at gmail.com Fri Dec 2 14:32:02 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 2 Dec 2011 22:32:02 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <4ED92DCE.3030108@oracle.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED92DCE.3030108@oracle.com>
Message-ID: <CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
Hi Sherman,
I think the original patch provider (Prasanna) was aiming at simply
removing the deprecation warning. Interesting point on the performance
aspect!
Is performance for this class already measured in an OpenJDK test
somewhere? Perhaps we could provide a test suite in this instance?
Cheers,
Martijn
On Friday, 2 December 2011, Xueming Shen <xueming.shen at oracle.com> wrote:
>
> The j.u.z.ZipEntry change should NOT be in as a warning cleanup. Will
need further
> evaluation/measurement, for example from performance point of view, the
change
> now creates a new Calendar instance instead of a Date object (Date class
uses a
> singleton BaseCalendar for the calculation, if I remember correctly) for
each invocation.
>
> -Sherman
>
> On 12/02/2011 11:24 AM, Michael Barker wrote:
>>
>> Hi,
>>
>> We had some late submissions from our hack day participants. 2 more
>> patches. One (j.u.z.ZipEntry) is possibly a little more involved for
>> a warnings fix. It removes a usage of deprecated Date APIs in favour
>> of Calendar. However, the fix results in code that is very similar to
>> Apache Harmony implementation. The other is a couple of fixes for
>> generics (j.u.j.Manifest).
>>
>> Thanks to:
>> - Prasannaa
>>
>> Regards,
>> Michael Barker
>> mikeb2701
>
>
From Lance.Andersen at oracle.com Fri Dec 2 14:33:31 2011
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 2 Dec 2011 17:33:31 -0500
Subject: Review request for warnings cleanup: some i18n classes in
java.util and sun.util
In-Reply-To: <4ED94AF8.4080804@oracle.com>
References: <4ED94AF8.4080804@oracle.com>
Message-ID: <9EB42172-24B3-460C-A83D-91A7ADCFE37C@oracle.com>
This looks OK
On Dec 2, 2011, at 5:02 PM, Masayoshi Okutsu wrote:
> Here are warnings cleanup fixes for some of the i18n classes in java.util and sun.util.**.
>
> http://cr.openjdk.java.net/~okutsu/8/7117487/webrev.00/
>
> I made some more cleanup suggested by NetBeans (unused imports, private final, etc.) in addition to the standard compiler warnings cleanup.
>
> Thanks,
> Masayoshi
>
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
From martijnverburg at gmail.com Fri Dec 2 14:34:28 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 2 Dec 2011 22:34:28 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <4ED93388.4020708@oracle.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED9295C.1080705@univ-mlv.fr>
<CALwNKeS6ASGdgVcRNhU5zY_UQKioyS-n5BSt0=Djth3ppXr3LA@mail.gmail.com>
<4ED93388.4020708@oracle.com>
Message-ID: <CAP7YuARiVOdfjY5vLU0htPMBCXsNcC6xbrpDKK1b60Pu5Lokog@mail.gmail.com>
Is it worth adding a comment to that code, or should that sort of
performance implication be understood by OpenJDK contributors?
I only ask because I can see myself foolishly applying the StandardCharsets
'fix' in 6 months time when I've forgotten this thread :)
Cheers,
Martijn
On Friday, 2 December 2011, Xueming Shen <xueming.shen at oracle.com> wrote:
> Mike,
>
> I would prefer to leave the "utf8" usage here un-changed.
>
> From performance point of view, String.getBytes("UTF8") is faster
> than String.getBytes(StandardCharsets.UTF_8).
>
> I have some measurement when I did the related performance work at
>
> http://cr.openjdk.java.net/~sherman/7040220/client
> http://cr.openjdk.java.net/~sherman/7040220/server
>
> #String.getBytes() is the "encoding".
>
>
> -Sherman
>
> On 12/02/2011 12:02 PM, Michael Barker wrote:
>>>
>>> one change to Manifest.java introduces a bug !
>>>
>>> - byte[] vb = value.getBytes("UTF8");
>>> - value = new String(vb, 0, 0, vb.length);
>>> + byte[] vb = value.getBytes(StandardCharsets.UTF_8);
>>> + value = new String(vb, 0, 0, StandardCharsets.UTF_8);
>>>
>>>
>>> the last line should be:
>>> value = new String(vb, 0, 0, vb.length);
>>
>> Cheers, good spot. I've attached an updated patch.
>>
>> Mike.
>
>
From brian.goetz at oracle.com Fri Dec 2 14:41:57 2011
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 02 Dec 2011 17:41:57 -0500
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <4ED9250D.7000205@univ-mlv.fr>
References: <20111201231919.GQ2461@redhat.com> <1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com> <20111202184726.GX2461@redhat.com>
<4ED9250D.7000205@univ-mlv.fr>
Message-ID: <4ED95435.4000509@oracle.com>
> but if Java is reified in 1.9 as state the current plan, we will be in
> trouble.
To be clear, there is no "current plan" for Java 9. At JavaOne and
Devoxx, Mark outlined a list of "possible things to look at" in future
versions of Java, and reification was on that list.
From mandy.chung at oracle.com Fri Dec 2 14:45:13 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 02 Dec 2011 14:45:13 -0800
Subject: Warnings cleanup in java.lang.instrument, java.lang.management
(late entry)
In-Reply-To: <d90afbb5-80ce-437f-974a-473e658c9aee@zmail13.collab.prod.int.phx2.redhat.com>
References: <d90afbb5-80ce-437f-974a-473e658c9aee@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4ED954F9.5080109@oracle.com>
On 12/2/2011 1:11 PM, Jon VanAlten wrote:
> Hi,
>
> This set is quite trivial, seemed almost not worth a webrev, but nonetheless:
>
> http://icedtea.classpath.org/~vanaltj/webrevs/javalangwarnings/
>
Thanks for the fix. I can sponsor this trivial one.
> I did make use of one @SuppressWarnings("unchecked") annotation;
PlatformComponent.java
L386: this can be replaced by calling the getMXBeans(mxbeanInterface)
method that does the cast and with unchecked warning suppressed.
ClassDefinition.java
L43: nit: the variable name was aligned with L48 and I will fix
the formatting to get the name realigned.
> the same cause for this warning was being suppressed elsewhere in the file and it looked like it would be a messy refactor to do otherwise, if indeed it would even be possible.
>
There are two unchecked warning suppressed in PlatformComponent.java
which are safe. What do you have in mind for the refactoring
to eliminate these two @SuppressWarnings? I may be missing
something but I don't see what refactoring can help. Anyway,
this trivial fix will get rid of a few warnings. Thanks.
> Comments? Would anyone like to create a bug and sponsor this set?
>
7117585 Eliminate java.lang.instrument, java.lang.management warnings
Mandy
From stuart.marks at oracle.com Fri Dec 2 14:52:19 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 02 Dec 2011 14:52:19 -0800
Subject: Review Request for 7116993 (warning cleanup java.applet)
In-Reply-To: <4ED899B4.7000207@oracle.com>
References: <4ED7E98F.3040200@oracle.com> <4ED7EE3E.6020109@oracle.com>
<4ED899B4.7000207@oracle.com>
Message-ID: <4ED956A3.80006@oracle.com>
Hi Artem,
It turns out that Danesh Dadachanji had also been working on java.applet. The
changes are identical, so there's no conflict.
Is it OK if this change goes into the TL forest? If so, I can handle the push.
Otherwise we'll to figure out something else.
s'marks
On 12/2/11 1:26 AM, Artem Ananiev wrote:
>
> I haven't seen anyone else working on java.applet. Your webrev looks fine.
>
> Thanks,
>
> Artem
>
> On 12/2/2011 1:14 AM, Brandon Passanisi wrote:
>> I'll withdraw this review request as I was notified by Xiomara that
>> someone else has been working on java.applet. I had sent an e-mail to
>> the alias yesterday about taking on java.applet though. Luckily, there
>> aren't many warnings in java.applet.
>>
>> On 12/1/2011 12:54 PM, Brandon Passanisi wrote:
>>> I have a webrev pertaining to the warning cleanup changes for
>>> java.applet ready for review. Here's the info:
>>>
>>> Bug: 7116993
>>> Webrev:
>>> http://cr.openjdk.java.net/~dmocek/bpassanisi/7116993/webrev.00/
>>> <http://cr.openjdk.java.net/%7Edmocek/bpassanisi/7116993/webrev.00/>
>>>
>>> Thanks.
>>
From naoto.sato at oracle.com Fri Dec 2 15:03:08 2011
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 02 Dec 2011 15:03:08 -0800
Subject: Review request for warnings cleanup: some i18n classes in
java.util and sun.util
In-Reply-To: <4ED94AF8.4080804@oracle.com>
References: <4ED94AF8.4080804@oracle.com>
Message-ID: <4ED9592C.90701@oracle.com>
Looks good to me.
Naoto
On 12/2/11 2:02 PM, Masayoshi Okutsu wrote:
> Here are warnings cleanup fixes for some of the i18n classes in
> java.util and sun.util.**.
>
> http://cr.openjdk.java.net/~okutsu/8/7117487/webrev.00/
>
> I made some more cleanup suggested by NetBeans (unused imports, private
> final, etc.) in addition to the standard compiler warnings cleanup.
>
> Thanks,
> Masayoshi
>
From kurchi.subhra.hazra at oracle.com Fri Dec 2 15:09:56 2011
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Fri, 02 Dec 2011 15:09:56 -0800
Subject: Review Request: Warnings cleanup in sun.management and its subpackages
Message-ID: <4ED95AC4.2090905@oracle.com>
Hi,
http://cr.openjdk.java.net/~khazra/7117570/webrev.00/
Please review this webrev that cleans warnings in sun.management and
its subpackages. These packages are now warning-free I believe.
Looking forward to your comments. I have used the serialver tool to
generate all the serial version UIDs that I have added.
Thanks,
Kurchi
From martijnverburg at gmail.com Fri Dec 2 15:12:37 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 2 Dec 2011 23:12:37 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <CAP7YuAQuEBFuvL8+hsw48wn_vsTYppDdAs23ofK-TBzZ2UG5Yg@mail.gmail.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED9295C.1080705@univ-mlv.fr>
<CAP7YuAQuEBFuvL8+hsw48wn_vsTYppDdAs23ofK-TBzZ2UG5Yg@mail.gmail.com>
Message-ID: <CAP7YuASCthRPC1M_ndJ=iRW_HKM41zLqaf+oCnv4Vs-4sOWy9w@mail.gmail.com>
Hi Remi,
Sorry, was on my phone earlier - so to clarify, I swapped:
String(byte[] ascii, int hibyte, int offset, int count)
to
String(byte[] bytes, int offset, int length, String charsetName)
The reasoning was that I didn't think the count had any actual value
in this call and from the deprecated warning on the first constructor:
"This method does not properly convert bytes into characters. As of
JDK 1.1, the preferred way to do this is via the String constructors
that take a Charset, charset name, or that use the platform's default
charset."
Hmm, I can't see another 'safe' constructor that takes a byte[] and a
count. Is there another recommended way around this?
Cheers,
Martijn
On 2 December 2011 22:28, Martijn Verburg <martijnverburg at gmail.com> wrote:
> Hi R?mi,
>
> Doesn't that then use the deprecated String constructor?
>
> Disclaimer - I was involved in that patch :)
>
> Cheers,
> Martijn
>
>
> On Friday, 2 December 2011, R?mi Forax <forax at univ-mlv.fr> wrote:
>> On 12/02/2011 08:24 PM, Michael Barker wrote:
>>>
>>> Hi,
>>>
>>> We had some late submissions from our hack day participants. ?2 more
>>> patches. ?One (j.u.z.ZipEntry) is possibly a little more involved for
>>> a warnings fix. ?It removes a usage of deprecated Date APIs in favour
>>> of Calendar. ?However, the fix results in code that is very similar to
>>> Apache Harmony implementation. ?The other is a couple of fixes for
>>> generics (j.u.j.Manifest).
>>>
>>> Thanks to:
>>> - Prasannaa
>>>
>>> Regards,
>>> Michael Barker
>>> mikeb2701
>>
>> Hi Mickael,
>> one change to Manifest.java introduces a bug !
>>
>> - ? ? ? ? ? ? ? ?byte[] vb = value.getBytes("UTF8");
>> - ? ? ? ? ? ? ? ?value = new String(vb, 0, 0, vb.length);
>> + ? ? ? ? ? ? ? ?byte[] vb = value.getBytes(StandardCharsets.UTF_8);
>> + ? ? ? ? ? ? ? ?value = new String(vb, 0, 0, StandardCharsets.UTF_8);
>>
>>
>> the last line should be:
>> value = new String(vb, 0, 0, vb.length);
>>
>> cheers,
>> R?mi
>>
From xueming.shen at oracle.com Fri Dec 2 15:18:03 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 02 Dec 2011 15:18:03 -0800
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com> <4ED92DCE.3030108@oracle.com>
<CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
Message-ID: <4ED95CAB.3030505@oracle.com>
On 12/02/2011 02:32 PM, Martijn Verburg wrote:
> Hi Sherman,
>
> I think the original patch provider (Prasanna) was aiming at simply
> removing the deprecation warning. Interesting point on the
> performance aspect!
>
> Is performance for this class already measured in an OpenJDK test
> somewhere? Perhaps we could provide a test suite in this instance?
Hi Martijn,
No, I don't think we have a benchmark test case anywhere in OpenJDK to
measure
this performance. I happened to take a quick look at the "calculation
cost" of
dosToJavaTime() last month when working on that jar n-thread performance
issue.
Here is a the result of a quick/dirty "non-benchmark" benchmark test
case, which
suggests the proposed change is way too slow, this is only from the
"speed" angle,
I would assume it probably also consumes more temporary (young-gen) memory.
So, the suggested approach appears not to be a good candidate to go in
without
further tuning.
sherman at sherman-linux:~/Workspace/test$ java -server JavaDosTime
j2dt :386
j2dt2 :1282
d2jt :424
d2jt2 :1296
sherman at sherman-linux:~/Workspace/test$ java -client JavaDosTime
j2dt :621
j2dt2 :1901
d2jt :662
d2jt2 :2016
public class JavaDosTime {
public static void main(String[] args) throws IOException {
long tt0 = System.currentTimeMillis();
int ii = 0;
for (ii = 0; ii < 1000000; ii++) {
long t = 10000 + ii;
t= javaToDosTime(t);
}
long tt1 = System.currentTimeMillis();
System.out.println("j2dt :" + (tt1 - tt0));
tt0 = System.currentTimeMillis();
ii = 0;
for (ii = 0; ii < 1000000; ii++) {
long t = 10000 + ii;
t= javaToDosTime2(t);
}
tt1 = System.currentTimeMillis();
System.out.println("j2dt2 :" + (tt1 - tt0));
tt0 = System.currentTimeMillis();
ii = 0;
for (ii = 0; ii < 1000000; ii++) {
long t = 10000 + ii;
t= dosToJavaTime(t);
}
tt1 = System.currentTimeMillis();
System.out.println("d2jt :" + (tt1 - tt0));
tt0 = System.currentTimeMillis();
ii = 0;
for (ii = 0; ii < 1000000; ii++) {
long t = 10000 + ii;
t= dosToJavaTime2(t);
}
tt1 = System.currentTimeMillis();
System.out.println("d2jt2 :" + (tt1 - tt0));
}
private static long javaToDosTime(long time){
Date d = new Date(time);
int year = d.getYear() + 1900;
if (year < 1980) {
return (1 << 21) | (1 << 16);
}
return (year - 1980) << 25 | (d.getMonth() + 1) << 21 |
d.getDate() << 16 | d.getHours() << 11 | d.getMinutes()
<< 5 |
d.getSeconds() >> 1;
}
private static long javaToDosTime2(long time){
Calendar cal = Calendar.getInstance();
cal.setTimeInMillis(time);
int year = cal.get(Calendar.YEAR);
if (year < 1980) {
return (1 << 21) | (1 << 16);
}
int month = cal.get(Calendar.MONTH) + 1;
return (year - 1980) << 25
| month << 21
| cal.get(Calendar.DAY_OF_MONTH) << 16
| cal.get(Calendar.HOUR_OF_DAY) << 11
| cal.get(Calendar.MINUTE) << 5
| cal.get(Calendar.SECOND) >> 1;
}
private static long dosToJavaTime(long dtime) {
Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
(int)(((dtime >> 21) & 0x0f) - 1),
(int)((dtime >> 16) & 0x1f),
(int)((dtime >> 11) & 0x1f),
(int)((dtime >> 5) & 0x3f),
(int)((dtime << 1) & 0x3e));
return d.getTime();
}
private static long dosToJavaTime2(long dtime) {
Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, (int) ((dtime >> 25) & 0x7f) + 1980);
cal.set(Calendar.MONTH, (int) ((dtime >> 21) & 0x0f) - 1);
cal.set(Calendar.DATE, (int) (dtime >> 16) & 0x1f);
cal.set(Calendar.HOUR_OF_DAY, (int) (dtime >> 11) & 0x1f);
cal.set(Calendar.MINUTE, (int) (dtime >> 5) & 0x3f);
cal.set(Calendar.SECOND, (int) (dtime << 1) & 0x3e);
return cal.getTimeInMillis();
}
}
>
> Cheers,
> Martijn
>
> On Friday, 2 December 2011, Xueming Shen <xueming.shen at oracle.com
> <mailto:xueming.shen at oracle.com>> wrote:
> >
> > The j.u.z.ZipEntry change should NOT be in as a warning cleanup.
> Will need further
> > evaluation/measurement, for example from performance point of view,
> the change
> > now creates a new Calendar instance instead of a Date object (Date
> class uses a
> > singleton BaseCalendar for the calculation, if I remember correctly)
> for each invocation.
> >
> > -Sherman
> >
> > On 12/02/2011 11:24 AM, Michael Barker wrote:
> >>
> >> Hi,
> >>
> >> We had some late submissions from our hack day participants. 2 more
> >> patches. One (j.u.z.ZipEntry) is possibly a little more involved for
> >> a warnings fix. It removes a usage of deprecated Date APIs in favour
> >> of Calendar. However, the fix results in code that is very similar to
> >> Apache Harmony implementation. The other is a couple of fixes for
> >> generics (j.u.j.Manifest).
> >>
> >> Thanks to:
> >> - Prasannaa
> >>
> >> Regards,
> >> Michael Barker
> >> mikeb2701
> >
> >
From jon.vanalten at redhat.com Fri Dec 2 15:30:37 2011
From: jon.vanalten at redhat.com (Jon VanAlten)
Date: Fri, 02 Dec 2011 18:30:37 -0500 (EST)
Subject: Warnings cleanup in java.lang.instrument,
java.lang.management (late entry)
In-Reply-To: <4ED954F9.5080109@oracle.com>
Message-ID: <98c306b7-3b68-42a1-8503-079e47cc7694@zmail13.collab.prod.int.phx2.redhat.com>
Hi,
----- Original Message -----
> From: "Mandy Chung" <mandy.chung at oracle.com>
> To: jdk8-dev at openjdk.java.net
> Sent: Friday, December 2, 2011 5:45:13 PM
> Subject: Re: Warnings cleanup in java.lang.instrument, java.lang.management (late entry)
>
> On 12/2/2011 1:11 PM, Jon VanAlten wrote:
> > Hi,
> >
> > This set is quite trivial, seemed almost not worth a webrev, but
> > nonetheless:
> >
> > http://icedtea.classpath.org/~vanaltj/webrevs/javalangwarnings/
> >
> Thanks for the fix. I can sponsor this trivial one.
>
Great, and thanks for looking at it!
>
> > I did make use of one @SuppressWarnings("unchecked") annotation;
> PlatformComponent.java
> L386: this can be replaced by calling the
> getMXBeans(mxbeanInterface)
> method that does the cast and with unchecked warning suppressed.
>
Ah, good idea.
> ClassDefinition.java
> L43: nit: the variable name was aligned with L48 and I will fix
> the formatting to get the name realigned.
>
I didn't notice the intentional alignment, sorry.
> > the same cause for this warning was being suppressed elsewhere in
> > the file and it looked like it would be a messy refactor to do
> > otherwise, if indeed it would even be possible.
> >
>
> There are two unchecked warning suppressed in PlatformComponent.java
> which are safe. What do you have in mind for the refactoring
> to eliminate these two @SuppressWarnings? I may be missing
> something but I don't see what refactoring can help. Anyway,
> this trivial fix will get rid of a few warnings. Thanks.
>
TBH, I hadn't really thought much on it. You are probably right that
there is no good way to help it.
For completeness, I've updated webrev:
http://icedtea.classpath.org/~vanaltj/webrevs/javalangwarnings/
Thanks,
jon
From stuart.marks at oracle.com Fri Dec 2 15:32:21 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 02 Dec 2011 15:32:21 -0800
Subject: Review request for IMF classes and Locale related classes
In-Reply-To: <4ED95018.3070808@oracle.com>
References: <4ED91F51.2020502@oracle.com> <4ED95018.3070808@oracle.com>
Message-ID: <4ED96005.3000709@oracle.com>
Hi Naoto,
A couple comments.
java/util/Currency.java --
The @SuppressWarnings covers the entire method. We're trying to use
@SuppressWarnings with as narrow a scope as possible. Sometimes it's helpful to
create a local variable declaration for this purpose; perhaps something like
this will help:
@SuppressedWarnings("unchecked")
Set<Currency> result = (Set<Currency>) available.clone();
return result;
You can probably do something similar in
sun/util/LocaleServiceProviderPool.java in the getLocalizedObjectImpl() method.
The suppression of warnings on the static AllAvailableLocales class is a bit of
a puzzle. Maybe it's OK to leave the suppression for that entire class.
s'marks
On 12/2/11 2:24 PM, Masayoshi Okutsu wrote:
> Looks good to me.
>
> Thanks,
> Masayoshi
>
> On 2011/12/02 10:56, Naoto Sato wrote:
>> Hello,
>>
>> Could you please review these two changesets for the WCD? One is for classes
>> that belongs to input method framework:
>>
>> http://cr.openjdk.java.net/~naoto/7117465/webrev.00/
>>
>> and the other is for (some of the) i18n related *.util.* classes:
>>
>> http://cr.openjdk.java.net/~naoto/7117469/webrev.00/
>>
>> Thanks!
>> Naoto
From xueming.shen at oracle.com Fri Dec 2 15:42:08 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 02 Dec 2011 15:42:08 -0800
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <CAP7YuASCthRPC1M_ndJ=iRW_HKM41zLqaf+oCnv4Vs-4sOWy9w@mail.gmail.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com> <4ED9295C.1080705@univ-mlv.fr> <CAP7YuAQuEBFuvL8+hsw48wn_vsTYppDdAs23ofK-TBzZ2UG5Yg@mail.gmail.com>
<CAP7YuASCthRPC1M_ndJ=iRW_HKM41zLqaf+oCnv4Vs-4sOWy9w@mail.gmail.com>
Message-ID: <4ED96250.4080708@oracle.com>
Martijn,
The proposed change is incorrect.
+ value = new String(vb, 0, 0, StandardCharsets.UTF_8);
First, shouldn't it at least be
value = new String(vb, StandardCharsets.UTF_8);
or
value = new String(vb, 0, vb.length, StandardCharsets.UTF_8);
Second, the "value" will be written out via dos.writeBytes(String)
later, which only
takes the low-byte of a each char of the target String object.
That "not properly" conversion is actually what we need here to make
sure the
output will be correctly in utf8. The only "reliable" replacement might
be to use
"iso8859-1" (not utf_8), but I would recommend keep it un-touched.
-Sherman
On 12/02/2011 03:12 PM, Martijn Verburg wrote:
> Hi Remi,
>
> Sorry, was on my phone earlier - so to clarify, I swapped:
>
> String(byte[] ascii, int hibyte, int offset, int count)
>
> to
>
> String(byte[] bytes, int offset, int length, String charsetName)
>
> The reasoning was that I didn't think the count had any actual value
> in this call and from the deprecated warning on the first constructor:
>
> "This method does not properly convert bytes into characters. As of
> JDK 1.1, the preferred way to do this is via the String constructors
> that take a Charset, charset name, or that use the platform's default
> charset."
>
> Hmm, I can't see another 'safe' constructor that takes a byte[] and a
> count. Is there another recommended way around this?
>
> Cheers,
> Martijn
>
> On 2 December 2011 22:28, Martijn Verburg<martijnverburg at gmail.com> wrote:
>> Hi R?mi,
>>
>> Doesn't that then use the deprecated String constructor?
>>
>> Disclaimer - I was involved in that patch :)
>>
>> Cheers,
>> Martijn
>>
>>
>> On Friday, 2 December 2011, R?mi Forax<forax at univ-mlv.fr> wrote:
>>> On 12/02/2011 08:24 PM, Michael Barker wrote:
>>>> Hi,
>>>>
>>>> We had some late submissions from our hack day participants. 2 more
>>>> patches. One (j.u.z.ZipEntry) is possibly a little more involved for
>>>> a warnings fix. It removes a usage of deprecated Date APIs in favour
>>>> of Calendar. However, the fix results in code that is very similar to
>>>> Apache Harmony implementation. The other is a couple of fixes for
>>>> generics (j.u.j.Manifest).
>>>>
>>>> Thanks to:
>>>> - Prasannaa
>>>>
>>>> Regards,
>>>> Michael Barker
>>>> mikeb2701
>>> Hi Mickael,
>>> one change to Manifest.java introduces a bug !
>>>
>>> - byte[] vb = value.getBytes("UTF8");
>>> - value = new String(vb, 0, 0, vb.length);
>>> + byte[] vb = value.getBytes(StandardCharsets.UTF_8);
>>> + value = new String(vb, 0, 0, StandardCharsets.UTF_8);
>>>
>>>
>>> the last line should be:
>>> value = new String(vb, 0, 0, vb.length);
>>>
>>> cheers,
>>> R?mi
>>>
From naoto.sato at oracle.com Fri Dec 2 16:00:42 2011
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 02 Dec 2011 16:00:42 -0800
Subject: Review request for IMF classes and Locale related classes
In-Reply-To: <4ED96005.3000709@oracle.com>
References: <4ED91F51.2020502@oracle.com> <4ED95018.3070808@oracle.com>
<4ED96005.3000709@oracle.com>
Message-ID: <4ED966AA.2010701@oracle.com>
Hi Stuart,
Thank you for your comments. Here is the updated webrev reflecting your
suggestions. Please review:
http://cr.openjdk.java.net/~naoto/7117469/webrev.01/
Naoto
On 12/2/11 3:32 PM, Stuart Marks wrote:
> Hi Naoto,
>
> A couple comments.
>
> java/util/Currency.java --
>
> The @SuppressWarnings covers the entire method. We're trying to use
> @SuppressWarnings with as narrow a scope as possible. Sometimes it's
> helpful to create a local variable declaration for this purpose; perhaps
> something like this will help:
>
> @SuppressedWarnings("unchecked")
> Set<Currency> result = (Set<Currency>) available.clone();
> return result;
>
> You can probably do something similar in
> sun/util/LocaleServiceProviderPool.java in the getLocalizedObjectImpl()
> method.
>
> The suppression of warnings on the static AllAvailableLocales class is a
> bit of a puzzle. Maybe it's OK to leave the suppression for that entire
> class.
>
> s'marks
>
>
> On 12/2/11 2:24 PM, Masayoshi Okutsu wrote:
>> Looks good to me.
>>
>> Thanks,
>> Masayoshi
>>
>> On 2011/12/02 10:56, Naoto Sato wrote:
>>> Hello,
>>>
>>> Could you please review these two changesets for the WCD? One is for
>>> classes
>>> that belongs to input method framework:
>>>
>>> http://cr.openjdk.java.net/~naoto/7117465/webrev.00/
>>>
>>> and the other is for (some of the) i18n related *.util.* classes:
>>>
>>> http://cr.openjdk.java.net/~naoto/7117469/webrev.00/
>>>
>>> Thanks!
>>> Naoto
From xiomara.jayasena at oracle.com Fri Dec 2 16:06:39 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Fri, 2 Dec 2011 16:06:39 -0800 (PST)
Subject: Request for Review: Warnings cleanup in java.lang.*, java.util.**
In-Reply-To: <4ED9042D.3000307@redhat.com>
References: <CAGVnyzRNvKDpSN-TuKRDg+ckKEZcQj-EfLUnt1Ayfse0PeDk6g@mail.gmail.com>
<4ED8C221.7070603@oracle.com 4ED9042D.3000307@redhat.com>
Message-ID: <c7fb40dd-5827-484f-88bc-5229ec48f8d8@default>
Omair / Danesh,
Here are the bug IDs:
7117605 Danesh
7117612 Omair
Wiki has been updated.
http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
-Xiomara
> -----Original Message-----
> From: Omair Majid [mailto:omajid at redhat.com]
> Sent: Friday, December 02, 2011 9:00 AM
> To: Alan Bateman
> Cc: jdk8-dev at openjdk.java.net; core-libs-dev
> Subject: Re: Request for Review: Warnings cleanup in java.lang.*,
> java.util.**
>
> Hi,
>
> On 12/02/2011 07:18 AM, Alan Bateman wrote:
> >
> > cc'ing core-libs-dev as that is the place to discuss these changes. I
> > see on the sign-up sheet [1] that omajid has signed up for java.lang,
> > maybe you are working together?
>
> Unfortunately, David and I were not working together :(
>
> Anyway, here is my webrev for java.lang.*
> http://cr.openjdk.java.net/~omajid/webrevs/warnings-day-2011/01/
>
> Sorry about the delay, building and testing this took longer than I had
> expected it to. Also, this patch only addresses the warnings pointed
> out by javac.
>
> The classes java.lang.ThreadLocal and java.lang.ClassValue are not
> included in the webrev. The fixes for ThreadLocal were basically
> sprinkling @SuppressWarnings("unchecked") throughout and the fixes for
> ClassValue looked slightly more complex when I tried to reduce the use
> of rawtypes. I will post a separate webrev for those later.
>
> Cheers,
> Omair
From john.r.rose at oracle.com Fri Dec 2 16:16:33 2011
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 2 Dec 2011 16:16:33 -0800
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED92DCE.3030108@oracle.com>
<CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
Message-ID: <A7D3CAED-1D38-4D3E-8855-CE3318DE327F@oracle.com>
On Dec 2, 2011, at 2:32 PM, Martijn Verburg wrote:
> I think the original patch provider (Prasanna) was aiming at simply
> removing the deprecation warning. Interesting point on the performance
> aspect!
Presently we are aiming at removing warnings with no changes to semantics (i.e., bytecodes).
I'll risk stating the obvious: If we have 900 warnings removals, and 30 of them remove warnings by changing code (to call a non-deprecated API element), and 1 of those 30 introduces a bug, we have put the 900 removals at risk, because we have made it much harder for the integrator to batch the warning changes.
So let's try to keep the deprecated call and suppress the deprecation. (There may be an exception, of course; that's when reviews help.)
And (this is equally important) comment the @SuppressWarnings() with the relevant information.
@SuppressWarnings("deprecation") // String(byte[],int) in String has been deprecated
// and this is actually useful because alskjdflsadkfjasl
String x = new String(new byte[0], 0);
Thanks!
-- John
From dl at cs.oswego.edu Fri Dec 2 16:30:46 2011
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 02 Dec 2011 19:30:46 -0500
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <A7D3CAED-1D38-4D3E-8855-CE3318DE327F@oracle.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com> <4ED92DCE.3030108@oracle.com> <CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
<A7D3CAED-1D38-4D3E-8855-CE3318DE327F@oracle.com>
Message-ID: <4ED96DB6.2060609@cs.oswego.edu>
On 12/02/11 19:16, John Rose wrote:
> Presently we are aiming at removing warnings with no changes to semantics
> (i.e., bytecodes).
Note that this is at odds with suggestions such as:
> java/util/Currency.java --
>
> The @SuppressWarnings covers the entire method. We're trying to use
> @SuppressWarnings with as narrow a scope as possible. Sometimes it's helpful to
> create a local variable declaration for this purpose; perhaps something like
> this will help:
>
> @SuppressedWarnings("unchecked")
> Set<Currency> result = (Set<Currency>) available.clone();
> return result;
This generates two more bytecodes and a local variable.
This won't matter when the code is actually JIT-compiled, but
the increased size might inhibit inlining or compilation.
Surely it doesn't matter in this class, but we are very careful
about these and many related issues in performance-sensitive
java.util.concurrent code.
Too bad you cannot place annotations on expressions.
Also too bad that javac doesn't do trivial optimizations.
-Doug
From mandy.chung at oracle.com Fri Dec 2 16:32:11 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 02 Dec 2011 16:32:11 -0800
Subject: Warnings cleanup in java.lang.instrument, java.lang.management
(late entry)
In-Reply-To: <98c306b7-3b68-42a1-8503-079e47cc7694@zmail13.collab.prod.int.phx2.redhat.com>
References: <98c306b7-3b68-42a1-8503-079e47cc7694@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4ED96E0B.7070809@oracle.com>
On 12/2/11 3:30 PM, Jon VanAlten wrote:
> For completeness, I've updated webrev:
> http://icedtea.classpath.org/~vanaltj/webrevs/javalangwarnings/
Thanks. Your changeset is pushed:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98502d7a3f98
Mandy
From xiomara.jayasena at oracle.com Fri Dec 2 16:45:54 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Fri, 2 Dec 2011 16:45:54 -0800 (PST)
Subject: Warning fixes in JDI
Message-ID: <82e56dd1-28a4-4cc9-a888-340c364ec82c@default>
FYI, Jim's web rev for his changes is here:
http://cr.openjdk.java.net/~jjh/7117053-FixSomeJDIWarnings/
and fixes about 300 warnings. His changes have already been partially reviewed and he is already got someone looking at the rest of this.
-Xiomara
From john.r.rose at oracle.com Fri Dec 2 16:49:58 2011
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 2 Dec 2011 16:49:58 -0800
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <4ED96DB6.2060609@cs.oswego.edu>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com> <4ED92DCE.3030108@oracle.com> <CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
<A7D3CAED-1D38-4D3E-8855-CE3318DE327F@oracle.com>
<4ED96DB6.2060609@cs.oswego.edu>
Message-ID: <4EBA5EF4-BFAB-4A3D-BD9E-C860CAA1231E@oracle.com>
On Dec 2, 2011, at 4:30 PM, Doug Lea wrote:
> On 12/02/11 19:16, John Rose wrote:
>
>> Presently we are aiming at removing warnings with no changes to semantics
>> (i.e., bytecodes).
>
> Note that this is at odds with suggestions such as:
>
>> java/util/Currency.java --
>>
>> The @SuppressWarnings covers the entire method. We're trying to use
>> @SuppressWarnings with as narrow a scope as possible. Sometimes it's helpful to
>> create a local variable declaration for this purpose; perhaps something like
>> this will help:
>>
>> @SuppressedWarnings("unchecked")
>> Set<Currency> result = (Set<Currency>) available.clone();
>> return result;
>
> This generates two more bytecodes and a local variable.
> This won't matter when the code is actually JIT-compiled, but
> the increased size might inhibit inlining or compilation.
> Surely it doesn't matter in this class, but we are very careful
> about these and many related issues in performance-sensitive
> java.util.concurrent code.
Good point; thanks.
Conflicting requirements are the spice of engineering life.
If you remove 900 warnings, there is a good chance of causing some sort of bug. ( http://blogs.oracle.com/jrose/entry/three_software_proverbs )
The 900 warnings may be masking other bugs, so we take the risk.
-- John
P.S.
> Too bad you cannot place annotations on expressions.
>
> Also too bad that javac doesn't do trivial optimizations.
I agree.
And, too bad that our (C2) inline heuristics are so rigid. I'm embarrassed that they count stupid stuff like unreached code (disabled asserts, throws) and data motion just as much as field and method uses. How long have we known about this...? The hard part about such a heuristic is that once entrenched it defends itself viciously, by taking all your benchmarks hostage.
From stuart.marks at oracle.com Fri Dec 2 17:41:13 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 02 Dec 2011 17:41:13 -0800
Subject: Review request for IMF classes and Locale related classes
In-Reply-To: <4ED966AA.2010701@oracle.com>
References: <4ED91F51.2020502@oracle.com> <4ED95018.3070808@oracle.com>
<4ED96005.3000709@oracle.com> <4ED966AA.2010701@oracle.com>
Message-ID: <4ED97E39.1050504@oracle.com>
The changes you made are good, thanks.
I did figure out how to deal with the static initializer in AllAvailableLocales:
@SuppressWarnings({"unchecked"})
Class<? extends LocaleServiceProvider>[] providerClasses =
(Class<? extends LocaleServiceProvider>[]) new Class<?>[] {
java.text.spi.BreakIteratorProvider.class,
...
};
This is a bit uglier but it does reduce the scope of warnings suppression.
I think you might be able to get rid of the wildcards, too:
@SuppressWarnings({"unchecked"})
Class<LocaleServiceProvider>[] providerClasses =
(Class<LocaleServiceProvider>[]) new Class<?>[] {
java.text.spi.BreakIteratorProvider.class,
...
};
...
for (Class<LocaleServiceProvider> providerClass : providerClasses) {
...
}
I'm not entirely sure why this works, but it seems to compile for me without
warnings or errors....
s'marks
On 12/2/11 4:00 PM, Naoto Sato wrote:
> Hi Stuart,
>
> Thank you for your comments. Here is the updated webrev reflecting your
> suggestions. Please review:
>
> http://cr.openjdk.java.net/~naoto/7117469/webrev.01/
>
> Naoto
>
>
> On 12/2/11 3:32 PM, Stuart Marks wrote:
>> Hi Naoto,
>>
>> A couple comments.
>>
>> java/util/Currency.java --
>>
>> The @SuppressWarnings covers the entire method. We're trying to use
>> @SuppressWarnings with as narrow a scope as possible. Sometimes it's
>> helpful to create a local variable declaration for this purpose; perhaps
>> something like this will help:
>>
>> @SuppressedWarnings("unchecked")
>> Set<Currency> result = (Set<Currency>) available.clone();
>> return result;
>>
>> You can probably do something similar in
>> sun/util/LocaleServiceProviderPool.java in the getLocalizedObjectImpl()
>> method.
>>
>> The suppression of warnings on the static AllAvailableLocales class is a
>> bit of a puzzle. Maybe it's OK to leave the suppression for that entire
>> class.
>>
>> s'marks
>>
>>
>> On 12/2/11 2:24 PM, Masayoshi Okutsu wrote:
>>> Looks good to me.
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 2011/12/02 10:56, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Could you please review these two changesets for the WCD? One is for
>>>> classes
>>>> that belongs to input method framework:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/7117465/webrev.00/
>>>>
>>>> and the other is for (some of the) i18n related *.util.* classes:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/7117469/webrev.00/
>>>>
>>>> Thanks!
>>>> Naoto
>
From xiomara.jayasena at oracle.com Fri Dec 2 18:15:56 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Fri, 2 Dec 2011 18:15:56 -0800 (PST)
Subject: OpenJDK Mailing Lists
Message-ID: <66f32caa-3f98-47f2-b28c-d47b46872889@default>
Hi,
This page contains a listing of the OpenJDK mailing list for each of the areas of development.
http://mail.openjdk.java.net/mailman/listinfo
There you will find instructions to subscribe.
-Xiomara
From stuart.marks at oracle.com Fri Dec 2 18:38:22 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 02 Dec 2011 18:38:22 -0800
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <4EBA5EF4-BFAB-4A3D-BD9E-C860CAA1231E@oracle.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com> <4ED92DCE.3030108@oracle.com> <CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
<A7D3CAED-1D38-4D3E-8855-CE3318DE327F@oracle.com>
<4ED96DB6.2060609@cs.oswego.edu>
<4EBA5EF4-BFAB-4A3D-BD9E-C860CAA1231E@oracle.com>
Message-ID: <4ED98B9E.2040101@oracle.com>
On 12/2/11 4:49 PM, John Rose wrote:
> On Dec 2, 2011, at 4:30 PM, Doug Lea wrote:
>> On 12/02/11 19:16, John Rose wrote:
>>> Presently we are aiming at removing warnings with no changes to semantics
>>> (i.e., bytecodes).
>>
>> Note that this is at odds with suggestions such as:
>>
>>> java/util/Currency.java --
>>>
>>> The @SuppressWarnings covers the entire method. We're trying to use
>>> @SuppressWarnings with as narrow a scope as possible. Sometimes it's helpful to
>>> create a local variable declaration for this purpose; perhaps something like
>>> this will help:
>>>
>>> @SuppressedWarnings("unchecked")
>>> Set<Currency> result = (Set<Currency>) available.clone();
>>> return result;
>>
>> This generates two more bytecodes and a local variable.
>> This won't matter when the code is actually JIT-compiled, but
>> the increased size might inhibit inlining or compilation.
>> Surely it doesn't matter in this class, but we are very careful
>> about these and many related issues in performance-sensitive
>> java.util.concurrent code.
>
> Good point; thanks.
>
> Conflicting requirements are the spice of engineering life.
>
> If you remove 900 warnings, there is a good chance of causing some sort of bug. ( http://blogs.oracle.com/jrose/entry/three_software_proverbs )
>
> The 900 warnings may be masking other bugs, so we take the risk.
I won't make a stand on warnings fixes not changing bytecodes. This is too
strict a requirement. As Doug pointed out (by quoting a message from me!) we
are indeed making changes that result in different bytecodes. It's interesting
to know that j.u.c is sensitive to bytecode changes, but most of the rest of
the class library isn't.
I do want to ensure that the warnings fixes don't make any semantic changes. It
should be possible to look at the source diff and determine that its semantics
are identical. We should avoid seemingly innocuous changes such as calling the
recommended replacement instead of a deprecated method, or upgrading to a newer
class such as from Date to Calendar. It's very difficult to prove anything
about such changes. John's admonition is sound here.
s'marks
From martijnverburg at gmail.com Sat Dec 3 02:34:43 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 3 Dec 2011 10:34:43 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <A7D3CAED-1D38-4D3E-8855-CE3318DE327F@oracle.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED92DCE.3030108@oracle.com>
<CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
<A7D3CAED-1D38-4D3E-8855-CE3318DE327F@oracle.com>
Message-ID: <CAP7YuAR89cJSASC0tPkyM=VNxGgE=C94_ebHon1H_1Zio7d01A@mail.gmail.com>
Hi John,
> Presently we are aiming at removing warnings with no changes to semantics
> (i.e., bytecodes).
>
> I'll risk stating the obvious: ?If we have 900 warnings removals, and 30 of
> them remove warnings by changing code (to call a non-deprecated API
> element), and 1 of those 30 introduces a bug, we have put the 900 removals
> at risk, because we have made it much harder for the integrator to batch the
> warning changes.
>
> So let's try to keep the deprecated call and suppress the deprecation.
> ?(There may be an exception, of course; that's when reviews help.)
>
> And (this is equally important) comment the @SuppressWarnings() with the
> relevant information.
>
> ? ? ? ? @SuppressWarnings("deprecation") ?//?String(byte[],int) in String
> has been deprecated
> ? ? ? ? // and this is actually useful because alskjdflsadkfjasl
> ? ? ? ??String x = new String(new byte[0], 0);
That's definitely the conclusion I've come to as well, especially
since the scope of this exercise is to remove warnings without any
possible side effects. I'm going to assume that one day in the future
there will be a sweep of @SuppressWarnings and this can be looked at
again then.
I'll re-spin a patch and pass that through Mike (my OCA should come
through soon).
Cheers,
Martijn
From martijnverburg at gmail.com Sat Dec 3 02:37:47 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 3 Dec 2011 10:37:47 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <4ED95CAB.3030505@oracle.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED92DCE.3030108@oracle.com>
<CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
<4ED95CAB.3030505@oracle.com>
Message-ID: <CAP7YuATwQXTDDytBH23KgMuC8SNv0gtNWjeHsc8fn+dk9Dz=YA@mail.gmail.com>
Hi Sherman,
Thanks for sending that through - very interesting. I'll let Prasanna
know as well, especially with regards to the performance and GC
implications, I'm kicking myself for not having picked up on at least
on of those when reviewing :(.
I'll re-spin a patch (adding a @SuppressWarnings with a comment) and
get it sent through Mike Barker.
Cheers,
Martijn
> Hi Martijn,
>
> No, I don't think we have a benchmark test case anywhere in OpenJDK to
> measure this performance. I happened to take a quick look at the
> "calculation cost" of dosToJavaTime() last month when working on that
> jar n-thread performance issue.
>
> Here is a the result of a quick/dirty "non-benchmark" benchmark test case,
> which suggests the proposed change is way too slow, this is only from the
> "speed" angle,
>
> I would assume it probably also consumes more temporary (young-gen) memory.
> So, the suggested approach appears not to be a good candidate to go in
> without further tuning.
>
> sherman at sherman-linux:~/Workspace/test$ java -server JavaDosTime
> j2dt? :386
> j2dt2 :1282
> d2jt? :424
> d2jt2 :1296
> sherman at sherman-linux:~/Workspace/test$ java -client JavaDosTime
> j2dt? :621
> j2dt2 :1901
> d2jt? :662
> d2jt2 :2016
>
> public class JavaDosTime {
>
> ??? public static void main(String[] args) throws IOException {
>
> ??????? long tt0 = System.currentTimeMillis();
> ??????? int ii = 0;
> ??????? for (ii = 0; ii < 1000000; ii++) {
> ??????????? long t = 10000 + ii;
> ??????????? t= javaToDosTime(t);
> ??????? }
> ??????? long tt1 = System.currentTimeMillis();
> ??????? System.out.println("j2dt? :" + (tt1 - tt0));
>
>
> ??????? tt0 = System.currentTimeMillis();
> ??????? ii = 0;
> ??????? for (ii = 0; ii < 1000000; ii++) {
> ??????????? long t = 10000 + ii;
> ??????????? t= javaToDosTime2(t);
> ??????? }
> ??????? tt1 = System.currentTimeMillis();
> ??????? System.out.println("j2dt2 :" + (tt1 - tt0));
>
>
> ??????? tt0 = System.currentTimeMillis();
> ??????? ii = 0;
> ??????? for (ii = 0; ii < 1000000; ii++) {
> ??????????? long t = 10000 + ii;
> ??????????? t= dosToJavaTime(t);
> ??????? }
> ??????? tt1 = System.currentTimeMillis();
> ??????? System.out.println("d2jt? :" + (tt1 - tt0));
>
>
> ??????? tt0 = System.currentTimeMillis();
> ??????? ii = 0;
> ??????? for (ii = 0; ii < 1000000; ii++) {
> ??????????? long t = 10000 + ii;
> ??????????? t= dosToJavaTime2(t);
> ??????? }
> ??????? tt1 = System.currentTimeMillis();
> ??????? System.out.println("d2jt2 :" + (tt1 - tt0));
>
> ??? }
>
> ??? private static long javaToDosTime(long time){
> ??????? Date d = new Date(time);
> ??????? int year = d.getYear() + 1900;
> ??????? if (year < 1980) {
> ??????????? return (1 << 21) | (1 << 16);
> ??????? }
> ??????? return (year - 1980) << 25 | (d.getMonth() + 1) << 21 |
> ?????????????? d.getDate() << 16 | d.getHours() << 11 | d.getMinutes() << 5
> |
> ?????????????? d.getSeconds() >> 1;
> ??? }
>
> ??? private static long javaToDosTime2(long time){
> ??????? Calendar cal = Calendar.getInstance();
> ??????? cal.setTimeInMillis(time);
> ??????? int year = cal.get(Calendar.YEAR);
> ??????? if (year < 1980) {
> ??????????? return (1 << 21) | (1 << 16);
> ??????? }
> ??????? int month = cal.get(Calendar.MONTH) + 1;
> ??????? return (year - 1980) << 25
> ??????????????? | month << 21
> ??????????????? | cal.get(Calendar.DAY_OF_MONTH) << 16
> ??????????????? | cal.get(Calendar.HOUR_OF_DAY) << 11
> ??????????????? | cal.get(Calendar.MINUTE) << 5
> ??????????????? | cal.get(Calendar.SECOND) >> 1;
> ???? }
>
> ???? private static long dosToJavaTime(long dtime) {
> ??????? Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
> ????????????????????????? (int)(((dtime >> 21) & 0x0f) - 1),
> ????????????????????????? (int)((dtime >> 16) & 0x1f),
> ????????????????????????? (int)((dtime >> 11) & 0x1f),
> ????????????????????????? (int)((dtime >> 5) & 0x3f),
> ????????????????????????? (int)((dtime << 1) & 0x3e));
> ??????? return d.getTime();
> ???? }
>
> ???? private static long dosToJavaTime2(long dtime) {
> ??? ?Calendar cal = Calendar.getInstance();
> ??? ?cal.set(Calendar.YEAR, (int) ((dtime >> 25) & 0x7f) + 1980);
> ??? ?cal.set(Calendar.MONTH, (int) ((dtime >> 21) & 0x0f) - 1);
> ??? ?cal.set(Calendar.DATE, (int) (dtime >> 16) & 0x1f);
> ??? ?cal.set(Calendar.HOUR_OF_DAY, (int) (dtime >> 11) & 0x1f);
> ??? ?cal.set(Calendar.MINUTE, (int) (dtime >> 5) & 0x3f);
> ??? ?cal.set(Calendar.SECOND, (int) (dtime << 1) & 0x3e);
> ???????? return cal.getTimeInMillis();
>
> ???? }
> }
From Alan.Bateman at oracle.com Sat Dec 3 03:03:06 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 03 Dec 2011 11:03:06 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <4EBA5EF4-BFAB-4A3D-BD9E-C860CAA1231E@oracle.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com> <4ED92DCE.3030108@oracle.com> <CAP7YuAT6mrTtvf0OtpOnspsAKNAvsSohR1JtBoLRW08iWz1UXQ@mail.gmail.com>
<A7D3CAED-1D38-4D3E-8855-CE3318DE327F@oracle.com>
<4ED96DB6.2060609@cs.oswego.edu>
<4EBA5EF4-BFAB-4A3D-BD9E-C860CAA1231E@oracle.com>
Message-ID: <4EDA01EA.1090209@oracle.com>
On 03/12/2011 00:49, John Rose wrote:
> :
>
> If you remove 900 warnings, there is a good chance of causing some sort of bug. ( http://blogs.oracle.com/jrose/entry/three_software_proverbs )
>
> The 900 warnings may be masking other bugs, so we take the risk.
>
Alexandre (Sasha) Boulgakov spent his summer internship in Oracle this
year working on javac warnings in the jdk repository. He contributed
changes that whacked about 2800 warnings, mostly in the security
classes, areas around the core libraries, and tools used in the build.
Off-hand, I can only think of one bug that surfaced a bit later so full
credit to Sasha and the reviewers/sponsors of his changes. I guess part
of the reason is that a significant bulk of the changes (esp. the raw
types warnings) didn't change the generated code. That plus if we if are
careful with the reviews and run the tests for the area then I would
hope that the current effort won't introduce issues either. On the
other hand, if we were tackling the native code warnings then it would
be a different story.
-Alan.
From martijnverburg at gmail.com Sat Dec 3 03:05:23 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 3 Dec 2011 11:05:23 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <4ED96250.4080708@oracle.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED9295C.1080705@univ-mlv.fr>
<CAP7YuAQuEBFuvL8+hsw48wn_vsTYppDdAs23ofK-TBzZ2UG5Yg@mail.gmail.com>
<CAP7YuASCthRPC1M_ndJ=iRW_HKM41zLqaf+oCnv4Vs-4sOWy9w@mail.gmail.com>
<4ED96250.4080708@oracle.com>
Message-ID: <CAP7YuAQ0d+RO+QkX6UUPaBBb07hb1YowS_G_JN6PETyVwVkyfA@mail.gmail.com>
Hi Sherman,
In order to keep this change within the scope of the intentions of the
exercise I'm going to revert that section to what it was (I'll re-spin a
patch). At this stage I won't add a @SuppressWarnings as I think this
should be avoidable once it's looked at again in a little more depth.
The rest follows in-line. If this is starting to chew up your time then
please don't feel obliged to answer, this is more for my own curiosities
sake. This also isn't a suggestion to change the patch again, just
theorising here :-)
On Friday, 2 December 2011, Xueming Shen <xueming.shen at oracle.com> wrote:
> Martijn,
>
> The proposed change is incorrect.
>
> + value = new String(vb, 0, 0, StandardCharsets.UTF_8);
>
> First, shouldn't it at least be
>
> value = new String(vb, StandardCharsets.UTF_8);
>
> or
>
> value = new String(vb, 0, vb.length, StandardCharsets.UTF_8);
>
> Second, the "value" will be written out via dos.writeBytes(String) later,
which
> only takes the low-byte of a each char of the target String object.
Right, so the need for the hi-byte constructor can be avoided, but by me
ignoring the vb.length I introduced a bug, gotcha.
So the code was:
String value = e.getKey();
if (value != null) {
byte[] vb = value.getBytes("utf8");
value = new String(vb, 0, 0, vb.length);
}
My proposed (bad) change was:
String value = e.getKey();
if (value != null) {
byte[] vb = value.getBytes(StandardCharsets.UTF_8);
value = new String(vb, 0, 0, StandardCharsets.UTF_8);
}
As you say, a better change would have been:
String value = e.getKey();
if (value != null) {
byte[] vb = value.getBytes(StandardCharsets.UTF_8);
value = new String(vb, 0, vb.length, StandardCharsets.UTF_8);
}
Or in a more performing manner:
String value = e.getKey();
if (value != null) {
// As at jdk8 build X - we don't use StandardCharsets.UTF_8 in getBytes
for performance reasons
byte[] vb = value.getBytes("utf8");
value = new String(vb, 0, vb.length, StandardCharsets.UTF_8);
}
> That "not properly" conversion is actually what we need here to make sure
the
> output will be correctly in utf8. The only "reliable" replacement might
be to use
> "iso8859-1" (not utf_8), but I would recommend keep it un-touched.
Fair enough.
Thanks for clearing that up and apologies for causing pain :(
Cheers,
Martijn
From martijnverburg at gmail.com Sat Dec 3 03:27:54 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 3 Dec 2011 11:27:54 +0000
Subject: Tests (Was Warnings Cleanup in java.util.<various> (more from hack
day))
Message-ID: <CAP7YuASf+6mzmikMv7ki=+gTY_7ZpBiSj7F+zC=sDYukx16RUg@mail.gmail.com>
Hi all,
So the recent warnings clean up exercise got me thinking about the
approach we took and how we could make it safer by applying/running
tests in some of these areas. I'm very new to the OpenJDK, but I
figure there must be a suite of tests (for the TCK if nothing else).
Is that the set of tests that are typically run? Or is there another
test suite that can be run/added to?
For example I feel that could/should have written a unit test for the
write method in the Manifest class that I had my recent brain melt in
:-)
Thoughts?
Cheers,
Martijn
From neugens.limasoftware at gmail.com Sat Dec 3 03:34:55 2011
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Sat, 3 Dec 2011 12:34:55 +0100
Subject: Tests (Was Warnings Cleanup in java.util.<various> (more from
hack day))
In-Reply-To: <CAP7YuASf+6mzmikMv7ki=+gTY_7ZpBiSj7F+zC=sDYukx16RUg@mail.gmail.com>
References: <CAP7YuASf+6mzmikMv7ki=+gTY_7ZpBiSj7F+zC=sDYukx16RUg@mail.gmail.com>
Message-ID: <371A8A7B-CE31-4D93-85CF-BBCA8AEFBDD5@gmail.com>
Il giorno 03/dic/2011, alle ore 12:27, Martijn Verburg ha scritto:
> Hi all,
>
> So the recent warnings clean up exercise got me thinking about the
> approach we took and how we could make it safer by applying/running
> tests in some of these areas. I'm very new to the OpenJDK, but I
> figure there must be a suite of tests (for the TCK if nothing else).
> Is that the set of tests that are typically run? Or is there another
> test suite that can be run/added to?
>
> For example I feel that could/should have written a unit test for the
> write method in the Manifest class that I had my recent brain melt in
> :-)
>
> Thoughts?
>
> Cheers,
> Martijn
Of course, you can write jtreg tests :)
The warning fixes were low risk changes (this is why everyone
was very picky about changing anything but the warnings) and
in many areas the JDK is well tested, so there was no real
reason to write tests for most of it, but this is not generally
true of course. So, to answer your question, yes, you can write
a jtreg test and propose it as companion to your code changes,
this is never a bad idea anyway, just double check that the test
you're going to write doesn't exist already (so you add more, rather
than duplicating it).
Cheers,
Mario
---
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
http://www.ladybug-studio.com
IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/
Please, support open standards:
http://endsoftpatents.org/
From martijnverburg at gmail.com Sat Dec 3 03:39:58 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 3 Dec 2011 11:39:58 +0000
Subject: Tests (Was Warnings Cleanup in java.util.<various> (more from
hack day))
In-Reply-To: <371A8A7B-CE31-4D93-85CF-BBCA8AEFBDD5@gmail.com>
References: <CAP7YuASf+6mzmikMv7ki=+gTY_7ZpBiSj7F+zC=sDYukx16RUg@mail.gmail.com>
<371A8A7B-CE31-4D93-85CF-BBCA8AEFBDD5@gmail.com>
Message-ID: <CAP7YuARNPk6Zajyfg=u1aAQ-hRQeLXzw-DqpjTH9cPEs-OiZWw@mail.gmail.com>
> On 3 December 2011 11:34, Mario Torre <neugens.limasoftware at gmail.com> wrote:
> Il giorno 03/dic/2011, alle ore 12:27, Martijn Verburg ha scritto:
>> Hi all,
>>
>> So the recent warnings clean up exercise got me thinking about the
>> approach we took and how we could make it safer by applying/running
>> tests in some of these areas. I'm very new to the OpenJDK, but I
>> figure there must be a suite of tests (for the TCK if nothing else).
>> Is that the set of tests that are typically run? Or is there another
>> test suite that can be run/added to?
>>
>> For example I feel that could/should have written a unit test for the
>> write method in the Manifest class that I had my recent brain melt in
>> :-)
>>
>> Thoughts?
>>
>> Cheers,
>> Martijn
>
>
> Of course, you can write jtreg tests :)
>
> The warning fixes were low risk changes (this is why everyone
> was very picky about changing anything but the warnings) and
> in many areas the JDK is well tested, so there was no real
> reason to write tests for most of it, but this is not generally
> true of course. So, to answer your question, yes, you can write
> a jtreg test and propose it as companion to your code changes,
> this is never a bad idea anyway, just double check that the test
> you're going to write doesn't exist already (so you add more, rather
> than duplicating it).
>
> Cheers,
> Mario
Hi Mario,
Thanks for that - I'll look up how to write/run jtreg tests -
should've figured there was something like that in the first place, a
well you live and learn :-)
Cheers,
Martijn
From forax at univ-mlv.fr Sat Dec 3 04:37:17 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 03 Dec 2011 13:37:17 +0100
Subject: Collections.enumeration() WAS Warning Cleanup Day
Message-ID: <4EDA17FD.6060505@univ-mlv.fr>
I've started to remove warnings from java.util
and I'm not able to cleanly retrofit java.util.PropertyPermission
because java.util.Collections.enumeration is wrongly typed.
PropertyPermission contains a member class that define
a PermissionCollection that store/load only PropertyPermissions.
One method of PermissionCollection returns an Enumeration
of Permission by calling Collections.enumeration.
But Collections.enumeration doesn't use a wildcard.
This is the actual code of Collections.enumeration is
public static <T> Enumeration<T> enumeration(final Collection<T> c) {
return new Enumeration<T>() {
private final Iterator<T> i = c.iterator();
public boolean hasMoreElements() {
return i.hasNext();
}
public T nextElement() {
return i.next();
}
};
}
and should be:
public static <T> Enumeration<T> enumeration(final Collection<? extends
T> c) {
final Iterator<? extends T> i = c.iterator();
return new Enumeration<T>() {
public boolean hasMoreElements() {
return i.hasNext();
}
public T nextElement() {
return i.next();
}
};
}
I believe this change is source and binary compatible because the method
is static and a Collection<? extends T> is a super type of Collection<T>.
R?mi
From forax at univ-mlv.fr Sat Dec 3 04:54:48 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 03 Dec 2011 13:54:48 +0100
Subject: PropertyResourceBundle WAS Warning Cleanup Day
Message-ID: <4EDA1C18.30205@univ-mlv.fr>
The two constructor of PropertyResourceBundle are unsafe
because they use a Properties which is a HashTable<Object,Object>
to populate a Map<String,Object>.
The way to fix that is to change Properties.load0
to be static and package visible and take a Map<? super String, ? super
String>
as parameter in order to call it from the constructors
of PropertyResourceBundle.
Because it's a bytecode change, I will not remove the warning from
PropertyResourceBundle.
If someone can create a bug for that :)
cheers,
R?mi
From mikeb01 at gmail.com Sat Dec 3 05:03:32 2011
From: mikeb01 at gmail.com (Michael Barker)
Date: Sat, 3 Dec 2011 13:03:32 +0000
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <CAP7YuAQ0d+RO+QkX6UUPaBBb07hb1YowS_G_JN6PETyVwVkyfA@mail.gmail.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED9295C.1080705@univ-mlv.fr>
<CAP7YuAQuEBFuvL8+hsw48wn_vsTYppDdAs23ofK-TBzZ2UG5Yg@mail.gmail.com>
<CAP7YuASCthRPC1M_ndJ=iRW_HKM41zLqaf+oCnv4Vs-4sOWy9w@mail.gmail.com>
<4ED96250.4080708@oracle.com>
<CAP7YuAQ0d+RO+QkX6UUPaBBb07hb1YowS_G_JN6PETyVwVkyfA@mail.gmail.com>
Message-ID: <CALwNKeSh898aruYTJNHpdgnmxxfbQaGm4THxr03h+=3kcTV4HA@mail.gmail.com>
Hi,
After some further review from the list and Martijn attached are
updated patches for Manifest.java and ZipEntry.java. The unnecessary
import and the UTF8 changes are removed. The ZipEntry now uses a
SuppressWarnings with a comment regarding the use of j.u.Calendar as
an alternative.
Apologies for the numerous round trips on this code. Thank you to all
that reviewed and commented on the code and general style/process.
This is a bit of a learning experience for us (LJC). It will make
further hack days much easier as we can better guide development and
review patches before sending them in.
Mike.
On Sat, Dec 3, 2011 at 11:05 AM, Martijn Verburg
<martijnverburg at gmail.com> wrote:
> Hi Sherman,
>
> In order to keep this change within the scope of the intentions of the
> exercise I'm going to revert that section to what it was (I'll re-spin a
> patch). ?At this stage I won't add a @SuppressWarnings as I think this
> should be avoidable once it's looked at again in a little more depth.
>
> The rest follows in-line. ?If this is starting to chew up your time then
> please don't feel obliged to answer, this is more for my own curiosities
> sake. ?This also isn't a suggestion to change the patch again, just
> theorising here :-)
>
> On Friday, 2 December 2011, Xueming Shen <xueming.shen at oracle.com> wrote:
>> Martijn,
>>
>> The proposed change is incorrect.
>>
>> + ?value = new String(vb, 0, 0, StandardCharsets.UTF_8);
>>
>> First, shouldn't it at least be
>>
>> value = new String(vb, StandardCharsets.UTF_8);
>>
>> ?or
>>
>> value = new String(vb, 0, vb.length, StandardCharsets.UTF_8);
>>
>> Second, the "value" will be written out via dos.writeBytes(String) later,
> which
>> only takes the low-byte of a each char of the target String object.
>
> Right, so the need for the hi-byte constructor can be avoided, but by me
> ignoring the vb.length I introduced a bug, gotcha.
>
> So the code was:
>
> String value = e.getKey();
> if (value != null) {
> ? ?byte[] vb = value.getBytes("utf8");
> ? ?value = new String(vb, 0, 0, vb.length);
> }
>
> My proposed (bad) change was:
>
> String value = e.getKey();
> if (value != null) {
> ? ?byte[] vb = value.getBytes(StandardCharsets.UTF_8);
> ? ?value = new String(vb, 0, 0, StandardCharsets.UTF_8);
> }
>
> As you say, a better change would have been:
>
> String value = e.getKey();
> if (value != null) {
> ? ?byte[] vb = value.getBytes(StandardCharsets.UTF_8);
> ? ?value = new String(vb, 0, vb.length, StandardCharsets.UTF_8);
> }
>
> Or in a more performing manner:
>
> String value = e.getKey();
> if (value != null) {
> ? ?// As at jdk8 build X - we don't use StandardCharsets.UTF_8 in getBytes
> for performance reasons
> ? ?byte[] vb = value.getBytes("utf8");
> ? ?value = new String(vb, 0, vb.length, StandardCharsets.UTF_8);
> }
>
>> That "not properly" conversion is actually what we need here to make sure
> the
>> output will be correctly in utf8. The only "reliable" replacement might
> be to use
>> "iso8859-1" (not utf_8), but I would recommend keep it un-touched.
>
> Fair enough.
>
> Thanks for clearing that up and apologies for causing pain :(
>
> Cheers,
> Martijn
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/jar/Manifest.java
--- a/src/share/classes/java/util/jar/Manifest.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/jar/Manifest.java Sat Dec 03 12:53:27 2011 +0000
@@ -51,7 +51,7 @@
private Attributes attr = new Attributes();
// manifest entries
- private Map entries = new HashMap();
+ private Map<String, Attributes> entries = new HashMap<>();
/**
* Constructs a new, empty Manifest.
@@ -148,11 +148,11 @@
// Write out the main attributes for the manifest
attr.writeMain(dos);
// Now write out the pre-entry attributes
- Iterator it = entries.entrySet().iterator();
+ Iterator<Map.Entry<String, Attributes>> it = entries.entrySet().iterator();
while (it.hasNext()) {
- Map.Entry e = (Map.Entry)it.next();
+ Map.Entry<String, Attributes> e = it.next();
StringBuffer buffer = new StringBuffer("Name: ");
- String value = (String)e.getKey();
+ String value = e.getKey();
if (value != null) {
byte[] vb = value.getBytes("UTF8");
value = new String(vb, 0, 0, vb.length);
@@ -161,7 +161,7 @@
buffer.append("\r\n");
make72Safe(buffer);
dos.writeBytes(buffer.toString());
- ((Attributes)e.getValue()).write(dos);
+ e.getValue().write(dos);
}
dos.flush();
}
-------------- next part --------------
diff -r 43a630f11af6 src/share/classes/java/util/zip/ZipEntry.java
--- a/src/share/classes/java/util/zip/ZipEntry.java Wed Nov 30 13:11:16 2011 -0800
+++ b/src/share/classes/java/util/zip/ZipEntry.java Sat Dec 03 12:55:05 2011 +0000
@@ -281,6 +281,8 @@
* Converts DOS time to Java time (number of milliseconds since epoch).
*/
private static long dosToJavaTime(long dtime) {
+ @SuppressWarnings("deprecation") // Changing to j.u.Calendar would have an
+ // unknown impact on performance/gc.
Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
(int)(((dtime >> 21) & 0x0f) - 1),
(int)((dtime >> 16) & 0x1f),
@@ -293,6 +295,8 @@
/*
* Converts Java time to DOS time.
*/
+ @SuppressWarnings("deprecation") // Changing to j.u.Calendar would have an
+ // unknown impact on performance/gc.
private static long javaToDosTime(long time) {
Date d = new Date(time);
int year = d.getYear() + 1900;
From forax at univ-mlv.fr Sat Dec 3 06:15:41 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 03 Dec 2011 15:15:41 +0100
Subject: WeakHashMap.put WAS Warning Cleanup Day
Message-ID: <4EDA2F0D.6030308@univ-mlv.fr>
WeakHashMap.put() can be optimized a bit
because tab[i] is read twice if the key is not in the map.
If someone can create a bug for that ...
I will provide a patch.
R?mi
From Alan.Bateman at oracle.com Sat Dec 3 06:33:02 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 03 Dec 2011 14:33:02 +0000
Subject: Collections.enumeration() WAS Warning Cleanup Day
In-Reply-To: <4EDA17FD.6060505@univ-mlv.fr>
References: <4EDA17FD.6060505@univ-mlv.fr>
Message-ID: <4EDA331E.6040800@oracle.com>
On 03/12/2011 12:37, R?mi Forax wrote:
> I've started to remove warnings from java.util
> and I'm not able to cleanly retrofit java.util.PropertyPermission
> because java.util.Collections.enumeration is wrongly typed.
>
R?mi - you might want to sync up with Mike Duigou as I believe he has
been working on the java.util area including collections. Also best to
move any discussions on collections/util area to core-libs-dev too.
-Alan
From forax at univ-mlv.fr Sat Dec 3 07:12:28 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 03 Dec 2011 16:12:28 +0100
Subject: Collections.enumeration() WAS Warning Cleanup Day
In-Reply-To: <4EDA331E.6040800@oracle.com>
References: <4EDA17FD.6060505@univ-mlv.fr> <4EDA331E.6040800@oracle.com>
Message-ID: <4EDA3C5C.6070404@univ-mlv.fr>
On 12/03/2011 03:33 PM, Alan Bateman wrote:
> On 03/12/2011 12:37, R?mi Forax wrote:
>> I've started to remove warnings from java.util
>> and I'm not able to cleanly retrofit java.util.PropertyPermission
>> because java.util.Collections.enumeration is wrongly typed.
>>
> R?mi - you might want to sync up with Mike Duigou as I believe he has
> been working on the java.util area including collections. Also best to
> move any discussions on collections/util area to core-libs-dev too.
>
> -Alan
too late :)
Here is a webrev that remove most of the unchecked cast/raw generics
warnings
http://cr.openjdk.java.net/~forax/WarningDay1/webrev/
R?mi
From Alan.Bateman at oracle.com Sat Dec 3 07:36:36 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 03 Dec 2011 15:36:36 +0000
Subject: Tests (Was Warnings Cleanup in java.util.<various> (more from
hack day))
In-Reply-To: <CAP7YuASf+6mzmikMv7ki=+gTY_7ZpBiSj7F+zC=sDYukx16RUg@mail.gmail.com>
References: <CAP7YuASf+6mzmikMv7ki=+gTY_7ZpBiSj7F+zC=sDYukx16RUg@mail.gmail.com>
Message-ID: <4EDA4204.2080108@oracle.com>
On 03/12/2011 11:27, Martijn Verburg wrote:
> Hi all,
>
> So the recent warnings clean up exercise got me thinking about the
> approach we took and how we could make it safer by applying/running
> tests in some of these areas. I'm very new to the OpenJDK, but I
> figure there must be a suite of tests (for the TCK if nothing else).
> Is that the set of tests that are typically run? Or is there another
> test suite that can be run/added to?
>
> For example I feel that could/should have written a unit test for the
> write method in the Manifest class that I had my recent brain melt in
> :-)
>
There are lots of tests in the jdk repository (lots in langtools and
some tests in the hotspot repository too). In order to run them then
you'll need the jtreg test harness [1]. We probably need better
documentation on the OpenJDK site for how to run the tests but one
useful thing to know is that the make file in jdk/test directory has
make targets that run the tests for many areas of the libraries. In this
case you are working on java.util classes and we have a jdk_util target
in the make file that runs the tests in jdk/test/java/util/**. You can
run them with:
make JT_HOME=<jtreg-location> jdk_util
This locates your build in the default output directory so if it's
somewhere else when you'll need to specify PRODUCT_HOME=<myjdk> to point
it to the JDK that you are testing.
It's possible that your sponsor (maybe Sherman in this case) will run
the tests before pushing the changes but we need to get more people used
to running the tests too.
-Alan.
[1] http://openjdk.java.net/jtreg/
From mike.duigou at oracle.com Sat Dec 3 08:21:00 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Sat, 3 Dec 2011 08:21:00 -0800
Subject: Collections.enumeration() WAS Warning Cleanup Day
In-Reply-To: <4EDA3C5C.6070404@univ-mlv.fr>
References: <4EDA17FD.6060505@univ-mlv.fr> <4EDA331E.6040800@oracle.com>
<4EDA3C5C.6070404@univ-mlv.fr>
Message-ID: <D26F01DE-1B85-490B-A6D8-622A77A9CE76@oracle.com>
On Dec 3 2011, at 07:12 , R?mi Forax wrote:
> On 12/03/2011 03:33 PM, Alan Bateman wrote:
>> On 03/12/2011 12:37, R?mi Forax wrote:
>>> I've started to remove warnings from java.util
>>> and I'm not able to cleanly retrofit java.util.PropertyPermission
>>> because java.util.Collections.enumeration is wrongly typed.
>>>
>> R?mi - you might want to sync up with Mike Duigou as I believe he has been working on the java.util area including collections. Also best to move any discussions on collections/util area to core-libs-dev too.
>>
>> -Alan
>
> too late :)
>
> Here is a webrev that remove most of the unchecked cast/raw generics warnings
> http://cr.openjdk.java.net/~forax/WarningDay1/webrev/
>
> R?mi
>
I have changes in about 15 files. I will compare them against yours. I actually believe that doing the same work independently and then comparing the results is a stronger validation than inspection review.
Thanks for submitting these fixes.
Mike
From martijnverburg at gmail.com Sat Dec 3 08:35:17 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 3 Dec 2011 16:35:17 +0000
Subject: Tests (Was Warnings Cleanup in java.util.<various> (more from
hack day))
In-Reply-To: <4EDA4204.2080108@oracle.com>
References: <CAP7YuASf+6mzmikMv7ki=+gTY_7ZpBiSj7F+zC=sDYukx16RUg@mail.gmail.com>
<4EDA4204.2080108@oracle.com>
Message-ID: <CAP7YuAQgdRG0Yf=4X8nz=7p95qFxveXOKo-tyGQ0Mhbs8XB0Vg@mail.gmail.com>
On 3 December 2011 15:36, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 03/12/2011 11:27, Martijn Verburg wrote:
>>
>> Hi all,
>>
>> So the recent warnings clean up exercise got me thinking about the
>> approach we took and how we could make it safer by applying/running
>> tests in some of these areas. I'm very new to the OpenJDK, but I
>> figure there must be a suite of tests (for the TCK if nothing else).
>> Is that the set of tests that are typically run? Or is there another
>> test suite that can be run/added to?
>>
>> For example I feel that could/should have written a unit test for the
>> write method in the Manifest class that I had my recent brain melt in
>> :-)
>>
> There are lots of tests in the jdk repository (lots in langtools and some
> tests in the hotspot repository too). In order to run them then you'll need
> the jtreg test harness [1]. We probably need better documentation on the
> OpenJDK site for how to run the tests but one useful thing to know is that
> the make file in jdk/test directory has make targets that run the tests for
> many areas of the libraries. In this case you are working on java.util
> classes and we have a jdk_util target in the make file that runs the tests
> in jdk/test/java/util/**. You can run them with:
>
> make JT_HOME=<jtreg-location> jdk_util
>
> This locates your build in the default output directory so if it's somewhere
> else when you'll need to specify PRODUCT_HOME=<myjdk> to point it to the JDK
> that you are testing.
>
> It's possible that your sponsor (maybe Sherman in this case) will run the
> tests before pushing the changes but we need to get more people used to
> running the tests too.
>
> -Alan.
>
> [1] http://openjdk.java.net/jtreg/
Thanks for the extra details, this is great stuff!
I think this is the sort of useful thing that the JUG community can
help with. That is, go through these sorts of steps and get them
documented in the right place on the OpenJDK wiki. I've got another
thread running with Dalibor about improving the OpenJDK site/wiki, so
this can be part of that effort.
I'll sit down tomorrow and go through the steps.
Thanks again,
Martijn
From forax at univ-mlv.fr Sat Dec 3 11:37:13 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 03 Dec 2011 20:37:13 +0100
Subject: Collections.enumeration() WAS Warning Cleanup Day
In-Reply-To: <D26F01DE-1B85-490B-A6D8-622A77A9CE76@oracle.com>
References: <4EDA17FD.6060505@univ-mlv.fr> <4EDA331E.6040800@oracle.com>
<4EDA3C5C.6070404@univ-mlv.fr>
<D26F01DE-1B85-490B-A6D8-622A77A9CE76@oracle.com>
Message-ID: <4EDA7A69.1040109@univ-mlv.fr>
On 12/03/2011 05:21 PM, Mike Duigou wrote:
> On Dec 3 2011, at 07:12 , R?mi Forax wrote:
>
>> On 12/03/2011 03:33 PM, Alan Bateman wrote:
>>> On 03/12/2011 12:37, R?mi Forax wrote:
>>>> I've started to remove warnings from java.util
>>>> and I'm not able to cleanly retrofit java.util.PropertyPermission
>>>> because java.util.Collections.enumeration is wrongly typed.
>>>>
>>> R?mi - you might want to sync up with Mike Duigou as I believe he has been working on the java.util area including collections. Also best to move any discussions on collections/util area to core-libs-dev too.
>>>
>>> -Alan
>> too late :)
>>
>> Here is a webrev that remove most of the unchecked cast/raw generics warnings
>> http://cr.openjdk.java.net/~forax/WarningDay1/webrev/
>>
>> R?mi
>>
> I have changes in about 15 files. I will compare them against yours. I actually believe that doing the same work independently and then comparing the results is a stronger validation than inspection review.
yes.
>
> Thanks for submitting these fixes.
>
> Mike
Mike, there is a raw type I was not able to remove in Collections line 1408,
I understand the problem but was not able to come with a solution.
The current fix is not good because it equivalent to say f*** you
wildcards !
R?mi
From john.r.rose at oracle.com Sat Dec 3 13:44:55 2011
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 3 Dec 2011 13:44:55 -0800
Subject: Warnings Cleanup in java.util.<various> (more from hack day)
In-Reply-To: <CALwNKeSh898aruYTJNHpdgnmxxfbQaGm4THxr03h+=3kcTV4HA@mail.gmail.com>
References: <CALwNKeS+pc3dUbyEaJagkSG0R2O57jLigBrA+4p7G0NqwTqLww@mail.gmail.com>
<4ED9295C.1080705@univ-mlv.fr>
<CAP7YuAQuEBFuvL8+hsw48wn_vsTYppDdAs23ofK-TBzZ2UG5Yg@mail.gmail.com>
<CAP7YuASCthRPC1M_ndJ=iRW_HKM41zLqaf+oCnv4Vs-4sOWy9w@mail.gmail.com>
<4ED96250.4080708@oracle.com>
<CAP7YuAQ0d+RO+QkX6UUPaBBb07hb1YowS_G_JN6PETyVwVkyfA@mail.gmail.com>
<CALwNKeSh898aruYTJNHpdgnmxxfbQaGm4THxr03h+=3kcTV4HA@mail.gmail.com>
Message-ID: <73C0F320-D6DC-4598-B979-7FF65329BCCF@oracle.com>
On Dec 3, 2011, at 5:03 AM, Michael Barker wrote:
> This is a bit of a learning experience for us (LJC).
That's true for us old-timers, too. (Transfer-of-information requires good questions from newcomers.) Together we'll shake out the process. -- John
From stuart.marks at oracle.com Sun Dec 4 16:17:23 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sun, 04 Dec 2011 16:17:23 -0800
Subject: Request for Review: Warnings cleanup in java.lang.*, java.util.**
In-Reply-To: <4ED9042D.3000307@redhat.com>
References: <CAGVnyzRNvKDpSN-TuKRDg+ckKEZcQj-EfLUnt1Ayfse0PeDk6g@mail.gmail.com>
<4ED8C221.7070603@oracle.com> <4ED9042D.3000307@redhat.com>
Message-ID: <4EDC0D93.7000608@oracle.com>
On 12/2/11 9:00 AM, Omair Majid wrote:
> On 12/02/2011 07:18 AM, Alan Bateman wrote:
>> cc'ing core-libs-dev as that is the place to discuss these changes. I
>> see on the sign-up sheet [1] that omajid has signed up for java.lang,
>> maybe you are working together?
>
> Unfortunately, David and I were not working together :(
>
> Anyway, here is my webrev for java.lang.*
> http://cr.openjdk.java.net/~omajid/webrevs/warnings-day-2011/01/
>
> Sorry about the delay, building and testing this took longer than I had
> expected it to. Also, this patch only addresses the warnings pointed out by javac.
>
> The classes java.lang.ThreadLocal and java.lang.ClassValue are not included in
> the webrev. The fixes for ThreadLocal were basically sprinkling
> @SuppressWarnings("unchecked") throughout and the fixes for ClassValue looked
> slightly more complex when I tried to reduce the use of rawtypes. I will post a
> separate webrev for those later.
I've been mulling over what to do with these two patches for the past couple
days. Initially I was thinking of merging the patches and generating a new one
combining the best of both. But after I looked over both of them, I felt that
we should go with Omair's patch, for the following reasons. First, he had
signed up to do this area already, and second, his patch stayed will within the
guideline of "simple, minimal, and risk-free warnings fixes" that I had posted
in kicking off the WCD [1].
The bugid for this change is 7117612. I'll kick off a separate review thread
for this on core-libs-dev shortly.
Omair, regarding other changes you mentioned you might work on, please be
advised that John Rose is doing some other work on ClassValue [2], and he has
indicated that he's doing some warnings cleanup in there as well. You might
take a look at his webrev. On ThreadLocal, it looks like there are a bunch of
rawtypes warnings there too, so some judicious application of generic type
parameters seems called for in those cases. Let us know what you intend to do
in these areas.
See you on the other thread.
s'marks
[1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000380.html
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-December/008541.html
From stuart.marks at oracle.com Sun Dec 4 17:25:03 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sun, 04 Dec 2011 17:25:03 -0800
Subject: Warnings Cleanup Weekend Update
Message-ID: <4EDC1D6F.2030103@oracle.com>
This has turned out to be a rather long day. :-)
Ten changesets have been integrated so far, and 16 (!) changesets are being
reviewed or are awaiting review. There are a couple changesets still being
developed (including one from me; hey, I had to get some coding in myself).
We started at 10,013 warnings in the jdk repo and after the ten changesets
we're down to 9,147.
Current changeset status and warning counts are on the wiki. [1]
s'marks
[1] http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
From david.holmes at oracle.com Sun Dec 4 17:39:37 2011
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 05 Dec 2011 11:39:37 +1000
Subject: Collections.enumeration() WAS Warning Cleanup Day
In-Reply-To: <4EDA7A69.1040109@univ-mlv.fr>
References: <4EDA17FD.6060505@univ-mlv.fr> <4EDA331E.6040800@oracle.com>
<4EDA3C5C.6070404@univ-mlv.fr>
<D26F01DE-1B85-490B-A6D8-622A77A9CE76@oracle.com>
<4EDA7A69.1040109@univ-mlv.fr>
Message-ID: <4EDC20D9.9080304@oracle.com>
On 4/12/2011 5:37 AM, R?mi Forax wrote:
> On 12/03/2011 05:21 PM, Mike Duigou wrote:
>> On Dec 3 2011, at 07:12 , R?mi Forax wrote:
>>
>>> On 12/03/2011 03:33 PM, Alan Bateman wrote:
>>>> On 03/12/2011 12:37, R?mi Forax wrote:
>>>>> I've started to remove warnings from java.util
>>>>> and I'm not able to cleanly retrofit java.util.PropertyPermission
>>>>> because java.util.Collections.enumeration is wrongly typed.
>>>>>
>>>> R?mi - you might want to sync up with Mike Duigou as I believe he
>>>> has been working on the java.util area including collections. Also
>>>> best to move any discussions on collections/util area to
>>>> core-libs-dev too.
>>>>
>>>> -Alan
>>> too late :)
>>>
>>> Here is a webrev that remove most of the unchecked cast/raw generics
>>> warnings
>>> http://cr.openjdk.java.net/~forax/WarningDay1/webrev/
>>>
>>> R?mi
>>>
>> I have changes in about 15 files. I will compare them against yours. I
>> actually believe that doing the same work independently and then
>> comparing the results is a stronger validation than inspection review.
>
> yes.
>
>>
>> Thanks for submitting these fixes.
>>
>> Mike
>
> Mike, there is a raw type I was not able to remove in Collections line
> 1408,
> I understand the problem but was not able to come with a solution.
> The current fix is not good because it equivalent to say f*** you
> wildcards !
So the obvious fix is:
@SuppressWarnings({ "unchecked" })
UnmodifiableEntrySet(Set<? extends Map.Entry<? extends K, ? extends
V>> s) {
super((Set<? extends Map.Entry<K,V>>)s);
}
Why doesn't it work?
David
From schlosna at gmail.com Sun Dec 4 19:10:46 2011
From: schlosna at gmail.com (David Schlosnagle)
Date: Sun, 4 Dec 2011 22:10:46 -0500
Subject: Request for Review: Warnings cleanup in java.lang.*, java.util.**
In-Reply-To: <4EDC0D93.7000608@oracle.com>
References: <CAGVnyzRNvKDpSN-TuKRDg+ckKEZcQj-EfLUnt1Ayfse0PeDk6g@mail.gmail.com>
<4ED8C221.7070603@oracle.com> <4ED9042D.3000307@redhat.com>
<4EDC0D93.7000608@oracle.com>
Message-ID: <5B1E1FC6-518A-452A-BB67-46153B52CD79@gmail.com>
On Dec 4, 2011, at 7:17 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> I've been mulling over what to do with these two patches for the past couple days. Initially I was thinking of merging the patches and generating a new one combining the best of both. But after I looked over both of them, I felt that we should go with Omair's patch, for the following reasons. First, he had signed up to do this area already, and second, his patch stayed will within the guideline of "simple, minimal, and risk-free warnings fixes" that I had posted in kicking off the WCD [1].
Stuart,
That's fine with me, I realize I missed the sign up window. I hope there is another cleanup feat soon.
Thanks,
Dave
From stuart.marks at oracle.com Sun Dec 4 22:34:19 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sun, 04 Dec 2011 22:34:19 -0800
Subject: Request for Review: Warnings cleanup in java.lang.*, java.util.**
In-Reply-To: <5B1E1FC6-518A-452A-BB67-46153B52CD79@gmail.com>
References: <CAGVnyzRNvKDpSN-TuKRDg+ckKEZcQj-EfLUnt1Ayfse0PeDk6g@mail.gmail.com>
<4ED8C221.7070603@oracle.com> <4ED9042D.3000307@redhat.com>
<4EDC0D93.7000608@oracle.com>
<5B1E1FC6-518A-452A-BB67-46153B52CD79@gmail.com>
Message-ID: <4EDC65EB.20201@oracle.com>
On 12/4/11 7:10 PM, David Schlosnagle wrote:
> On Dec 4, 2011, at 7:17 PM, Stuart Marks<stuart.marks at oracle.com> wrote:
>
>> I've been mulling over what to do with these two patches for the past couple days. Initially I was thinking of merging the patches and generating a new one combining the best of both. But after I looked over both of them, I felt that we should go with Omair's patch, for the following reasons. First, he had signed up to do this area already, and second, his patch stayed will within the guideline of "simple, minimal, and risk-free warnings fixes" that I had posted in kicking off the WCD [1].
>
> Stuart,
>
> That's fine with me, I realize I missed the sign up window. I hope there is another cleanup feat soon.
>
> Thanks,
> Dave
Great, thanks for understanding. Yes, there will be other opportunities.
s'marks
From artem.ananiev at oracle.com Mon Dec 5 06:12:29 2011
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 05 Dec 2011 18:12:29 +0400
Subject: Review Request for 7116993 (warning cleanup java.applet)
In-Reply-To: <4ED956A3.80006@oracle.com>
References: <4ED7E98F.3040200@oracle.com> <4ED7EE3E.6020109@oracle.com>
<4ED899B4.7000207@oracle.com> <4ED956A3.80006@oracle.com>
Message-ID: <4EDCD14D.2070006@oracle.com>
Hi, Stuart, Danesh,
as java.applet changes are isolated from the rest of java.awt, they can
be pushed via TL workspace.
Thanks,
Artem
On 12/3/2011 2:52 AM, Stuart Marks wrote:
> Hi Artem,
>
> It turns out that Danesh Dadachanji had also been working on
> java.applet. The changes are identical, so there's no conflict.
>
> Is it OK if this change goes into the TL forest? If so, I can handle the
> push. Otherwise we'll to figure out something else.
>
> s'marks
>
> On 12/2/11 1:26 AM, Artem Ananiev wrote:
>>
>> I haven't seen anyone else working on java.applet. Your webrev looks
>> fine.
>>
>> Thanks,
>>
>> Artem
>>
>> On 12/2/2011 1:14 AM, Brandon Passanisi wrote:
>>> I'll withdraw this review request as I was notified by Xiomara that
>>> someone else has been working on java.applet. I had sent an e-mail to
>>> the alias yesterday about taking on java.applet though. Luckily, there
>>> aren't many warnings in java.applet.
>>>
>>> On 12/1/2011 12:54 PM, Brandon Passanisi wrote:
>>>> I have a webrev pertaining to the warning cleanup changes for
>>>> java.applet ready for review. Here's the info:
>>>>
>>>> Bug: 7116993
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~dmocek/bpassanisi/7116993/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Edmocek/bpassanisi/7116993/webrev.00/>
>>>>
>>>> Thanks.
>>>
From stuart.marks at oracle.com Sat Dec 3 12:59:56 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sat, 03 Dec 2011 12:59:56 -0800
Subject: review of 7117249: java.util warnings patches from LJC/Mike Barker
Message-ID: <4EDA8DCC.6040503@oracle.com>
[bcc to jdk8-dev; subsequent reviews/comments should go to core-libs-dev]
Hi Mike, all,
I've collected all the patches together, filed bug 7117249 to cover them, and
have started this new review thread on core-libs-dev for it. I've also posted a
webrev for the collected patches:
http://cr.openjdk.java.net/~smarks/reviews/7117249/webrev.0/
It looks like we have the following patches from your group so far:
- java/util/jar/JarFile.java
- java/util/jar/Manifest.java [patch4]
- java/util/logging/LogManager.java [patch2]
- java/util/prefs/Preferences.java
- java/util/prefs/XmlSupport.java
- java/util/zip/ZipEntry.java [patch2]
Did I get everything? I think you've addressed all the review comments that
have come in so far. (Other reviewers, please recheck the webrev!)
In addition, I have the following comments:
JarFile.java --
242 ZipEntry ze = (ZipEntry)enum_.nextElement();
621 ZipEntry ze = (ZipEntry) enum_.nextElement();
676 ZipEntry e = (ZipEntry) entries.nextElement();
I think these are all unnecessary casts now, since at 242 and 621 the return
type from nextElement is <? extends ZipEntry> and at 676 it's JarEntry, and
JarEntry is a subclass of ZipEntry. So, these casts can probably be removed
even though they don't generate warnings. An alternative would be to change the
type of e at 676 to JarEntry; not sure if this would be better.
LogManager.java --
203 Logger.getGlobal().setLogManager(manager);
204 manager.addLogger(Logger.getGlobal());
The doc recommends replacing mentions of the global field with a call to
getGlobal(), and this was done here, however sometimes what's in the doc
doesn't necessarily apply to library code. Can someone who's more familiar with
logging verify this change is correct?
418 Class<?> clz = ClassLoader.getSystemClassLoader().loadClass(word);
419 Handler hdl = (Handler) clz.newInstance();
Minor nit: extra space was before 'clz' in the original code, I think, to make
it line up with 'hdl'. Maybe spacing needs to be rearranged to keep them lined
up. (I see this a couple other places in the file, but it's not too prevalent.)
The alternative is to have a single space between the type and the variable name.
*******
Mike, if you end up needing to update this patch further, it might be easiest
if you just sent all the changes in a single patch file, i.e. the output of 'hg
diff'. I can then apply it to the tip and generate a webrev quite easily.
Thanks.
s'marks
From chris.hegarty at oracle.com Mon Dec 5 08:44:45 2011
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 05 Dec 2011 16:44:45 +0000
Subject: Review Request: Warnings cleanup in sun.management and its
subpackages
In-Reply-To: <4ED95AC4.2090905@oracle.com>
References: <4ED95AC4.2090905@oracle.com>
Message-ID: <4EDCF4FD.9020806@oracle.com>
Some trivial comments:
ConnectorAddressLink.java
L172 - L178, you can use 'for(Counter c: counters)' and remove
subsequent redundant cases.
MappedMXBeanType.java
L76, cast to (Class<?) ???
Some of the public classes have API changes. Are these classes in any
way supported? Some have Javadoc comments that would make me think this,
but maybe not given the name space.
-Chris.
On 02/12/2011 23:09, Kurchi Hazra wrote:
> Hi,
>
> http://cr.openjdk.java.net/~khazra/7117570/webrev.00/
>
> Please review this webrev that cleans warnings in sun.management and its
> subpackages. These packages are now warning-free I believe.
>
> Looking forward to your comments. I have used the serialver tool to
> generate all the serial version UIDs that I have added.
>
>
>
> Thanks,
>
> Kurchi
>
From naoto.sato at oracle.com Mon Dec 5 11:01:19 2011
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 05 Dec 2011 11:01:19 -0800
Subject: Review request for IMF classes and Locale related classes
In-Reply-To: <4ED97E39.1050504@oracle.com>
References: <4ED91F51.2020502@oracle.com> <4ED95018.3070808@oracle.com>
<4ED96005.3000709@oracle.com> <4ED966AA.2010701@oracle.com>
<4ED97E39.1050504@oracle.com>
Message-ID: <4EDD14FF.9060603@oracle.com>
OK here is the revised one:
http://cr.openjdk.java.net/~naoto/7117469/webrev.02/
I hope this is the final :-)
Naoto
On 12/2/11 5:41 PM, Stuart Marks wrote:
> The changes you made are good, thanks.
>
> I did figure out how to deal with the static initializer in
> AllAvailableLocales:
>
> @SuppressWarnings({"unchecked"})
> Class<? extends LocaleServiceProvider>[] providerClasses =
> (Class<? extends LocaleServiceProvider>[]) new Class<?>[] {
> java.text.spi.BreakIteratorProvider.class,
> ...
> };
>
> This is a bit uglier but it does reduce the scope of warnings suppression.
>
> I think you might be able to get rid of the wildcards, too:
>
> @SuppressWarnings({"unchecked"})
> Class<LocaleServiceProvider>[] providerClasses =
> (Class<LocaleServiceProvider>[]) new Class<?>[] {
> java.text.spi.BreakIteratorProvider.class,
> ...
> };
> ...
> for (Class<LocaleServiceProvider> providerClass : providerClasses) {
> ...
> }
>
> I'm not entirely sure why this works, but it seems to compile for me
> without warnings or errors....
>
> s'marks
>
>
>
> On 12/2/11 4:00 PM, Naoto Sato wrote:
>> Hi Stuart,
>>
>> Thank you for your comments. Here is the updated webrev reflecting your
>> suggestions. Please review:
>>
>> http://cr.openjdk.java.net/~naoto/7117469/webrev.01/
>>
>> Naoto
>>
>>
>> On 12/2/11 3:32 PM, Stuart Marks wrote:
>>> Hi Naoto,
>>>
>>> A couple comments.
>>>
>>> java/util/Currency.java --
>>>
>>> The @SuppressWarnings covers the entire method. We're trying to use
>>> @SuppressWarnings with as narrow a scope as possible. Sometimes it's
>>> helpful to create a local variable declaration for this purpose; perhaps
>>> something like this will help:
>>>
>>> @SuppressedWarnings("unchecked")
>>> Set<Currency> result = (Set<Currency>) available.clone();
>>> return result;
>>>
>>> You can probably do something similar in
>>> sun/util/LocaleServiceProviderPool.java in the getLocalizedObjectImpl()
>>> method.
>>>
>>> The suppression of warnings on the static AllAvailableLocales class is a
>>> bit of a puzzle. Maybe it's OK to leave the suppression for that entire
>>> class.
>>>
>>> s'marks
>>>
>>>
>>> On 12/2/11 2:24 PM, Masayoshi Okutsu wrote:
>>>> Looks good to me.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 2011/12/02 10:56, Naoto Sato wrote:
>>>>> Hello,
>>>>>
>>>>> Could you please review these two changesets for the WCD? One is for
>>>>> classes
>>>>> that belongs to input method framework:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/7117465/webrev.00/
>>>>>
>>>>> and the other is for (some of the) i18n related *.util.* classes:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/7117469/webrev.00/
>>>>>
>>>>> Thanks!
>>>>> Naoto
>>
From artem.ananiev at oracle.com Mon Dec 5 11:37:59 2011
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 05 Dec 2011 23:37:59 +0400
Subject: [8] Review request for 7117008: warning cleanup in sun.awt
Message-ID: <4EDD1D97.3020304@oracle.com>
Hi, AWT team,
here is a fix for 7117008, which is about javac warning cleanup in the
sun.awt package:
http://cr.openjdk.java.net/~art/jdk8/7117008/
As a part of this fix, I'm deleting several classes, which haven't been
changed since 1995. They are not referenced anywhere in the JDK
workspace, and they are not public API, so I consider them safe to
remove. Please, let me know if you feel these files should stay in the
workspace.
Thanks,
Artem
From kurchi.subhra.hazra at oracle.com Mon Dec 5 11:49:21 2011
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Mon, 05 Dec 2011 11:49:21 -0800
Subject: Review Request: Warnings cleanup in sun.management and its
subpackages
In-Reply-To: <4EDCF4FD.9020806@oracle.com>
References: <4ED95AC4.2090905@oracle.com> <4EDCF4FD.9020806@oracle.com>
Message-ID: <4EDD2041.2060606@oracle.com>
On 12/5/2011 8:44 AM, Chris Hegarty wrote:
>
> Some trivial comments:
> ConnectorAddressLink.java
> L172 - L178, you can use 'for(Counter c: counters)' and remove
> subsequent redundant cases.
> MappedMXBeanType.java
> L76, cast to (Class<?) ???
Thanks! I changed these.
>
> Some of the public classes have API changes. Are these classes in any
> way supported? Some have Javadoc comments that would make me think
> this, but maybe not given the name space.
I tried being careful - but I guess I did touch public classes. Maybe I
will wait for Mandy's review and go over these again, and then send out
a final webrev.
- Kurchi
>
> -Chris.
>
> On 02/12/2011 23:09, Kurchi Hazra wrote:
>> Hi,
>>
>> http://cr.openjdk.java.net/~khazra/7117570/webrev.00/
>>
>> Please review this webrev that cleans warnings in sun.management and its
>> subpackages. These packages are now warning-free I believe.
>>
>> Looking forward to your comments. I have used the serialver tool to
>> generate all the serial version UIDs that I have added.
>>
>>
>>
>> Thanks,
>>
>> Kurchi
>>
--
-Kurchi
From dbhole at redhat.com Mon Dec 5 12:30:50 2011
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 5 Dec 2011 15:30:50 -0500
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <21DB2F64-8352-4574-8EFB-58A0C563D907@oracle.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<20111202184726.GX2461@redhat.com>
<21DB2F64-8352-4574-8EFB-58A0C563D907@oracle.com>
Message-ID: <20111205203050.GL8668@redhat.com>
* John Rose <john.r.rose at oracle.com> [2011-12-02 17:12]:
> On Dec 2, 2011, at 10:47 AM, Deepak Bhole wrote:
>
> (Netbeans can find opportunities for diamond operators, BTW.)
>
> The new parameters <K extends Attribute, V> are clearly more
> correct, but they look like an API change on a public method or
> constructor. If so, I think you'll have to find a different
> approach. (But I'm not an API change and generics expert.)
>
> Do you mean the changes in the AttributedString constructor? I just
> added names for the bounded and unbound wildcards so that they could be
> used in the body (without it, the compiler was throwing errors).
> I am not expert on these either -- I didn't know adding names could
> change signature in an incompatible way.
> I just wrote a small test case to try this out and everything seems to
> work fine. Adding named parameters does not appear to break
> compatibility in my test case.
>
> Since this is an important point, I checked into it. Result: Wildcards
> cannot (in general) be compatibly switched with named type parameters
> in public APIs.
> See the demonstration here:
> [1]https://gist.github.com/1424776
> (This is subject to correction by someone more expert than me in API
> evolution, like Alex Buckley, Joe Darcy, or Maurizio Cimadamore. I'm a
> JVM hacker!)
>
Thanks for the pointer! Yes, it is rather unfortunate that it cannot
changed then :( I have reverted it and added a more localized @SW
instead.
> For createRunAttributeDataVectors, ensureRunBreak, etc. consider
> pushing the @SuppressWarnings down onto the individual declarations.
> It is best to put @SuppressWarnings on the smallest program unit
> possible, and a local variable declaration is often the right spot.
> I see that createRunAttributeDataVectors could be viewed as simple
> enough to mark as a whole, but ensureRunBreak is probably too
> complex to mark as a whole.
>
> Doh! Good point.
> For DictionaryBasedBreakIterator.divideUpDictionaryRange, I cannot add
> it above the
> "bestBreakPositions = (Stack<Integer>)(currentBreakPositions.clone());"
> line
> without refactoring. I done done a very minor refactor (use copy
> constructor instead of clone) -- please let me know if it is
> satisfactory.
>
> I'm OK with that. Replacing clone by an equivalent copy constructor
> looks trivial enough to me, even though it changes bytecode output.
>
As mentioned in my other email to R?mi, the clone constructor was my
initial plan but didn't work. Instead I am just initializing a temp var
(so that I can add a localized @SW) and then assigning the outer scope
var to it.
> As for others, I've narrowed it in the new webrev. Narrowing also
> exposed a few more places I had missed in ensureRunBreak. Fixed now.
>
> In the same way, consider pushing the annotation into the body of
> class AttributeEntry, even though that class is very simple.
>
> That one is for the declaration itself -- the warning is about the Map
> supertype not being parameterized.
>
> I didn't get that clearly from the comment. Suggest:
> +// Suppress warning about raw Map.Entry. Parameterizing Map.Entry
> correctly
> +// requires changing return of getKey
> ++// Must suppress the whole class to suppress warning about raw
> supertype Map.Entry.
> ++// Parameterizing Map.Entry correctly would requires changing return
> of getKey.
>
Done!
[ ... ]
>
> setIndex is deprecated, so I looked into what the method did and did it
> at the call site. Sorry, I should have specifically mentioned this
> re-factor in the original email :(
> I am fine with just suppressing deprecation warning there. I have done
> so in the new copy by adding the annotation to the method.
>
> Right. Don't inline the deprecated method body. Just suppress the
> deprecation warning, with a comment. (Maybe put the body expressions
> in a comment, for the next person who touches the code.)
>
I've added the deprecated method names in a comment. I avoided adding
the body just in case it changes by the time someone gets to it.
[ ... ]
>
> I saw Stuart's comments on this. Didn't know that there was a way to
> find
> existing serialid (I thought Eclipse just generated a random one)! I
> have added
> the class default id.
>
> Yep. SW("serial") seems to be the wrong thing, almost everywhere.
>
Out of curiosity, why is this? Is it because not having a serial can
cause invalid class errors or are there other reasons?
Thanks for taking a look. New webrev:
http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.02/
As with before, diff between rev 01 and 02 is there too:
http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.02/rev-01-02.patch
Cheers,
Deepak
From mandy.chung at oracle.com Mon Dec 5 16:28:41 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 05 Dec 2011 16:28:41 -0800
Subject: Review Request: Warnings cleanup in sun.management and its
subpackages
In-Reply-To: <4ED95AC4.2090905@oracle.com>
References: <4ED95AC4.2090905@oracle.com>
Message-ID: <4EDD61B9.2030804@oracle.com>
On 12/2/11 3:09 PM, Kurchi Hazra wrote:
> Hi,
>
> http://cr.openjdk.java.net/~khazra/7117570/webrev.00/
All these classes are implementation classes. These classes were
implemented before the 1.5 language features were integrated.
Below I included the suggestion to replace iterator with foreach
since you are already in that file.
Agent.java
L221, 229: Since you're in that file, can you change it to
call the UnsupportedOperationException(String msg, Throwable cause)
constructor so that the cause exception is available?
L252-271: it would be good to replace this try-finally with
try-with-resource.
ConnectorAddressLink.java
L120-128: it'd be better to change this to use foreach.
L172-173: the variable c in the for-loop should be
of type Counter.
GarbageCollectorImpl.java
L76: another good candidate to use foreach.
HotspotCompilation.java
L139-144: another good candidate to use foreach.
LazyCompositeData.java
L162: for (String item : allItems) {...}
MappedMXBeanType.java
L76, 88: the cast should be fixed to "(Class<>)"
L229, 759: I think these suppressed warnings can be eliminated.
I have to study it a little bit to determine what we can do
with this file and get back to you.
NotificationEmitterSupport.java
This class was copied fromjavax.management.NotificationBroadcasterSupport
when it was implemented but the jmx class has been updated since then.
It didn't use javax.management.NotificationBroadcasterSupport directly
to avoid loading the jmx classes if java.lang.management is used locally
with no jmx agent created. I think it's time to update this class
and I'll submit a CR for that. Your change is fine.
ConnectorBootstrap.java
L237: nit: this extra line which can be removed.
AdaptorBootstrap.java
L130, 133: The com.sun.jmx.snmp API is not generified (it's internal API).
Although the javadoc states that the getTrapDestinations method returns
an enumeration of InetAddress, I think it'd be better for this change
to wait until the com.sun.jmx.snmp API is updated.
JvmMemManagerTableMetaImpl.java
L70: should be indented (looks like it was accidentially removed
in your change).
L122: the returned type should be List<MemoryManagerMXBean>, right?
L107: JvmContextFactory.getUserData() returns a Map<Object,Object>
which is the current implementation. This strikes me that
this may lead to some type casting somewhere.
e.g. JvmMemoryImpl.java L160 - this casts the key to MemoryUsage.
Shouldn't javac issue unchecked warning for this? I wonder if
you see any other warnings.
I didn't review the rest of the snmp files (up to the JvmMemoryImpl.java
file). It takes longer that I expect. It was very old code and
looks like that it requires more investigation. I suggest to separate
the snmp change and first get the non-snmp files warning cleaned and
continue with the snmp one next.
Thanks
Mandy
From david.katleman at oracle.com Mon Dec 5 16:33:56 2011
From: david.katleman at oracle.com (David Katleman)
Date: Mon, 05 Dec 2011 16:33:56 -0800
Subject: Review Request: 7117162: jdk8/jaxws/Makefile default DROPS_DIR should
set to jdk8-drops
Message-ID: <4EDD62F4.9070804@oracle.com>
Hello!
Hopefully a simple straightforward fix to
7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-drops
Consists of updating the jdk7 drop references to jdk8.
http://cr.openjdk.java.net/~katleman/7117162/jaxws/webrev.00/
http://cr.openjdk.java.net/~katleman/7117162/jaxp/webrev.00/
Yes, I'm aware of the rumblings to drop "DROPS" altogether in JDK8.
Until that happens, this ensures the existing mechanism looks at the
correct release by default.
Thanks
Dave
From kelly.ohair at oracle.com Mon Dec 5 16:48:05 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 5 Dec 2011 16:48:05 -0800
Subject: Review Request: 7117162: jdk8/jaxws/Makefile default DROPS_DIR
should set to jdk8-drops
In-Reply-To: <4EDD62F4.9070804@oracle.com>
References: <4EDD62F4.9070804@oracle.com>
Message-ID: <0CBA8E73-2B7E-4A4F-9944-732CC916E8F4@oracle.com>
Looks good.
-kto
On Dec 5, 2011, at 4:33 PM, David Katleman wrote:
> Hello!
>
> Hopefully a simple straightforward fix to
>
> 7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-drops
>
> Consists of updating the jdk7 drop references to jdk8.
>
> http://cr.openjdk.java.net/~katleman/7117162/jaxws/webrev.00/
> http://cr.openjdk.java.net/~katleman/7117162/jaxp/webrev.00/
>
> Yes, I'm aware of the rumblings to drop "DROPS" altogether in JDK8. Until that happens, this ensures the existing mechanism looks at the correct release by default.
>
> Thanks
> Dave
>
>
From stuart.marks at oracle.com Mon Dec 5 16:49:52 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 05 Dec 2011 16:49:52 -0800
Subject: Review Request: Warnings cleanup in sun.management and its
subpackages
In-Reply-To: <4EDD61B9.2030804@oracle.com>
References: <4ED95AC4.2090905@oracle.com> <4EDD61B9.2030804@oracle.com>
Message-ID: <4EDD66B0.6000404@oracle.com>
Hi Mandy,
Thanks for the thorough review.
For warnings cleanup, we've been trying to avoid including refactorings like
changing Enumerations to Iterator or to the enhanced-for loop. Changes to use
try-with-resources also fall into this category. But I've been OK with such
changes if the primary maintainer of the area is OK with them. Are you
comfortable giving the go-ahead for these kinds of changes? I assume you are,
since you suggested them, but I just wanted to double check.
Also, would any additional testing be required before these changes go in?
s'marks
On 12/5/11 4:28 PM, Mandy Chung wrote:
> On 12/2/11 3:09 PM, Kurchi Hazra wrote:
>> Hi,
>>
>> http://cr.openjdk.java.net/~khazra/7117570/webrev.00/
> All these classes are implementation classes. These classes were
> implemented before the 1.5 language features were integrated.
> Below I included the suggestion to replace iterator with foreach
> since you are already in that file.
>
> Agent.java
> L221, 229: Since you're in that file, can you change it to
> call the UnsupportedOperationException(String msg, Throwable cause)
> constructor so that the cause exception is available?
>
> L252-271: it would be good to replace this try-finally with
> try-with-resource.
>
> ConnectorAddressLink.java
> L120-128: it'd be better to change this to use foreach.
> L172-173: the variable c in the for-loop should be
> of type Counter.
>
> GarbageCollectorImpl.java
> L76: another good candidate to use foreach.
>
> HotspotCompilation.java
> L139-144: another good candidate to use foreach.
>
> LazyCompositeData.java
> L162: for (String item : allItems) {...}
>
> MappedMXBeanType.java
> L76, 88: the cast should be fixed to "(Class<>)"
> L229, 759: I think these suppressed warnings can be eliminated.
> I have to study it a little bit to determine what we can do
> with this file and get back to you.
>
> NotificationEmitterSupport.java
> This class was copied fromjavax.management.NotificationBroadcasterSupport
> when it was implemented but the jmx class has been updated since then.
> It didn't use javax.management.NotificationBroadcasterSupport directly
> to avoid loading the jmx classes if java.lang.management is used locally
> with no jmx agent created. I think it's time to update this class
> and I'll submit a CR for that. Your change is fine.
>
> ConnectorBootstrap.java
> L237: nit: this extra line which can be removed.
>
> AdaptorBootstrap.java
> L130, 133: The com.sun.jmx.snmp API is not generified (it's internal API).
> Although the javadoc states that the getTrapDestinations method returns
> an enumeration of InetAddress, I think it'd be better for this change
> to wait until the com.sun.jmx.snmp API is updated.
>
> JvmMemManagerTableMetaImpl.java
> L70: should be indented (looks like it was accidentially removed
> in your change).
>
> L122: the returned type should be List<MemoryManagerMXBean>, right?
>
> L107: JvmContextFactory.getUserData() returns a Map<Object,Object>
> which is the current implementation. This strikes me that
> this may lead to some type casting somewhere.
> e.g. JvmMemoryImpl.java L160 - this casts the key to MemoryUsage.
> Shouldn't javac issue unchecked warning for this? I wonder if
> you see any other warnings.
>
> I didn't review the rest of the snmp files (up to the JvmMemoryImpl.java
> file). It takes longer that I expect. It was very old code and
> looks like that it requires more investigation. I suggest to separate
> the snmp change and first get the non-snmp files warning cleaned and
> continue with the snmp one next.
>
> Thanks
> Mandy
>
>
From stuart.marks at oracle.com Mon Dec 5 17:00:44 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 05 Dec 2011 17:00:44 -0800
Subject: Review request for IMF classes and Locale related classes
In-Reply-To: <4EDD14FF.9060603@oracle.com>
References: <4ED91F51.2020502@oracle.com> <4ED95018.3070808@oracle.com>
<4ED96005.3000709@oracle.com> <4ED966AA.2010701@oracle.com>
<4ED97E39.1050504@oracle.com> <4EDD14FF.9060603@oracle.com>
Message-ID: <4EDD693C.5010708@oracle.com>
Looks good! Please proceed with the push.
thanks.
s'marks
On 12/5/11 11:01 AM, Naoto Sato wrote:
> OK here is the revised one:
>
> http://cr.openjdk.java.net/~naoto/7117469/webrev.02/
>
> I hope this is the final :-)
>
> Naoto
>
> On 12/2/11 5:41 PM, Stuart Marks wrote:
>> The changes you made are good, thanks.
>>
>> I did figure out how to deal with the static initializer in
>> AllAvailableLocales:
>>
>> @SuppressWarnings({"unchecked"})
>> Class<? extends LocaleServiceProvider>[] providerClasses =
>> (Class<? extends LocaleServiceProvider>[]) new Class<?>[] {
>> java.text.spi.BreakIteratorProvider.class,
>> ...
>> };
>>
>> This is a bit uglier but it does reduce the scope of warnings suppression.
>>
>> I think you might be able to get rid of the wildcards, too:
>>
>> @SuppressWarnings({"unchecked"})
>> Class<LocaleServiceProvider>[] providerClasses =
>> (Class<LocaleServiceProvider>[]) new Class<?>[] {
>> java.text.spi.BreakIteratorProvider.class,
>> ...
>> };
>> ...
>> for (Class<LocaleServiceProvider> providerClass : providerClasses) {
>> ...
>> }
>>
>> I'm not entirely sure why this works, but it seems to compile for me
>> without warnings or errors....
>>
>> s'marks
>>
>>
>>
>> On 12/2/11 4:00 PM, Naoto Sato wrote:
>>> Hi Stuart,
>>>
>>> Thank you for your comments. Here is the updated webrev reflecting your
>>> suggestions. Please review:
>>>
>>> http://cr.openjdk.java.net/~naoto/7117469/webrev.01/
>>>
>>> Naoto
>>>
>>>
>>> On 12/2/11 3:32 PM, Stuart Marks wrote:
>>>> Hi Naoto,
>>>>
>>>> A couple comments.
>>>>
>>>> java/util/Currency.java --
>>>>
>>>> The @SuppressWarnings covers the entire method. We're trying to use
>>>> @SuppressWarnings with as narrow a scope as possible. Sometimes it's
>>>> helpful to create a local variable declaration for this purpose; perhaps
>>>> something like this will help:
>>>>
>>>> @SuppressedWarnings("unchecked")
>>>> Set<Currency> result = (Set<Currency>) available.clone();
>>>> return result;
>>>>
>>>> You can probably do something similar in
>>>> sun/util/LocaleServiceProviderPool.java in the getLocalizedObjectImpl()
>>>> method.
>>>>
>>>> The suppression of warnings on the static AllAvailableLocales class is a
>>>> bit of a puzzle. Maybe it's OK to leave the suppression for that entire
>>>> class.
>>>>
>>>> s'marks
>>>>
>>>>
>>>> On 12/2/11 2:24 PM, Masayoshi Okutsu wrote:
>>>>> Looks good to me.
>>>>>
>>>>> Thanks,
>>>>> Masayoshi
>>>>>
>>>>> On 2011/12/02 10:56, Naoto Sato wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you please review these two changesets for the WCD? One is for
>>>>>> classes
>>>>>> that belongs to input method framework:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/7117465/webrev.00/
>>>>>>
>>>>>> and the other is for (some of the) i18n related *.util.* classes:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/7117469/webrev.00/
>>>>>>
>>>>>> Thanks!
>>>>>> Naoto
>>>
>
From xiomara.jayasena at oracle.com Mon Dec 5 17:00:53 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Mon, 5 Dec 2011 17:00:53 -0800 (PST)
Subject: Review Request: 7117162: jdk8/jaxws/Makefile default DROPS_DIR
should set to jdk8-drops
In-Reply-To: <4EDD62F4.9070804@oracle.com>
References: <4EDD62F4.9070804@oracle.com>
Message-ID: <0fb827cb-72f7-416a-9f8b-d028184b9eef@default>
The changes look fine to me. This should probably have gone to the build-dev alias instead, for review.
-Xiomara
> -----Original Message-----
> From: David Katleman
> Sent: Monday, December 05, 2011 4:34 PM
> To: jdk8-dev at openjdk.java.net
> Subject: Review Request: 7117162: jdk8/jaxws/Makefile default DROPS_DIR
> should set to jdk8-drops
>
> Hello!
>
> Hopefully a simple straightforward fix to
>
> 7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-
> drops
>
> Consists of updating the jdk7 drop references to jdk8.
>
> http://cr.openjdk.java.net/~katleman/7117162/jaxws/webrev.00/
> http://cr.openjdk.java.net/~katleman/7117162/jaxp/webrev.00/
>
> Yes, I'm aware of the rumblings to drop "DROPS" altogether in JDK8.
> Until that happens, this ensures the existing mechanism looks at the
> correct release by default.
>
> Thanks
> Dave
>
>
From mandy.chung at oracle.com Mon Dec 5 17:15:42 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 05 Dec 2011 17:15:42 -0800
Subject: Review Request: 7117162: jdk8/jaxws/Makefile default DROPS_DIR
should set to jdk8-drops
In-Reply-To: <4EDD62F4.9070804@oracle.com>
References: <4EDD62F4.9070804@oracle.com>
Message-ID: <4EDD6CBE.2080600@oracle.com>
Looks good.
Mandy
On 12/5/11 4:33 PM, David Katleman wrote:
> Hello!
>
> Hopefully a simple straightforward fix to
>
> 7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to
> jdk8-drops
>
> Consists of updating the jdk7 drop references to jdk8.
>
> http://cr.openjdk.java.net/~katleman/7117162/jaxws/webrev.00/
> http://cr.openjdk.java.net/~katleman/7117162/jaxp/webrev.00/
>
> Yes, I'm aware of the rumblings to drop "DROPS" altogether in JDK8.
> Until that happens, this ensures the existing mechanism looks at the
> correct release by default.
>
> Thanks
> Dave
>
>
From mandy.chung at oracle.com Mon Dec 5 17:42:24 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 05 Dec 2011 17:42:24 -0800
Subject: Review Request: Warnings cleanup in sun.management and its
subpackages
In-Reply-To: <4EDD66B0.6000404@oracle.com>
References: <4ED95AC4.2090905@oracle.com> <4EDD61B9.2030804@oracle.com>
<4EDD66B0.6000404@oracle.com>
Message-ID: <4EDD7300.4000203@oracle.com>
On 12/5/11 4:49 PM, Stuart Marks wrote:
> Hi Mandy,
>
> Thanks for the thorough review.
>
> For warnings cleanup, we've been trying to avoid including
> refactorings like changing Enumerations to Iterator or to the
> enhanced-for loop. Changes to use try-with-resources also fall into
> this category. But I've been OK with such changes if the primary
> maintainer of the area is OK with them.
I agree that we should avoid refactoring from warnings cleanup in
general. So I try to be cautious about where to suggest replacing the
iterator with foreach (this is the main suggestion) and also keep them
to the lines that Kurchi already modified.
I no longer work on this area but I'm sure the serviceability team will
appreciate this cleanup.
I wasn't sure to suggest try-with-resources initially but Kurchi already
included such change in her webrev. So the testing required for her
change should cover it :-)
> Are you comfortable giving the go-ahead for these kinds of changes? I
> assume you are, since you suggested them, but I just wanted to double
> check.
I'm comfortable for the places suggested in my comment as they are
trivial ones. I would not recommend to look for other refactoring
opportunity besides them (e.g. the snmp files are more convoluted).
>
> Also, would any additional testing be required before these changes go
> in?
>
Thanks for asking. I meant to mention it - jdk_lang and jdk_management
test targets. java.lang.management tests are included in the jdk_lang
target. jdk_management includes the sun.management tests and it also
includes jmx tests which Kurchi's change didn't touch that area but no
harm to run that and make the jprt submission simpler.
Thanks
Mandy
From artem.ananiev at oracle.com Tue Dec 6 02:15:13 2011
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Tue, 06 Dec 2011 14:15:13 +0400
Subject: Result: New JDK8 Committer: Alexander Scherbatiy
Message-ID: <4EDDEB31.4090208@oracle.com>
Voting for Alexander Scherbatiy [1] is now closed.
Yes: 14
Veto: 0
Abstain: 3
According to the Bylaws definition of Lazy Consensus, this is sufficient
to approve the nomination.
Thanks,
Artem
[1]
http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000261.html
From anthony.petrov at oracle.com Tue Dec 6 04:31:42 2011
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 06 Dec 2011 16:31:42 +0400
Subject: <AWT Dev> [8] Review request for 7117008: warning cleanup in
sun.awt
In-Reply-To: <4EDD1D97.3020304@oracle.com>
References: <4EDD1D97.3020304@oracle.com>
Message-ID: <4EDE0B2E.3020205@oracle.com>
Hi Artem,
The fix looks fine to me.
--
best regards,
Anthony
On 12/5/2011 11:37 PM, Artem Ananiev wrote:
> Hi, AWT team,
>
> here is a fix for 7117008, which is about javac warning cleanup in the
> sun.awt package:
>
> http://cr.openjdk.java.net/~art/jdk8/7117008/
>
> As a part of this fix, I'm deleting several classes, which haven't been
> changed since 1995. They are not referenced anywhere in the JDK
> workspace, and they are not public API, so I consider them safe to
> remove. Please, let me know if you feel these files should stay in the
> workspace.
>
> Thanks,
>
> Artem
From stuart.marks at oracle.com Tue Dec 6 15:42:15 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 06 Dec 2011 15:42:15 -0800
Subject: review request (M): 7117167: Misc warnings in java.lang.invoke
and sun.invoke.*
In-Reply-To: <454EA54E-6326-4621-A9DC-D03688F1B9AD@oracle.com>
References: <454EA54E-6326-4621-A9DC-D03688F1B9AD@oracle.com>
Message-ID: <4EDEA857.9080605@oracle.com>
On 12/1/11 3:12 PM, John Rose wrote:
> 7117167: Misc warnings in java.lang.invoke and sun.invoke.*
>
> http://cr.openjdk.java.net/~jrose/7117167/webrev.00/
>
> Removing build warnings from java.lang.invoke and sun.invoke.*, as part of the December 2011 cleanup effort.
Hi John,
I'm finally getting back to this. Just a couple comments:
MethodHandles.java --
The change here is to add a wildcard type parameter to the parameter of the
unreflectConstructor() method. I believe this is a public API. Is such a change
permitted? I started thinking about compatibility, but compatibility is
actually a side issue. The main issue is whether it's a spec change. I think it
is, but I have to admit that not really sure. But if it is a spec change, I
don't think we should be making it in the context of warnings cleanup.
MethodHandleImpl.java --
Just an observation, really, but I puzzled for a while over the suppression of
rawtypes and unchecked warnings at the construction of AllocateObject (L115).
As I looked further I realized, "oh *that's* what Remi was talking about." [1]
On the other hand I see your point that the class declaration AllocateObject<C>
and uses of C within that class really do make sense. Perhaps this is the time
when one really wants to write
new AllocateObject<?>(...)
but of course this is illegal. I don't have a specific recommendation to change
anything here. It's just that whenever there's code that's puzzling, I'm always
looking around for a better way to write it.
Anyway, that's it, everything else looks fine.
s'marks
[1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000406.html
From john.r.rose at oracle.com Tue Dec 6 17:26:46 2011
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 6 Dec 2011 17:26:46 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <20111205203050.GL8668@redhat.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<20111202184726.GX2461@redhat.com>
<21DB2F64-8352-4574-8EFB-58A0C563D907@oracle.com>
<20111205203050.GL8668@redhat.com>
Message-ID: <FC2F76EA-9A99-4E27-9D50-4242B684A59A@oracle.com>
On Dec 5, 2011, at 12:30 PM, Deepak Bhole wrote:
>> Since this is an important point, I checked into it. Result: Wildcards
>> cannot (in general) be compatibly switched with named type parameters
>> in public APIs.
>> See the demonstration here:
>> [1]https://gist.github.com/1424776
>> (This is subject to correction by someone more expert than me in API
>> evolution, like Alex Buckley, Joe Darcy, or Maurizio Cimadamore. I'm a
>> JVM hacker!)
>>
>
> Thanks for the pointer! Yes, it is rather unfortunate that it cannot
> changed then :( I have reverted it and added a more localized @SW
> instead.
Good. I puzzled some more over the localized @SW and found a formulation
that does not require any @SW at all. It's a matter of choosing wildcards very
carefully. See patch below.
Basically, it's one of those cases where a type T isn't good enough, but a type
"? extends T" will do the job. (I can't tell you all such cases, but this is one of them!)
>> I'm OK with that. Replacing clone by an equivalent copy constructor
>> looks trivial enough to me, even though it changes bytecode output.
>>
>
> As mentioned in my other email to R?mi, the clone constructor was my
> initial plan but didn't work. Instead I am just initializing a temp var
> (so that I can add a localized @SW) and then assigning the outer scope
> var to it.
Good.
>> Yep. SW("serial") seems to be the wrong thing, almost everywhere.
>
> Out of curiosity, why is this? Is it because not having a serial can
> cause invalid class errors or are there other reasons?
If you don't have a SVUID, the system makes one for you. (It is the same
one your IDE can generate explicitly.) If you way @SW("serial"), you are
telling the system that it can adjust the SVUID at will. You get into trouble
with this if somebody adds another (non-transient) field. This changes the
implicit SVUID. This can lead to surprising results down the road.
> Thanks for taking a look. New webrev:
> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.02/
>
> As with before, diff between rev 01 and 02 is there too:
> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.02/rev-01-02.patch
On Dec 2, 2011, at 2:12 PM, John Rose wrote:
>>> In the same way, consider pushing the annotation into the body of class AttributeEntry, even though that class is very simple.
>>>
>>
>> That one is for the declaration itself -- the warning is about the Map
>> supertype not being parameterized.
>
>
> I didn't get that clearly from the comment. Suggest:
> +// Suppress warning about raw Map.Entry. Parameterizing Map.Entry correctly
> +// requires changing return of getKey
> ++// Must suppress the whole class to suppress warning about raw supertype Map.Entry.
> ++// Parameterizing Map.Entry correctly would requires changing return of getKey.
I went back to class AttributeEntry and realized that it also does not need @SW.
Since it is a non-public class, it is OK to change the supertype and the return value
of getKey. A simple correction to the type parameters of a non-public name is in
scope for this project, as I read Stuart here:
http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000380.html
-+// Must suppress the whole class to suppress warning about raw supertype Map.Entry.
-+// Parameterizing Map.Entry correctly would requires changing return of getKey.
-+ at SuppressWarnings("rawtypes")
-class AttributeEntry implements Map.Entry {
++class AttributeEntry implements Map.Entry<Attribute,Object> {
...
- public Object getKey() {
++ public Attribute getKey() {
(I could be mistaken about this; please double check. I made a public API
mistake in my own java.lang.invoke warnings cleanup!)
Also, I noticed some extraneous blank lines surrounding @SW occurrences.
They aren't needed. Also, a few occurrences of @SW({"foo"}) do not need
the braces: @SW("foo").
Here are all the adjustments I suggest, in one patch:
https://gist.github.com/1440966
See if they work for you. If so, we're done.
-- John
From john.r.rose at oracle.com Tue Dec 6 17:35:01 2011
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 6 Dec 2011 17:35:01 -0800
Subject: review request (M): 7117167: Misc warnings in java.lang.invoke
and sun.invoke.*
In-Reply-To: <4EDEA857.9080605@oracle.com>
References: <454EA54E-6326-4621-A9DC-D03688F1B9AD@oracle.com>
<4EDEA857.9080605@oracle.com>
Message-ID: <8B7A5715-0FC9-4E0D-9A3E-E4AC33FCE4E2@oracle.com>
On Dec 6, 2011, at 3:42 PM, Stuart Marks wrote:
> On 12/1/11 3:12 PM, John Rose wrote:
>> 7117167: Misc warnings in java.lang.invoke and sun.invoke.*
>>
>> http://cr.openjdk.java.net/~jrose/7117167/webrev.00/
>>
>> Removing build warnings from java.lang.invoke and sun.invoke.*, as part of the December 2011 cleanup effort.
>
> Hi John,
>
> I'm finally getting back to this. Just a couple comments:
>
> MethodHandles.java --
>
> The change here is to add a wildcard type parameter to the parameter of the unreflectConstructor() method. I believe this is a public API. Is such a change permitted? I started thinking about compatibility, but compatibility is actually a side issue. The main issue is whether it's a spec change. I think it is, but I have to admit that not really sure. But if it is a spec change, I don't think we should be making it in the context of warnings cleanup.
Foo; you are right. That will require an small Act of Congress to fix. I'll add it to my API cleanup list.
> MethodHandleImpl.java --
>
> Just an observation, really, but I puzzled for a while over the suppression of rawtypes and unchecked warnings at the construction of AllocateObject (L115). As I looked further I realized, "oh *that's* what Remi was talking about." [1] On the other hand I see your point that the class declaration AllocateObject<C> and uses of C within that class really do make sense. Perhaps this is the time when one really wants to write
>
> new AllocateObject<?>(...)
>
> but of course this is illegal. I don't have a specific recommendation to change anything here. It's just that whenever there's code that's puzzling, I'm always looking around for a better way to write it.
I am currently working on minimizing MethodHandleImpl.java, and AllocateObject may go away, so I would rather just leave it as is for the moment.
> Anyway, that's it, everything else looks fine.
Thanks!
-- John
> s'marks
>
> [1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000406.html
From kurchi.subhra.hazra at oracle.com Wed Dec 7 08:12:55 2011
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Wed, 7 Dec 2011 08:12:55 -0800 (PST)
Subject: Review Request: Warnings cleanup in sun.management and its
subpackages
In-Reply-To: <4EDD7300.4000203@oracle.com>
References: <4ED95AC4.2090905@oracle.com> <4EDD61B9.2030804@oracle.com>
<4EDD66B0.6000404@oracle.com> <4EDD7300.4000203@oracle.com>
Message-ID: <4EDF9087.7080808@oracle.com>
>
>>
>> Also, would any additional testing be required before these changes
>> go in?
>>
>
> Thanks for asking. I meant to mention it - jdk_lang and
> jdk_management test targets. java.lang.management tests are included
> in the jdk_lang target. jdk_management includes the sun.management
> tests and it also includes jmx tests which Kurchi's change didn't
> touch that area but no harm to run that and make the jprt submission
> simpler.
Hi Mandy,
I ran the jdk_land and jdk_management tests from jdk/test folder
with and without my changes. I get 8 failures. Is this normal?
Thanks,
Kurchi
From mandy.chung at oracle.com Wed Dec 7 09:48:42 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 07 Dec 2011 09:48:42 -0800
Subject: Review Request: Warnings cleanup in sun.management and its
subpackages
In-Reply-To: <4EDF9087.7080808@oracle.com>
References: <4ED95AC4.2090905@oracle.com> <4EDD61B9.2030804@oracle.com>
<4EDD66B0.6000404@oracle.com> <4EDD7300.4000203@oracle.com>
<4EDF9087.7080808@oracle.com>
Message-ID: <4EDFA6FA.4060109@oracle.com>
On 12/7/2011 8:12 AM, Kurchi Hazra wrote:
> Hi Mandy,
>
> I ran the jdk_land and jdk_management tests from jdk/test folder
> with and without my changes. I get 8 failures. Is this normal?
I haven't run the latest jdk8 tests lately. There has been works to
improve the test reliability that I think the default test set should
pass. But I believe there is some test reliability issue with a few
management tests using a hardcoded port etc that should have been
excluded in the ProblemList.
Can you send me the test logs? I'll have to take a look.
Mandy
From david.katleman at sun.com Wed Dec 7 15:19:22 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 07 Dec 2011 23:19:22 +0000
Subject: hg: jdk8/jdk8/jaxp: 2 new changesets
Message-ID: <20111207231922.814BA4763B@hg.openjdk.java.net>
Changeset: e32444f13774
Author: katleman
Date: 2011-12-06 08:43 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/e32444f13774
7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-drops
Reviewed-by: ohair, xdono, mchung
! build.properties
! make/Makefile
Changeset: 09eb517404b0
Author: katleman
Date: 2011-12-07 13:02 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/09eb517404b0
Merge
From david.katleman at sun.com Wed Dec 7 15:19:32 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 07 Dec 2011 23:19:32 +0000
Subject: hg: jdk8/jdk8/jaxws: 2 new changesets
Message-ID: <20111207231932.E1F954763C@hg.openjdk.java.net>
Changeset: 23c42f40fd3e
Author: katleman
Date: 2011-12-06 08:43 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/23c42f40fd3e
7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-drops
Reviewed-by: ohair, xdono, mchung
! build.properties
! make/Makefile
Changeset: 3d45ab79643d
Author: katleman
Date: 2011-12-07 13:02 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/3d45ab79643d
Merge
From Alan.Bateman at oracle.com Thu Dec 8 03:42:08 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 08 Dec 2011 11:42:08 +0000
Subject: Review Request: Warnings cleanup in sun.management and its
subpackages
In-Reply-To: <4EDF9087.7080808@oracle.com>
References: <4ED95AC4.2090905@oracle.com> <4EDD61B9.2030804@oracle.com>
<4EDD66B0.6000404@oracle.com> <4EDD7300.4000203@oracle.com>
<4EDF9087.7080808@oracle.com>
Message-ID: <4EE0A290.6040201@oracle.com>
On 07/12/2011 16:12, Kurchi Hazra wrote:
> :
>
> Hi Mandy,
>
> I ran the jdk_land and jdk_management tests from jdk/test folder
> with and without my changes. I get 8 failures. Is this normal?
All the tests should pass. Does 8 failures mean the same test failing on
8 hardware/OS combinations or 8 distinct failures. If the former then I
would suggest following up on serviceability-dev. Also check that you
are using the the problem list, which the jdk_lang and jdk_management
targets will use by default. If you've just run the
java/lang/management/** and sun/management/** tests without specifying
-exclude then you will be running tests that are known to have issues
(they should not be run).
-Alan.
From john_platts at hotmail.com Thu Dec 8 09:25:41 2011
From: john_platts at hotmail.com (John Platts)
Date: Thu, 8 Dec 2011 11:25:41 -0600
Subject: Optimizing arithmetic operations on processors with AVX2 support
Message-ID: <SNT116-W2262C48EB748262985C1529DB80@phx.gbl>
Here is an example of a class with an operation that can be optimized on a processor with AVX2 support:class ExampleClass {? ? public void ExampleOperation(ExampleClass y) {? ? ? ? a += y.a;? ? ? ? b *= y.b;? ? ? ? c += y.c;? ? ? ? d += y.d;? ? ? ? e += y.e;? ? ? ? f *= y.f;? ? ? ? g *= y.g;? ? ? ? h *= y.h;? ? }
? ? private int a;? ? private int b;? ? private int c;? ? private int d;? ? private int e;? ? private int f;? ? private int g;? ? private int h;}
The AVX2 instruction set includes gather instructions that can be used to read from primitive fields that are not contiguous to each other. The AVX2 instruction set will be implemented on the Intel Haswell microarchitecture processors.
In the example above, a JVM running on a processor with the AVX2 instruction set can optimize the ExampleOperation method as follows:- Reading the a, c, d, and e fields of both this and y using the VPGATHERDD instruction.- Performing the 4 addition operations simultaneously using the PADDD instruction.- Store the result of the addition operations in a, c, d, and e using the?PEXTRD instruction.- Reading the b, f, g, and h fields of both this and y using the VPGATHERDD instruction.- Performing the 4 multiplication operations simultaneously using the PMULLD instruction.- Store the result of the multiplication operations in b, f, g, and h using the PEXTRD instruction.
This optimization is perfectly legal under the Java Memory Model, since there are no volatile reads or volatile writes. However, this optimization would be illegal if a, b, c, d, e, f, g, or h were declared as volatile fields. This optimization must also respect constraints imposed by synchronized blocks, volatile reads, volatile writes, method calls, data dependencies, and strictfp semantics. This optimization would also need to be disabled if the method is being debugged by a Java debugger, as the Java debugger can step through each operation individually.
The point I am trying to illustrate is that Java programmers should not assume that the arithmetic operations performed by the ExampleOperation method are not guaranteed to execute in the sequence shown in the source code. This example also illustrates the importance of properly synchronization. Will this optimization get implemented in the Hotspot VM in the future?
From shankar at vmware.com Thu Dec 8 10:08:12 2011
From: shankar at vmware.com (Shankar Unni)
Date: Thu, 8 Dec 2011 10:08:12 -0800 (PST)
Subject: Optimizing arithmetic operations on processors with AVX2 support
In-Reply-To: <SNT116-W2262C48EB748262985C1529DB80@phx.gbl>
Message-ID: <5dfbcef2-6eee-4541-b129-155a386575a9@shankar-win1>
Such an assumption (in-order execution of statements) would be invalid even with the current memory model. There's nothing to stop the compilers from re-ordering the adds and multiplies so that they fill each other's pipeline delays.
So I don't think AVX2 brings anything new to the table in terms of perturbing the memory model.
----- Original Message -----
From: "John Platts" <john_platts at hotmail.com>
To: jdk8-dev at openjdk.java.net
Sent: Thursday, December 8, 2011 9:25:41 AM
Subject: Optimizing arithmetic operations on processors with AVX2 support
Here is an example of a class with an operation that can be optimized on a processor with AVX2 support:class ExampleClass {? ? public void ExampleOperation(ExampleClass y) {? ? ? ? a += y.a;? ? ? ? b *= y.b;? ? ? ? c += y.c;? ? ? ? d += y.d;? ? ? ? e += y.e;? ? ? ? f *= y.f;? ? ? ? g *= y.g;? ? ? ? h *= y.h;? ? }
? ? private int a;? ? private int b;? ? private int c;? ? private int d;? ? private int e;? ? private int f;? ? private int g;? ? private int h;}
The AVX2 instruction set includes gather instructions that can be used to read from primitive fields that are not contiguous to each other. The AVX2 instruction set will be implemented on the Intel Haswell microarchitecture processors.
In the example above, a JVM running on a processor with the AVX2 instruction set can optimize the ExampleOperation method as follows:- Reading the a, c, d, and e fields of both this and y using the VPGATHERDD instruction.- Performing the 4 addition operations simultaneously using the PADDD instruction.- Store the result of the addition operations in a, c, d, and e using the?PEXTRD instruction.- Reading the b, f, g, and h fields of both this and y using the VPGATHERDD instruction.- Performing the 4 multiplication operations simultaneously using the PMULLD instruction.- Store the result of the multiplication operations in b, f, g, and h using the PEXTRD instruction.
This optimization is perfectly legal under the Java Memory Model, since there are no volatile reads or volatile writes. However, this optimization would be illegal if a, b, c, d, e, f, g, or h were declared as volatile fields. This optimization must also respect constraints imposed by synchronized blocks, volatile reads, volatile writes, method calls, data dependencies, and strictfp semantics. This optimization would also need to be disabled if the method is being debugged by a Java debugger, as the Java debugger can step through each operation individually.
The point I am trying to illustrate is that Java programmers should not assume that the arithmetic operations performed by the ExampleOperation method are not guaranteed to execute in the sequence shown in the source code. This example also illustrates the importance of properly synchronization. Will this optimization get implemented in the Hotspot VM in the future?
From john_platts at hotmail.com Thu Dec 8 10:41:12 2011
From: john_platts at hotmail.com (John Platts)
Date: Thu, 8 Dec 2011 12:41:12 -0600
Subject: Optimizing arithmetic operations on processors with AVX2 support
In-Reply-To: <5dfbcef2-6eee-4541-b129-155a386575a9@shankar-win1>
References: <SNT116-W2262C48EB748262985C1529DB80@phx.gbl>,
<5dfbcef2-6eee-4541-b129-155a386575a9@shankar-win1>
Message-ID: <SNT116-W2686C590E30FF014C68B6C9DB80@phx.gbl>
I actually do agree with what Shankar said regarding the current Java memory model. However, the point that I was trying to illustrate is that the JIT compiler of a JVM can use the AVX2, SSE2, SSE3, and SSE4.1 instructions instead of the ordinary arithmetic instructions to optimize the performance of integer arithmetic operations on x86 processors with the AVX2 instruction set. I was also intending to show an example of how arithmetic operations can be re-ordered by a JVM implementation without violating the Java Memory Model.
----------------------------------------
> Date: Thu, 8 Dec 2011 10:08:12 -0800
> From: shankar at vmware.com
> To: john_platts at hotmail.com
> CC: jdk8-dev at openjdk.java.net
> Subject: Re: Optimizing arithmetic operations on processors with AVX2 support
>
> Such an assumption (in-order execution of statements) would be invalid even with the current memory model. There's nothing to stop the compilers from re-ordering the adds and multiplies so that they fill each other's pipeline delays.
>
> So I don't think AVX2 brings anything new to the table in terms of perturbing the memory model.
>
> ----- Original Message -----
> From: "John Platts" <john_platts at hotmail.com>
> To: jdk8-dev at openjdk.java.net
> Sent: Thursday, December 8, 2011 9:25:41 AM
> Subject: Optimizing arithmetic operations on processors with AVX2 support
>
>
> Here is an example of a class with an operation that can be optimized on a processor with AVX2 support:class ExampleClass { public void ExampleOperation(ExampleClass y) { a += y.a; b *= y.b; c += y.c; d += y.d; e += y.e; f *= y.f; g *= y.g; h *= y.h; }
> private int a; private int b; private int c; private int d; private int e; private int f; private int g; private int h;}
> The AVX2 instruction set includes gather instructions that can be used to read from primitive fields that are not contiguous to each other. The AVX2 instruction set will be implemented on the Intel Haswell microarchitecture processors.
> In the example above, a JVM running on a processor with the AVX2 instruction set can optimize the ExampleOperation method as follows:- Reading the a, c, d, and e fields of both this and y using the VPGATHERDD instruction.- Performing the 4 addition operations simultaneously using the PADDD instruction.- Store the result of the addition operations in a, c, d, and e using the PEXTRD instruction.- Reading the b, f, g, and h fields of both this and y using the VPGATHERDD instruction.- Performing the 4 multiplication operations simultaneously using the PMULLD instruction.- Store the result of the multiplication operations in b, f, g, and h using the PEXTRD instruction.
> This optimization is perfectly legal under the Java Memory Model, since there are no volatile reads or volatile writes. However, this optimization would be illegal if a, b, c, d, e, f, g, or h were declared as volatile fields. This optimization must also respect constraints imposed by synchronized blocks, volatile reads, volatile writes, method calls, data dependencies, and strictfp semantics. This optimization would also need to be disabled if the method is being debugged by a Java debugger, as the Java debugger can step through each operation individually.
> The point I am trying to illustrate is that Java programmers should not assume that the arithmetic operations performed by the ExampleOperation method are not guaranteed to execute in the sequence shown in the source code. This example also illustrates the importance of properly synchronization. Will this optimization get implemented in the Hotspot VM in the future?
From artem.ananiev at oracle.com Thu Dec 8 10:59:42 2011
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Thu, 08 Dec 2011 22:59:42 +0400
Subject: Optimizing arithmetic operations on processors with AVX2 support
In-Reply-To: <SNT116-W2262C48EB748262985C1529DB80@phx.gbl>
References: <SNT116-W2262C48EB748262985C1529DB80@phx.gbl>
Message-ID: <4EE1091E.4020803@oracle.com>
Shouldn't it be discussed on the hotspot-dev alias?
Thanks,
Artem
On 12/8/2011 9:25 PM, John Platts wrote:
>
> Here is an example of a class with an operation that can be optimized on a processor with AVX2 support:class ExampleClass { public void ExampleOperation(ExampleClass y) { a += y.a; b *= y.b; c += y.c; d += y.d; e += y.e; f *= y.f; g *= y.g; h *= y.h; }
> private int a; private int b; private int c; private int d; private int e; private int f; private int g; private int h;}
> The AVX2 instruction set includes gather instructions that can be used to read from primitive fields that are not contiguous to each other. The AVX2 instruction set will be implemented on the Intel Haswell microarchitecture processors.
> In the example above, a JVM running on a processor with the AVX2 instruction set can optimize the ExampleOperation method as follows:- Reading the a, c, d, and e fields of both this and y using the VPGATHERDD instruction.- Performing the 4 addition operations simultaneously using the PADDD instruction.- Store the result of the addition operations in a, c, d, and e using the PEXTRD instruction.- Reading the b, f, g, and h fields of both this and y using the VPGATHERDD instruction.- Performing the 4 multiplication operations simultaneously using the PMULLD instruction.- Store the result of the multiplication operations in b, f, g, and h using the PEXTRD instruction.
> This optimization is perfectly legal under the Java Memory Model, since there are no volatile reads or volatile writes. However, this optimization would be illegal if a, b, c, d, e, f, g, or h were declared as volatile fields. This optimization must also respect constraints imposed by synchronized blocks, volatile reads, volatile writes, method calls, data dependencies, and strictfp semantics. This optimization would also need to be disabled if the method is being debugged by a Java debugger, as the Java debugger can step through each operation individually.
> The point I am trying to illustrate is that Java programmers should not assume that the arithmetic operations performed by the ExampleOperation method are not guaranteed to execute in the sequence shown in the source code. This example also illustrates the importance of properly synchronization. Will this optimization get implemented in the Hotspot VM in the future?
From paul.hohensee at oracle.com Thu Dec 8 10:59:55 2011
From: paul.hohensee at oracle.com (Paul Hohensee)
Date: Thu, 08 Dec 2011 13:59:55 -0500
Subject: Optimizing arithmetic operations on processors with AVX2 support
In-Reply-To: <SNT116-W2686C590E30FF014C68B6C9DB80@phx.gbl>
References: <SNT116-W2262C48EB748262985C1529DB80@phx.gbl>,
<5dfbcef2-6eee-4541-b129-155a386575a9@shankar-win1>
<SNT116-W2686C590E30FF014C68B6C9DB80@phx.gbl>
Message-ID: <4EE1092B.2050408@oracle.com>
cc'ing hotspot-dev.
Paul
On 12/8/11 1:41 PM, John Platts wrote:
> I actually do agree with what Shankar said regarding the current Java memory model. However, the point that I was trying to illustrate is that the JIT compiler of a JVM can use the AVX2, SSE2, SSE3, and SSE4.1 instructions instead of the ordinary arithmetic instructions to optimize the performance of integer arithmetic operations on x86 processors with the AVX2 instruction set. I was also intending to show an example of how arithmetic operations can be re-ordered by a JVM implementation without violating the Java Memory Model.
>
> ----------------------------------------
>> Date: Thu, 8 Dec 2011 10:08:12 -0800
>> From: shankar at vmware.com
>> To: john_platts at hotmail.com
>> CC: jdk8-dev at openjdk.java.net
>> Subject: Re: Optimizing arithmetic operations on processors with AVX2 support
>>
>> Such an assumption (in-order execution of statements) would be invalid even with the current memory model. There's nothing to stop the compilers from re-ordering the adds and multiplies so that they fill each other's pipeline delays.
>>
>> So I don't think AVX2 brings anything new to the table in terms of perturbing the memory model.
>>
>> ----- Original Message -----
>> From: "John Platts"<john_platts at hotmail.com>
>> To: jdk8-dev at openjdk.java.net
>> Sent: Thursday, December 8, 2011 9:25:41 AM
>> Subject: Optimizing arithmetic operations on processors with AVX2 support
>>
>>
>> Here is an example of a class with an operation that can be optimized on a processor with AVX2 support:class ExampleClass { public void ExampleOperation(ExampleClass y) { a += y.a; b *= y.b; c += y.c; d += y.d; e += y.e; f *= y.f; g *= y.g; h *= y.h; }
>> private int a; private int b; private int c; private int d; private int e; private int f; private int g; private int h;}
>> The AVX2 instruction set includes gather instructions that can be used to read from primitive fields that are not contiguous to each other. The AVX2 instruction set will be implemented on the Intel Haswell microarchitecture processors.
>> In the example above, a JVM running on a processor with the AVX2 instruction set can optimize the ExampleOperation method as follows:- Reading the a, c, d, and e fields of both this and y using the VPGATHERDD instruction.- Performing the 4 addition operations simultaneously using the PADDD instruction.- Store the result of the addition operations in a, c, d, and e using the PEXTRD instruction.- Reading the b, f, g, and h fields of both this and y using the VPGATHERDD instruction.- Performing the 4 multiplication operations simultaneously using the PMULLD instruction.- Store the result of the multiplication operations in b, f, g, and h using the PEXTRD instruction.
>> This optimization is perfectly legal under the Java Memory Model, since there are no volatile reads or volatile writes. However, this optimization would be illegal if a, b, c, d, e, f, g, or h were declared as volatile fields. This optimization must also respect constraints imposed by synchronized blocks, volatile reads, volatile writes, method calls, data dependencies, and strictfp semantics. This optimization would also need to be disabled if the method is being debugged by a Java debugger, as the Java debugger can step through each operation individually.
>> The point I am trying to illustrate is that Java programmers should not assume that the arithmetic operations performed by the ExampleOperation method are not guaranteed to execute in the sequence shown in the source code. This example also illustrates the importance of properly synchronization. Will this optimization get implemented in the Hotspot VM in the future?
>
From vladimir.kozlov at oracle.com Thu Dec 8 11:10:39 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 08 Dec 2011 11:10:39 -0800
Subject: Optimizing arithmetic operations on processors with AVX2 support
In-Reply-To: <SNT116-W2686C590E30FF014C68B6C9DB80@phx.gbl>
References: <SNT116-W2262C48EB748262985C1529DB80@phx.gbl>,
<5dfbcef2-6eee-4541-b129-155a386575a9@shankar-win1>
<SNT116-W2686C590E30FF014C68B6C9DB80@phx.gbl>
Message-ID: <4EE10BAF.5030801@oracle.com>
First, there is no AVX2 hardware yet. Second, generating JIT code for vector
arithmetic is on our TODO list but we can't say when it will be done.
Regards,
Vladimir
John Platts wrote:
> I actually do agree with what Shankar said regarding the current Java memory model. However, the point that I was trying to illustrate is that the JIT compiler of a JVM can use the AVX2, SSE2, SSE3, and SSE4.1 instructions instead of the ordinary arithmetic instructions to optimize the performance of integer arithmetic operations on x86 processors with the AVX2 instruction set. I was also intending to show an example of how arithmetic operations can be re-ordered by a JVM implementation without violating the Java Memory Model.
>
> ----------------------------------------
>> Date: Thu, 8 Dec 2011 10:08:12 -0800
>> From: shankar at vmware.com
>> To: john_platts at hotmail.com
>> CC: jdk8-dev at openjdk.java.net
>> Subject: Re: Optimizing arithmetic operations on processors with AVX2 support
>>
>> Such an assumption (in-order execution of statements) would be invalid even with the current memory model. There's nothing to stop the compilers from re-ordering the adds and multiplies so that they fill each other's pipeline delays.
>>
>> So I don't think AVX2 brings anything new to the table in terms of perturbing the memory model.
>>
>> ----- Original Message -----
>> From: "John Platts" <john_platts at hotmail.com>
>> To: jdk8-dev at openjdk.java.net
>> Sent: Thursday, December 8, 2011 9:25:41 AM
>> Subject: Optimizing arithmetic operations on processors with AVX2 support
>>
>>
>> Here is an example of a class with an operation that can be optimized on a processor with AVX2 support:class ExampleClass { public void ExampleOperation(ExampleClass y) { a += y.a; b *= y.b; c += y.c; d += y.d; e += y.e; f *= y.f; g *= y.g; h *= y.h; }
>> private int a; private int b; private int c; private int d; private int e; private int f; private int g; private int h;}
>> The AVX2 instruction set includes gather instructions that can be used to read from primitive fields that are not contiguous to each other. The AVX2 instruction set will be implemented on the Intel Haswell microarchitecture processors.
>> In the example above, a JVM running on a processor with the AVX2 instruction set can optimize the ExampleOperation method as follows:- Reading the a, c, d, and e fields of both this and y using the VPGATHERDD instruction.- Performing the 4 addition operations simultaneously using the PADDD instruction.- Store the result of the addition operations in a, c, d, and e using the PEXTRD instruction.- Reading the b, f, g, and h fields of both this and y using the VPGATHERDD instruction.- Performing the 4 multiplication operations simultaneously using the PMULLD instruction.- Store the result of the multiplication operations in b, f, g, and h using the PEXTRD instruction.
>> This optimization is perfectly legal under the Java Memory Model, since there are no volatile reads or volatile writes. However, this optimization would be illegal if a, b, c, d, e, f, g, or h were declared as volatile fields. This optimization must also respect constraints imposed by synchronized blocks, volatile reads, volatile writes, method calls, data dependencies, and strictfp semantics. This optimization would also need to be disabled if the method is being debugged by a Java debugger, as the Java debugger can step through each operation individually.
>> The point I am trying to illustrate is that Java programmers should not assume that the arithmetic operations performed by the ExampleOperation method are not guaranteed to execute in the sequence shown in the source code. This example also illustrates the importance of properly synchronization. Will this optimization get implemented in the Hotspot VM in the future?
>
From martijnverburg at gmail.com Thu Dec 8 12:41:31 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 8 Dec 2011 20:41:31 +0000
Subject: Tests (Was Warnings Cleanup in java.util.<various> (more from
hack day))
In-Reply-To: <4EDA4204.2080108@oracle.com>
References: <CAP7YuASf+6mzmikMv7ki=+gTY_7ZpBiSj7F+zC=sDYukx16RUg@mail.gmail.com>
<4EDA4204.2080108@oracle.com>
Message-ID: <CAP7YuAR_BeF5hiq+MsN1rS8tYtBuHbNFUXgZJXJ6f1OvJ46cKA@mail.gmail.com>
Hi Alan/All,
On 3 December 2011 15:36, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 03/12/2011 11:27, Martijn Verburg wrote:
>>
>> Hi all,
>>
>> So the recent warnings clean up exercise got me thinking about the
>> approach we took and how we could make it safer by applying/running
>> tests in some of these areas. I'm very new to the OpenJDK, but I
>> figure there must be a suite of tests (for the TCK if nothing else).
>> Is that the set of tests that are typically run? Or is there another
>> test suite that can be run/added to?
>>
>> For example I feel that could/should have written a unit test for the
>> write method in the Manifest class that I had my recent brain melt in
>> :-)
>>
> There are lots of tests in the jdk repository (lots in langtools and some
> tests in the hotspot repository too). In order to run them then you'll need
> the jtreg test harness [1]. We probably need better documentation on the
> OpenJDK site for how to run the tests but one useful thing to know is that
> the make file in jdk/test directory has make targets that run the tests for
> many areas of the libraries. In this case you are working on java.util
> classes and we have a jdk_util target in the make file that runs the tests
> in jdk/test/java/util/**. You can run them with:
>
> make JT_HOME=<jtreg-location> jdk_util
>
> This locates your build in the default output directory so if it's somewhere
> else when you'll need to specify PRODUCT_HOME=<myjdk> to point it to the JDK
> that you are testing.
>
> It's possible that your sponsor (maybe Sherman in this case) will run the
> tests before pushing the changes but we need to get more people used to
> running the tests too.
>
> -Alan.
>
> [1] http://openjdk.java.net/jtreg/
Thanks for the set-up instructions, between that and the jtreg site I
was able to get them running.
I'll probably have more specific questions later on, but in the mean
time I'd like to be able to
contribute some documentation steps so that especially when community
enthusiasts help out
with things like 'javac warning clean-up' they do so with an extra safety net.
I pinged the guide-discuss list as I thought the developers guide
should be where this goes. It
could be Warlocks dilemma, but I got not reply there, is the
developers guide still the right place? Or
is there a wiki that now holds the equivalent developers guide?
Apologies for asking on this list, but wasn't sure what another
appropriate list would be, OpenJDK
has a lot of lists ;-).
Cheers,
Martijn
From martijnverburg at gmail.com Thu Dec 8 12:47:34 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 8 Dec 2011 20:47:34 +0000
Subject: OpenJDK adoption by Java User Groups
Message-ID: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com>
Hi all,
I think the experiment was pretty successful the other night and Mike
and I have also figured out some ways to
streamline the process even further for future events (pre-built VMs
with the initial build already executed once
work pretty well if you're running adequate hardware).
We're keeping the VM up-to-date with jtreg and the latest commits and
will be organising a regular monthly
OpenJDK hack night for the LJC to work on low hanging fruit such as
javac warnings.
A few of the more enthusiastic folk will probably keeping submitting
ad-hoc patches, but what would you like us
to work on as a group next time? There is still ~8500 warnings last
time I checked so we'd probably be quite
happy to run through a similar exercise again.
Once we've found our feet (and made sure we're not making life
difficult for all of you) then we'll spread the
program further to other JUGs.
We're also exploring where we can help out with documentation, but
I'll cover that separately.
Cheers,
Martijn
From jonathan.gibbons at oracle.com Thu Dec 8 13:22:39 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 08 Dec 2011 13:22:39 -0800
Subject: Tests (Was Warnings Cleanup in java.util.<various> (more from
hack day))
In-Reply-To: <CAP7YuAR_BeF5hiq+MsN1rS8tYtBuHbNFUXgZJXJ6f1OvJ46cKA@mail.gmail.com>
References: <CAP7YuASf+6mzmikMv7ki=+gTY_7ZpBiSj7F+zC=sDYukx16RUg@mail.gmail.com> <4EDA4204.2080108@oracle.com>
<CAP7YuAR_BeF5hiq+MsN1rS8tYtBuHbNFUXgZJXJ6f1OvJ46cKA@mail.gmail.com>
Message-ID: <4EE12A9F.5090204@oracle.com>
On 12/08/2011 12:41 PM, Martijn Verburg wrote:
> Hi Alan/All,
>
> On 3 December 2011 15:36, Alan Bateman<Alan.Bateman at oracle.com> wrote:
>> On 03/12/2011 11:27, Martijn Verburg wrote:
>>> Hi all,
>>>
>>> So the recent warnings clean up exercise got me thinking about the
>>> approach we took and how we could make it safer by applying/running
>>> tests in some of these areas. I'm very new to the OpenJDK, but I
>>> figure there must be a suite of tests (for the TCK if nothing else).
>>> Is that the set of tests that are typically run? Or is there another
>>> test suite that can be run/added to?
>>>
>>> For example I feel that could/should have written a unit test for the
>>> write method in the Manifest class that I had my recent brain melt in
>>> :-)
>>>
>> There are lots of tests in the jdk repository (lots in langtools and some
>> tests in the hotspot repository too). In order to run them then you'll need
>> the jtreg test harness [1]. We probably need better documentation on the
>> OpenJDK site for how to run the tests but one useful thing to know is that
>> the make file in jdk/test directory has make targets that run the tests for
>> many areas of the libraries. In this case you are working on java.util
>> classes and we have a jdk_util target in the make file that runs the tests
>> in jdk/test/java/util/**. You can run them with:
>>
>> make JT_HOME=<jtreg-location> jdk_util
>>
>> This locates your build in the default output directory so if it's somewhere
>> else when you'll need to specify PRODUCT_HOME=<myjdk> to point it to the JDK
>> that you are testing.
>>
>> It's possible that your sponsor (maybe Sherman in this case) will run the
>> tests before pushing the changes but we need to get more people used to
>> running the tests too.
>>
>> -Alan.
>>
>> [1] http://openjdk.java.net/jtreg/
> Thanks for the set-up instructions, between that and the jtreg site I
> was able to get them running.
>
> I'll probably have more specific questions later on, but in the mean
> time I'd like to be able to
> contribute some documentation steps so that especially when community
> enthusiasts help out
> with things like 'javac warning clean-up' they do so with an extra safety net.
>
> I pinged the guide-discuss list as I thought the developers guide
> should be where this goes. It
> could be Warlocks dilemma, but I got not reply there, is the
> developers guide still the right place? Or
> is there a wiki that now holds the equivalent developers guide?
>
> Apologies for asking on this list, but wasn't sure what another
> appropriate list would be, OpenJDK
> has a lot of lists ;-).
>
> Cheers,
> Martijn
Martijn,
I think the Developers Guide is the right place to put this sort of
documentation, and ideally the guide-discuss list would be the place to
discuss it. In the meantime, I suggest creating documentation so that we
can post it "somewhere" where it can be referenced by others wanting to
join in the fun.
-- Jon
From jonathan.gibbons at oracle.com Thu Dec 8 13:38:43 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 08 Dec 2011 13:38:43 -0800
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com>
Message-ID: <4EE12E63.7060707@oracle.com>
On 12/08/2011 12:47 PM, Martijn Verburg wrote:
> Hi all,
>
> I think the experiment was pretty successful the other night and Mike
> and I have also figured out some ways to
> streamline the process even further for future events (pre-built VMs
> with the initial build already executed once
> work pretty well if you're running adequate hardware).
>
> We're keeping the VM up-to-date with jtreg and the latest commits and
> will be organising a regular monthly
> OpenJDK hack night for the LJC to work on low hanging fruit such as
> javac warnings.
>
> A few of the more enthusiastic folk will probably keeping submitting
> ad-hoc patches, but what would you like us
> to work on as a group next time? There is still ~8500 warnings last
> time I checked so we'd probably be quite
> happy to run through a similar exercise again.
>
> Once we've found our feet (and made sure we're not making life
> difficult for all of you) then we'll spread the
> program further to other JUGs.
>
> We're also exploring where we can help out with documentation, but
> I'll cover that separately.
>
> Cheers,
> Martijn
Martijn,
There were a number of surprises on Warnings Day last week.
One was the amount of enthusiasm. Another was the difficulty of
staying within the prescribed bounds, such as "no public API changes".
Which brings me to a suggestion I've been meaning to make for a
while, and is relevant here.
For changes to the OpenJDK code itself, you can see the sort of
controls we go through to make sure nothing bad happens. That can
be somewhat limiting for folk who want more creative freedom ;-)
One possibility is the development of tools which are not themselves
part of the OpenJDK itself, but which are useful to folk working on
OpenJDK. One such category of tools is intelligent comparison tools.
Given two copies of a library (such as rt.jar and tools.jar), analyze
them to report on differences. A bunch of different comparison
tests could be done:
-- have any public API signatures changed (where "public" means
"documented/published")
-- have any public API signatures changed (where "public" means
the Java access modifier)
-- if any signatures have changed, are the changes binary compatible,
source compatible, etc.
[See http://blogs.oracle.com/darcy/entry/kinds_of_compatibility]
-- have any method bodies changed
-- and so on
I wonder it would make sense for interested groups, such as JUGs,
to team up and take on such projects.
-- Jon
From xiomara.jayasena at oracle.com Thu Dec 8 20:12:14 2011
From: xiomara.jayasena at oracle.com (Xiomara Jayasena)
Date: Thu, 8 Dec 2011 20:12:14 -0800 (PST)
Subject: Summary: JDK8 Warnings Cleanup Day
Message-ID: <a6d10575-d70b-40df-97cf-b70647e6a5bf@default>
Hi,
Last week?we held?[1] the first (of hopefully several!) JDK8 Warnings Cleanup Days (WCD), where the OpenJDK community collaborated to reduce the number of warnings in the JDK8 source.?
We started with just over 10,000 warnings before WCD. The checked-in changesets fixed a total of?*1,498 * warnings, leaving 8,515.
The pending changesets (with webrevs) would fix and additional 674 warnings, giving a grand total of *2,172* warning fixed, bringing us down to 7,841 overall. Great job to everyone who participated!!
If you would like to see the further breakdown of the changes, you can go to the warnings cleanup wiki [2] and see them there.
We learned a lot from this first experience and appreciated how quickly the community responded to our request for help even with such short notice.
Thanks again!
-Xiomara
[1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000302.html
[2] http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
From jonathan.gibbons at oracle.com Thu Dec 8 20:56:23 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 08 Dec 2011 20:56:23 -0800
Subject: Summary: JDK8 Warnings Cleanup Day
In-Reply-To: <a6d10575-d70b-40df-97cf-b70647e6a5bf@default>
References: <a6d10575-d70b-40df-97cf-b70647e6a5bf@default>
Message-ID: <4EE194F7.6030504@oracle.com>
Wow, most impressive!
-- Jon
On 12/08/2011 08:12 PM, Xiomara Jayasena wrote:
> Hi,
>
> Last week we held [1] the first (of hopefully several!) JDK8 Warnings Cleanup Days (WCD), where the OpenJDK community collaborated to reduce the number of warnings in the JDK8 source.
>
> We started with just over 10,000 warnings before WCD. The checked-in changesets fixed a total of *1,498 * warnings, leaving 8,515.
>
> The pending changesets (with webrevs) would fix and additional 674 warnings, giving a grand total of *2,172* warning fixed, bringing us down to 7,841 overall. Great job to everyone who participated!!
>
> If you would like to see the further breakdown of the changes, you can go to the warnings cleanup wiki [2] and see them there.
>
> We learned a lot from this first experience and appreciated how quickly the community responded to our request for help even with such short notice.
>
> Thanks again!
> -Xiomara
>
> [1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000302.html
> [2] http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
From sebastian.sickelmann at gmx.de Thu Dec 8 21:20:27 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 09 Dec 2011 06:20:27 +0100
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <4EE12E63.7060707@oracle.com>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com>
<4EE12E63.7060707@oracle.com>
Message-ID: <4EE19A9B.1090202@gmx.de>
Am 08.12.2011 22:38, schrieb Jonathan Gibbons:
> On 12/08/2011 12:47 PM, Martijn Verburg wrote:
>> Hi all,
>>
>> I think the experiment was pretty successful the other night and Mike
>> and I have also figured out some ways to
>> streamline the process even further for future events (pre-built VMs
>> with the initial build already executed once
>> work pretty well if you're running adequate hardware).
>>
>> We're keeping the VM up-to-date with jtreg and the latest commits and
>> will be organising a regular monthly
>> OpenJDK hack night for the LJC to work on low hanging fruit such as
>> javac warnings.
>>
>> A few of the more enthusiastic folk will probably keeping submitting
>> ad-hoc patches, but what would you like us
>> to work on as a group next time? There is still ~8500 warnings last
>> time I checked so we'd probably be quite
>> happy to run through a similar exercise again.
>>
>> Once we've found our feet (and made sure we're not making life
>> difficult for all of you) then we'll spread the
>> program further to other JUGs.
>>
>> We're also exploring where we can help out with documentation, but
>> I'll cover that separately.
>>
>> Cheers,
>> Martijn
>
> Martijn,
>
> There were a number of surprises on Warnings Day last week.
> One was the amount of enthusiasm. Another was the difficulty of
> staying within the prescribed bounds, such as "no public API changes".
>
> Which brings me to a suggestion I've been meaning to make for a
> while, and is relevant here.
>
> For changes to the OpenJDK code itself, you can see the sort of
> controls we go through to make sure nothing bad happens. That can
> be somewhat limiting for folk who want more creative freedom ;-)
> One possibility is the development of tools which are not themselves
> part of the OpenJDK itself, but which are useful to folk working on
> OpenJDK. One such category of tools is intelligent comparison tools.
> Given two copies of a library (such as rt.jar and tools.jar), analyze
> them to report on differences. A bunch of different comparison
> tests could be done:
> -- have any public API signatures changed (where "public" means
> "documented/published")
> -- have any public API signatures changed (where "public" means
> the Java access modifier)
> -- if any signatures have changed, are the changes binary compatible,
> source compatible, etc.
> [See http://blogs.oracle.com/darcy/entry/kinds_of_compatibility]
> -- have any method bodies changed
> -- and so on
>
> I wonder it would make sense for interested groups, such as JUGs,
> to team up and take on such projects.
>
> -- Jon
Another fine thing would be to have an public reachable review system.
Like gerrit(for git) just for mercurial. I think inside of Oracle there
is such
a system, at least most of the webrevs from oracle folks are hosted on
a server with the name http://cr.openjdk.java.net.
Providing patches through webrev is not the easiest part for anyone
who can move the OpenJdk forward. I think this is true at least for
those who uses windows as there primary development plattform.
Pushing to hg server that creates webrev for them would be really cool.
-- Sebastian
From martijnverburg at gmail.com Fri Dec 9 01:41:52 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 9 Dec 2011 09:41:52 +0000
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <4EE12E63.7060707@oracle.com>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com>
<4EE12E63.7060707@oracle.com>
Message-ID: <CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com>
>> Hi all,
>>
>> I think the experiment was pretty successful the other night and Mike
>> and I have also figured out some ways to
>> streamline the process even further for future events (pre-built VMs
>> with the initial build already executed once
>> work pretty well if you're running adequate hardware).
>>
>> We're keeping the VM up-to-date with jtreg and the latest commits and
>> will be organising a regular monthly
>> OpenJDK hack night for the LJC to work on low hanging fruit such as
>> javac warnings.
>>
>> A few of the more enthusiastic folk will probably keeping submitting
>> ad-hoc patches, but what would you like us
>> to work on as a group next time? ?There is still ~8500 warnings last
>> time I checked so we'd probably be quite
>> happy to run through a similar exercise again.
>>
>> Once we've found our feet (and made sure we're not making life
>> difficult for all of you) then we'll spread the
>> program further to other JUGs.
>>
>> We're also exploring where we can help out with documentation, but
>> I'll cover that separately.
>>
>> Cheers,
>> Martijn
>
>
> Martijn,
>
> There were a number of surprises on Warnings Day last week.
> One was the amount of enthusiasm. Another was the difficulty of
> staying within the prescribed bounds, such as "no public API changes".
>
> Which brings me to a suggestion I've been meaning to make for a
> while, and is relevant here.
>
> For changes to the OpenJDK code itself, you can see the sort of
> controls we go through to make sure nothing bad happens. That can
> be somewhat limiting for folk who want more creative freedom ;-)
> One possibility is the development of tools which are not themselves
> part of the OpenJDK itself, but which are useful to folk working on
> OpenJDK. One such category of tools is intelligent comparison tools.
> Given two copies of a library (such as rt.jar and tools.jar), analyze
> them to report on differences. A bunch of different comparison
> tests could be done:
> -- have any public API signatures changed (where "public" means
> ? ?"documented/published")
> -- have any public API signatures changed (where "public" means
> ? ?the Java access modifier)
> -- if any signatures have changed, are the changes binary compatible,
> ? source compatible, etc.
> ? [See http://blogs.oracle.com/darcy/entry/kinds_of_compatibility]
> -- have any method bodies changed
> -- and so on
>
> I wonder it would make sense for interested groups, such as JUGs,
> to team up and take on such projects.
>
> -- Jon
We could certainly list projects like this on a Adopt OpenJDK site and
work with
the JUG leaders to put together teams. There's never any guarantee that a
particular project will get picked up, but with such a diverse group
of developers
there would hopefully be some sort of adoption yes.
Cheers,
Martijn
From martijnverburg at gmail.com Fri Dec 9 01:45:54 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 9 Dec 2011 09:45:54 +0000
Subject: Summary: JDK8 Warnings Cleanup Day
In-Reply-To: <4EE194F7.6030504@oracle.com>
References: <a6d10575-d70b-40df-97cf-b70647e6a5bf@default>
<4EE194F7.6030504@oracle.com>
Message-ID: <CAP7YuASXevW6ehP2Z=MOP5arkJh5TsD=V_w1SqRdN4i7dMHpyw@mail.gmail.com>
Glad to hear there was a good result out of it - we certainly learned
a lot and had a good deal of fun as well! - M
On 9 December 2011 04:56, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> Wow, most impressive!
>
> -- Jon
>
>
> On 12/08/2011 08:12 PM, Xiomara Jayasena wrote:
>>
>> Hi,
>>
>> Last week we held [1] the first (of hopefully several!) JDK8 Warnings
>> Cleanup Days (WCD), where the OpenJDK community collaborated to reduce the
>> number of warnings in the JDK8 source.
>> We started with just over 10,000 warnings before WCD. The checked-in
>> changesets fixed a total of *1,498 * warnings, leaving 8,515.
>>
>> The pending changesets (with webrevs) would fix and additional 674
>> warnings, giving a grand total of *2,172* warning fixed, bringing us down to
>> 7,841 overall. ?Great job to everyone who participated!!
>>
>> If you would like to see the further breakdown of the changes, you can go
>> to the warnings cleanup wiki [2] and see them there.
>>
>> We learned a lot from this first experience and appreciated how quickly
>> the community responded to our request for help even with such short notice.
>>
>> Thanks again!
>> -Xiomara
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000302.html
>> [2]
>> http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
>
>
From martijnverburg at gmail.com Fri Dec 9 02:16:16 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 9 Dec 2011 10:16:16 +0000
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com>
<4EE12E63.7060707@oracle.com>
<CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com>
Message-ID: <CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com>
>> Martijn,
>>
>> There were a number of surprises on Warnings Day last week.
>> One was the amount of enthusiasm. Another was the difficulty of
>> staying within the prescribed bounds, such as "no public API changes".
>>
>> Which brings me to a suggestion I've been meaning to make for a
>> while, and is relevant here.
>>
>> For changes to the OpenJDK code itself, you can see the sort of
>> controls we go through to make sure nothing bad happens. That can
>> be somewhat limiting for folk who want more creative freedom ;-)
>> One possibility is the development of tools which are not themselves
>> part of the OpenJDK itself, but which are useful to folk working on
>> OpenJDK. One such category of tools is intelligent comparison tools.
>> Given two copies of a library (such as rt.jar and tools.jar), analyze
>> them to report on differences. A bunch of different comparison
>> tests could be done:
>> -- have any public API signatures changed (where "public" means
>> ? ?"documented/published")
>> -- have any public API signatures changed (where "public" means
>> ? ?the Java access modifier)
>> -- if any signatures have changed, are the changes binary compatible,
>> ? source compatible, etc.
>> ? [See http://blogs.oracle.com/darcy/entry/kinds_of_compatibility]
>> -- have any method bodies changed
>> -- and so on
>>
>> I wonder it would make sense for interested groups, such as JUGs,
>> to team up and take on such projects.
>>
>> -- Jon
>
> We could certainly list projects like this on a Adopt OpenJDK site and
> work with
> the JUG leaders to put together teams. ?There's never any guarantee that a
> particular project will get picked up, but with such a diverse group
> of developers there would hopefully be some sort of adoption yes.
To add further to this, please send myself or Mike Barker any ideas you'd
like to see tackled and we'll get them added to the list.
Cheers,
Martijn
From forax at univ-mlv.fr Fri Dec 9 02:23:34 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Fri, 09 Dec 2011 11:23:34 +0100
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com>
<4EE12E63.7060707@oracle.com>
<CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com>
<CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com>
Message-ID: <4EE1E1A6.3060404@univ-mlv.fr>
On 12/09/2011 11:16 AM, Martijn Verburg wrote:
>>> Martijn,
>>>
>>> There were a number of surprises on Warnings Day last week.
>>> One was the amount of enthusiasm. Another was the difficulty of
>>> staying within the prescribed bounds, such as "no public API changes".
>>>
>>> Which brings me to a suggestion I've been meaning to make for a
>>> while, and is relevant here.
>>>
>>> For changes to the OpenJDK code itself, you can see the sort of
>>> controls we go through to make sure nothing bad happens. That can
>>> be somewhat limiting for folk who want more creative freedom ;-)
>>> One possibility is the development of tools which are not themselves
>>> part of the OpenJDK itself, but which are useful to folk working on
>>> OpenJDK. One such category of tools is intelligent comparison tools.
>>> Given two copies of a library (such as rt.jar and tools.jar), analyze
>>> them to report on differences. A bunch of different comparison
>>> tests could be done:
>>> -- have any public API signatures changed (where "public" means
>>> "documented/published")
>>> -- have any public API signatures changed (where "public" means
>>> the Java access modifier)
>>> -- if any signatures have changed, are the changes binary compatible,
>>> source compatible, etc.
>>> [See http://blogs.oracle.com/darcy/entry/kinds_of_compatibility]
>>> -- have any method bodies changed
>>> -- and so on
>>>
>>> I wonder it would make sense for interested groups, such as JUGs,
>>> to team up and take on such projects.
>>>
>>> -- Jon
>> We could certainly list projects like this on a Adopt OpenJDK site and
>> work with
>> the JUG leaders to put together teams. There's never any guarantee that a
>> particular project will get picked up, but with such a diverse group
>> of developers there would hopefully be some sort of adoption yes.
> To add further to this, please send myself or Mike Barker any ideas you'd
> like to see tackled and we'll get them added to the list.
>
> Cheers,
> Martijn
There is already something like this in the test of ASM (google ASM java).
It allows us, developers of ASM to maintain 1.3 compatibility by checking
against a public description of the 1.3 API.
R?mi
From martijnverburg at gmail.com Fri Dec 9 03:24:27 2011
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 9 Dec 2011 11:24:27 +0000
Subject: Tests (Was Warnings Cleanup in java.util.<various> (more from
hack day))
In-Reply-To: <4EE12A9F.5090204@oracle.com>
References: <CAP7YuASf+6mzmikMv7ki=+gTY_7ZpBiSj7F+zC=sDYukx16RUg@mail.gmail.com>
<4EDA4204.2080108@oracle.com>
<CAP7YuAR_BeF5hiq+MsN1rS8tYtBuHbNFUXgZJXJ6f1OvJ46cKA@mail.gmail.com>
<4EE12A9F.5090204@oracle.com>
Message-ID: <CAP7YuAT0VaHmUsxbXy-tv4Utynp7_be5LDWQ3Yie+3M9M4bdOQ@mail.gmail.com>
>> Thanks for the set-up instructions, between that and the jtreg site I
>> was able to get them running.
>>
>> I'll probably have more specific questions later on, but in the mean
>> time I'd like to be able to
>> contribute some documentation steps so that especially when community
>> enthusiasts help out
>> with things like 'javac warning clean-up' they do so with an extra safety
>> net.
>>
>> I pinged the guide-discuss list as I thought the developers guide
>> should be where this goes. It
>> could be Warlocks dilemma, but I got not reply there, is the
>> developers guide still the right place? Or
>> is there a wiki that now holds the equivalent developers guide?
>>
>> Apologies for asking on this list, but wasn't sure what another
>> appropriate list would be, OpenJDK
>> has a lot of lists ;-).
>>
>> Cheers,
>> Martijn
>
>
> Martijn,
>
> I think the Developers Guide is the right place to put this sort of
> documentation, and ideally the guide-discuss list would be the place to
> discuss it. In the meantime, I suggest creating documentation so that we can
> post it "somewhere" where it can be referenced by others wanting to join in
> the fun.
>
> -- Jon
Hi Jon/All,
So if developers were working through the guide for fixing a bug at
http://openjdk.java.net/guide/changePlanning.html#bug then following
on from Step 6 there could be something like (formatting would need to
be improved):
7. Configuring and running the jtreg tests
1. Go to http://openjdk.java.net/jtreg/ and have a scan through the
details there
2. Go http://download.java.net/openjdk/jtreg/
3. Download the latest binary zip file
4. Unzip the contents to a directory of your choosing, you should see
a folder called jtreg
5. Set JT_HOME=<location where you unzipped jtreg>
5. Set your PATH to PATH=$PATH:$JT_HOME/<your platform>/bin (look at
the $JT_HOME directory for supported platforms)
6. cd <location of where OpenJDK source was cloned to>/test
7. make <test target> (e.g. In order to test the util package: make
jdk_util &> test.log)
For more options and details see http://openjdk.java.net/jtreg/
Cheers,
Martijn
From georges.saab at oracle.com Fri Dec 9 06:16:38 2011
From: georges.saab at oracle.com (Georges Saab)
Date: Fri, 9 Dec 2011 12:16:38 -0200
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <4EE19A9B.1090202@gmx.de>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com>
<4EE12E63.7060707@oracle.com> <4EE19A9B.1090202@gmx.de>
Message-ID: <FBCBA5EA-453D-4C75-A9AF-A46EA04637FB@oracle.com>
This is something we intend to test out with the pilot instance of JIRA, see the following:
http://mail.openjdk.java.net/pipermail/announce/2011-October/000112.html
/GES
On 9 dec 2011, at 03:20, Sebastian Sickelmann wrote:
...
> Another fine thing would be to have an public reachable review system.
> Like gerrit(for git) just for mercurial. I think inside of Oracle there is such
> a system, at least most of the webrevs from oracle folks are hosted on
> a server with the name http://cr.openjdk.java.net.
>
> Providing patches through webrev is not the easiest part for anyone
> who can move the OpenJdk forward. I think this is true at least for
> those who uses windows as there primary development plattform.
> Pushing to hg server that creates webrev for them would be really cool.
>
> -- Sebastian
From Alan.Bateman at oracle.com Fri Dec 9 06:44:40 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 09 Dec 2011 14:44:40 +0000
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com>
<4EE12E63.7060707@oracle.com>
<CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com>
<CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com>
Message-ID: <4EE21ED8.1010408@oracle.com>
On 09/12/2011 10:16, Martijn Verburg wrote:
> To add further to this, please send myself or Mike Barker any ideas you'd
> like to see tackled and we'll get them added to the list.
>
There is an almost endless list of things that could be done. Along the
lines of the warnings clean-up, then sorting through the output of
FindBugs and other static analysis tools could lead to some useful
patches and fun discussions. You probably saw the mail from Evgeny
Mandrikov a few weeks ago where he announced a Sonar dashboard for the
jdk7 sources. There's a lot of noise in there but it may be useful to
identify some useful clean-ups (just need to watch the risk/benefit
trade-off). And of course the tests. In the past we haven't given the
tests enough TLC so patches to improve the reliability or performance of
tests are very welcome. There are lots of specific things that could be
done too but the nice thing about the clean-up areas is that they
implement Spliterable.
-Alan.
From mcconnell at dpml.net Fri Dec 9 06:48:06 2011
From: mcconnell at dpml.net (Stephen McConnell)
Date: Sat, 10 Dec 2011 01:18:06 +1030
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <4EE21ED8.1010408@oracle.com>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com><4EE12E63.7060707@oracle.com><CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com><CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com>
<4EE21ED8.1010408@oracle.com>
Message-ID: <1FAEC202D15E43368C9760CA0120CA20@GLORIA>
If Sonar is in place - then chances are we could enable a 'Technical Debt'
metric.
That would be interesting.
Cheers, Steve.
-----Original Message-----
From: Alan Bateman
Sent: Saturday, December 10, 2011 1:14 AM
To: Martijn Verburg
Cc: jdk8-dev at openjdk.java.net
Subject: Re: OpenJDK adoption by Java User Groups
On 09/12/2011 10:16, Martijn Verburg wrote:
> To add further to this, please send myself or Mike Barker any ideas you'd
> like to see tackled and we'll get them added to the list.
>
There is an almost endless list of things that could be done. Along the
lines of the warnings clean-up, then sorting through the output of
FindBugs and other static analysis tools could lead to some useful
patches and fun discussions. You probably saw the mail from Evgeny
Mandrikov a few weeks ago where he announced a Sonar dashboard for the
jdk7 sources. There's a lot of noise in there but it may be useful to
identify some useful clean-ups (just need to watch the risk/benefit
trade-off). And of course the tests. In the past we haven't given the
tests enough TLC so patches to improve the reliability or performance of
tests are very welcome. There are lots of specific things that could be
done too but the nice thing about the clean-up areas is that they
implement Spliterable.
-Alan.
From jonathan.gibbons at oracle.com Fri Dec 9 06:52:19 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 09 Dec 2011 06:52:19 -0800
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <1FAEC202D15E43368C9760CA0120CA20@GLORIA>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com><4EE12E63.7060707@oracle.com><CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com><CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com> <4EE21ED8.1010408@oracle.com>
<1FAEC202D15E43368C9760CA0120CA20@GLORIA>
Message-ID: <4EE220A3.4050304@oracle.com>
Metrics are good, especially when you can see trend towards a realistic
goal ;-)
-- Jon
On 12/09/2011 06:48 AM, Stephen McConnell wrote:
> If Sonar is in place - then chances are we could enable a 'Technical
> Debt' metric.
> That would be interesting.
>
> Cheers, Steve.
>
> -----Original Message----- From: Alan Bateman
> Sent: Saturday, December 10, 2011 1:14 AM
> To: Martijn Verburg
> Cc: jdk8-dev at openjdk.java.net
> Subject: Re: OpenJDK adoption by Java User Groups
>
> On 09/12/2011 10:16, Martijn Verburg wrote:
>> To add further to this, please send myself or Mike Barker any ideas
>> you'd
>> like to see tackled and we'll get them added to the list.
>>
> There is an almost endless list of things that could be done. Along the
> lines of the warnings clean-up, then sorting through the output of
> FindBugs and other static analysis tools could lead to some useful
> patches and fun discussions. You probably saw the mail from Evgeny
> Mandrikov a few weeks ago where he announced a Sonar dashboard for the
> jdk7 sources. There's a lot of noise in there but it may be useful to
> identify some useful clean-ups (just need to watch the risk/benefit
> trade-off). And of course the tests. In the past we haven't given the
> tests enough TLC so patches to improve the reliability or performance of
> tests are very welcome. There are lots of specific things that could be
> done too but the nice thing about the clean-up areas is that they
> implement Spliterable.
>
> -Alan.
From mcconnell at dpml.net Fri Dec 9 07:06:50 2011
From: mcconnell at dpml.net (Stephen McConnell)
Date: Sat, 10 Dec 2011 01:36:50 +1030
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <4EE220A3.4050304@oracle.com>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com><4EE12E63.7060707@oracle.com><CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com><CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com> <4EE21ED8.1010408@oracle.com><1FAEC202D15E43368C9760CA0120CA20@GLORIA>
<4EE220A3.4050304@oracle.com>
Message-ID: <EA5BE8498D4A425EA1BEED96C05B6034@GLORIA>
Does anyone have a link to the Sonar page?
Cheers, Steve.
-----Original Message-----
From: Jonathan Gibbons
Sent: Saturday, December 10, 2011 1:22 AM
To: jdk8-dev at openjdk.java.net
Subject: Re: OpenJDK adoption by Java User Groups
Metrics are good, especially when you can see trend towards a realistic
goal ;-)
-- Jon
On 12/09/2011 06:48 AM, Stephen McConnell wrote:
> If Sonar is in place - then chances are we could enable a 'Technical
> Debt' metric.
> That would be interesting.
>
> Cheers, Steve.
>
> -----Original Message----- From: Alan Bateman
> Sent: Saturday, December 10, 2011 1:14 AM
> To: Martijn Verburg
> Cc: jdk8-dev at openjdk.java.net
> Subject: Re: OpenJDK adoption by Java User Groups
>
> On 09/12/2011 10:16, Martijn Verburg wrote:
>> To add further to this, please send myself or Mike Barker any ideas
>> you'd
>> like to see tackled and we'll get them added to the list.
>>
> There is an almost endless list of things that could be done. Along the
> lines of the warnings clean-up, then sorting through the output of
> FindBugs and other static analysis tools could lead to some useful
> patches and fun discussions. You probably saw the mail from Evgeny
> Mandrikov a few weeks ago where he announced a Sonar dashboard for the
> jdk7 sources. There's a lot of noise in there but it may be useful to
> identify some useful clean-ups (just need to watch the risk/benefit
> trade-off). And of course the tests. In the past we haven't given the
> tests enough TLC so patches to improve the reliability or performance of
> tests are very welcome. There are lots of specific things that could be
> done too but the nice thing about the clean-up areas is that they
> implement Spliterable.
>
> -Alan.
From artem.ananiev at oracle.com Fri Dec 9 07:22:49 2011
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Fri, 09 Dec 2011 19:22:49 +0400
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <EA5BE8498D4A425EA1BEED96C05B6034@GLORIA>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com><4EE12E63.7060707@oracle.com><CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com><CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com> <4EE21ED8.1010408@oracle.com><1FAEC202D15E43368C9760CA0120CA20@GLORIA>
<4EE220A3.4050304@oracle.com>
<EA5BE8498D4A425EA1BEED96C05B6034@GLORIA>
Message-ID: <4EE227C9.40208@oracle.com>
Here is a link to original Sonar announcement at the discuss at
openjdk.java.net alias:
http://mail.openjdk.java.net/pipermail/discuss/2011-November/002204.html
Artem
On 12/9/2011 7:06 PM, Stephen McConnell wrote:
> Does anyone have a link to the Sonar page?
>
> Cheers, Steve.
>
> -----Original Message----- From: Jonathan Gibbons Sent: Saturday,
> December 10, 2011 1:22 AM To: jdk8-dev at openjdk.java.net Subject: Re:
> OpenJDK adoption by Java User Groups
> Metrics are good, especially when you can see trend towards a realistic
> goal ;-)
>
> -- Jon
>
> On 12/09/2011 06:48 AM, Stephen McConnell wrote:
>> If Sonar is in place - then chances are we could enable a 'Technical
>> Debt' metric.
>> That would be interesting.
>>
>> Cheers, Steve.
>>
>> -----Original Message----- From: Alan Bateman
>> Sent: Saturday, December 10, 2011 1:14 AM
>> To: Martijn Verburg
>> Cc: jdk8-dev at openjdk.java.net
>> Subject: Re: OpenJDK adoption by Java User Groups
>>
>> On 09/12/2011 10:16, Martijn Verburg wrote:
>>> To add further to this, please send myself or Mike Barker any ideas
>>> you'd
>>> like to see tackled and we'll get them added to the list.
>>>
>> There is an almost endless list of things that could be done. Along the
>> lines of the warnings clean-up, then sorting through the output of
>> FindBugs and other static analysis tools could lead to some useful
>> patches and fun discussions. You probably saw the mail from Evgeny
>> Mandrikov a few weeks ago where he announced a Sonar dashboard for the
>> jdk7 sources. There's a lot of noise in there but it may be useful to
>> identify some useful clean-ups (just need to watch the risk/benefit
>> trade-off). And of course the tests. In the past we haven't given the
>> tests enough TLC so patches to improve the reliability or performance of
>> tests are very welcome. There are lots of specific things that could be
>> done too but the nice thing about the clean-up areas is that they
>> implement Spliterable.
>>
>> -Alan.
>
From jonathan.gibbons at oracle.com Fri Dec 9 08:45:45 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 09 Dec 2011 08:45:45 -0800
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <BCA79E7246E645F2BE54F7389503F237@GLORIA>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com><4EE12E63.7060707@oracle.com><CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com><CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com> <4EE21ED8.1010408@oracle.com><1FAEC202D15E43368C9760CA0120CA20@GLORIA>
<4EE220A3.4050304@oracle.com>
<EA5BE8498D4A425EA1BEED96C05B6034@GLORIA>
<4EE227C9.40208@oracle.com>
<BCA79E7246E645F2BE54F7389503F237@GLORIA>
Message-ID: <4EE23B39.6050902@oracle.com>
On 12/09/2011 08:40 AM, Stephen McConnell wrote:
> Seems we don't' have test coverage in place. Does anyone know if this
> is being put in place?
Can you give more details on what you mean or would like to see here?
-- Jon
From mcconnell at dpml.net Fri Dec 9 08:58:09 2011
From: mcconnell at dpml.net (Stephen McConnell)
Date: Sat, 10 Dec 2011 03:28:09 +1030
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <4EE23B39.6050902@oracle.com>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com><4EE12E63.7060707@oracle.com><CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com><CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com> <4EE21ED8.1010408@oracle.com><1FAEC202D15E43368C9760CA0120CA20@GLORIA>
<4EE220A3.4050304@oracle.com>
<EA5BE8498D4A425EA1BEED96C05B6034@GLORIA>
<4EE227C9.40208@oracle.com>
<BCA79E7246E645F2BE54F7389503F237@GLORIA>
<4EE23B39.6050902@oracle.com>
Message-ID: <3B8F17CCD979492A89430EE8749CDC4D@GLORIA>
Jonathan:
I would like to see Sonar metrics for the following:
1.. unit test coverage
2.. technical debt
I use Sonar on multiple internal projects and these two metrics mean a lot to me.
Cheers, Steve.
p.s. I can provide resources to help with the configuration if required.
/SJM
-----Original Message-----
From: Jonathan Gibbons
Sent: Saturday, December 10, 2011 3:15 AM
To: Stephen McConnell
Cc: Artem Ananiev ; jdk8-dev at openjdk.java.net
Subject: Re: OpenJDK adoption by Java User Groups
On 12/09/2011 08:40 AM, Stephen McConnell wrote:
> Seems we don't' have test coverage in place. Does anyone know if this
> is being put in place?
Can you give more details on what you mean or would like to see here?
-- Jon
From mcconnell at dpml.net Fri Dec 9 09:01:28 2011
From: mcconnell at dpml.net (Stephen McConnell)
Date: Sat, 10 Dec 2011 03:31:28 +1030
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <3B8F17CCD979492A89430EE8749CDC4D@GLORIA>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com><4EE12E63.7060707@oracle.com><CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com><CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com> <4EE21ED8.1010408@oracle.com><1FAEC202D15E43368C9760CA0120CA20@GLORIA><4EE220A3.4050304@oracle.com><EA5BE8498D4A425EA1BEED96C05B6034@GLORIA><4EE227C9.40208@oracle.com><BCA79E7246E645F2BE54F7389503F237@GLORIA><4EE23B39.6050902@oracle.com>
<3B8F17CCD979492A89430EE8749CDC4D@GLORIA>
Message-ID: <9EDC9410F2474A35A319990E8E895F70@GLORIA>
These are the related links:
Clover Unit Test Coverage
http://docs.codehaus.org/display/SONAR/Clover+Plugin
Technical Debt
http://www.sonarsource.org/evaluate-your-technical-debt-with-sonar/
Cheers, Steve.
-----Original Message-----
From: Stephen McConnell
Sent: Saturday, December 10, 2011 3:28 AM
To: Jonathan Gibbons
Cc: jdk8-dev at openjdk.java.net
Subject: Re: OpenJDK adoption by Java User Groups
Jonathan:
I would like to see Sonar metrics for the following:
1.. unit test coverage
2.. technical debt
I use Sonar on multiple internal projects and these two metrics mean a lot
to me.
Cheers, Steve.
p.s. I can provide resources to help with the configuration if required.
/SJM
-----Original Message-----
From: Jonathan Gibbons
Sent: Saturday, December 10, 2011 3:15 AM
To: Stephen McConnell
Cc: Artem Ananiev ; jdk8-dev at openjdk.java.net
Subject: Re: OpenJDK adoption by Java User Groups
On 12/09/2011 08:40 AM, Stephen McConnell wrote:
> Seems we don't' have test coverage in place. Does anyone know if this
> is being put in place?
Can you give more details on what you mean or would like to see here?
-- Jon
From jonathan.gibbons at oracle.com Fri Dec 9 09:14:08 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 09 Dec 2011 09:14:08 -0800
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <9EDC9410F2474A35A319990E8E895F70@GLORIA>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com><4EE12E63.7060707@oracle.com><CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com><CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com> <4EE21ED8.1010408@oracle.com><1FAEC202D15E43368C9760CA0120CA20@GLORIA><4EE220A3.4050304@oracle.com><EA5BE8498D4A425EA1BEED96C05B6034@GLORIA><4EE227C9.40208@oracle.com><BCA79E7246E645F2BE54F7389503F237@GLORIA><4EE23B39.6050902@oracle.com>
<3B8F17CCD979492A89430EE8749CDC4D@GLORIA>
<9EDC9410F2474A35A319990E8E895F70@GLORIA>
Message-ID: <4EE241E0.2080600@oracle.com>
Stephen,
I've browsed around the links for Clover. It looks very interesting, but
it's not clear to me the constraints under which it operates.
Note that OpenJDK uses jtreg for the publicly available regression
tests, and that many of the tests rely on being able to start up one or
more new JVMs for the duration of the test. In my experience this has
been too much of a stretch for commercially available coverage tools to
tolerate, and they typically can't cope and/or fall over. A common
assumption for such tools is that all API tests can run sequentially in
the same JVM.
Do you know if there are any such restrictions with Clover?
-- Jon
On 12/09/2011 09:01 AM, Stephen McConnell wrote:
> These are the related links:
>
> Clover Unit Test Coverage
> http://docs.codehaus.org/display/SONAR/Clover+Plugin
>
> Technical Debt
> http://www.sonarsource.org/evaluate-your-technical-debt-with-sonar/
>
> Cheers, Steve.
>
> -----Original Message----- From: Stephen McConnell
> Sent: Saturday, December 10, 2011 3:28 AM
> To: Jonathan Gibbons
> Cc: jdk8-dev at openjdk.java.net
> Subject: Re: OpenJDK adoption by Java User Groups
>
> Jonathan:
>
> I would like to see Sonar metrics for the following:
> 1.. unit test coverage
> 2.. technical debt
> I use Sonar on multiple internal projects and these two metrics mean a
> lot to me.
>
> Cheers, Steve.
>
> p.s. I can provide resources to help with the configuration if required.
>
> /SJM
>
> -----Original Message----- From: Jonathan Gibbons
> Sent: Saturday, December 10, 2011 3:15 AM
> To: Stephen McConnell
> Cc: Artem Ananiev ; jdk8-dev at openjdk.java.net
> Subject: Re: OpenJDK adoption by Java User Groups
>
> On 12/09/2011 08:40 AM, Stephen McConnell wrote:
>> Seems we don't' have test coverage in place. Does anyone know if this
>> is being put in place?
>
> Can you give more details on what you mean or would like to see here?
>
> -- Jon
From Alan.Bateman at oracle.com Sun Dec 11 13:27:18 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 11 Dec 2011 21:27:18 +0000
Subject: OpenJDK adoption by Java User Groups
In-Reply-To: <4EE241E0.2080600@oracle.com>
References: <CAP7YuATEd5W5FH5_q6swOU2oSNewQos1jT9Fp-STgBTUVU7hhA@mail.gmail.com><4EE12E63.7060707@oracle.com><CAP7YuASiC1iMAhJSXDtR5wZi+MCnt-uA3Nwu5okXsZCtq+qgZA@mail.gmail.com><CAP7YuAS9Yw-UM3DuqS0q-LVj8eMFi__jcZ1i08PMkJNG97qOcg@mail.gmail.com> <4EE21ED8.1010408@oracle.com><1FAEC202D15E43368C9760CA0120CA20@GLORIA><4EE220A3.4050304@oracle.com><EA5BE8498D4A425EA1BEED96C05B6034@GLORIA><4EE227C9.40208@oracle.com><BCA79E7246E645F2BE54F7389503F237@GLORIA><4EE23B39.6050902@oracle.com>
<3B8F17CCD979492A89430EE8749CDC4D@GLORIA>
<9EDC9410F2474A35A319990E8E895F70@GLORIA>
<4EE241E0.2080600@oracle.com>
Message-ID: <4EE52036.1010406@oracle.com>
On 09/12/2011 17:14, Jonathan Gibbons wrote:
> Stephen,
>
> I've browsed around the links for Clover. It looks very interesting,
> but it's not clear to me the constraints under which it operates.
>
> Note that OpenJDK uses jtreg for the publicly available regression
> tests, and that many of the tests rely on being able to start up one
> or more new JVMs for the duration of the test. In my experience this
> has been too much of a stretch for commercially available coverage
> tools to tolerate, and they typically can't cope and/or fall over. A
> common assumption for such tools is that all API tests can run
> sequentially in the same JVM.
>
> Do you know if there are any such restrictions with Clover?
>
> -- Jon
It would be interesting to know if this is possible. Another thing that
often gets us with off-the-shelf tools is that they don't recognize the
newest class file version or they only work with released JDK versions.
I don't know if this tool uses static or load-time instrumentation but
it reminds me that another useful thing that could be done is audit the
shell tests, and tests that use Runtime.exec to create additional VMs,
to make sure that they pass the VM options through to the child
processes. It's unlikely to change the code coverage numbers too much,
except perhaps tool code, but important to get the right results.
-Alan
From lana.steuck at oracle.com Tue Dec 13 15:11:05 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 13 Dec 2011 23:11:05 +0000
Subject: hg: jdk8/jdk8/langtools: 10 new changesets
Message-ID: <20111213231127.5074D4769F@hg.openjdk.java.net>
Changeset: c896d95e7469
Author: mcimadamore
Date: 2011-11-24 13:36 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/c896d95e7469
7115046: Add AST node for lambda expressions
Summary: Add tree nodes for representing lambda expressions and update relevant visitors interfaces
Reviewed-by: jjg
+ src/share/classes/com/sun/source/tree/LambdaExpressionTree.java
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/tree/TreeVisitor.java
! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java
Changeset: ec59a2ce9114
Author: mcimadamore
Date: 2011-11-24 13:38 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ec59a2ce9114
7115049: Add AST node for method references
Summary: Add tree nodes for representing method/constructor references and update relevant visitors interfaces
Reviewed-by: jjg
+ src/share/classes/com/sun/source/tree/MemberReferenceTree.java
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/tree/TreeVisitor.java
! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java
Changeset: 9448fe783fd2
Author: mcimadamore
Date: 2011-11-28 15:56 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/9448fe783fd2
7115050: Add parser support for lambda expressions
Summary: Add support for parsing lambda expressions to JavacParser
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/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Lexer.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/parser/Tokens.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/diags/examples/CatchWithoutTry.java
+ test/tools/javac/diags/examples/LambdaNotSupported.java
+ test/tools/javac/diags/examples/NotAStatement.java
! test/tools/javac/generics/rare/6665356/T6665356.out
+ test/tools/javac/lambda/LambdaParserTest.java
Changeset: 3343b22e2761
Author: mcimadamore
Date: 2011-11-28 16:05 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/3343b22e2761
7115052: Add parser support for method references
Summary: Add support for parsing method references to JavacParser
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/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Tokens.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/diags/examples/IllegalChar.java
+ test/tools/javac/diags/examples/MethodReferencesNotSupported.java
+ test/tools/javac/lambda/MethodReferenceParserTest.java
! test/tools/javac/quid/T6999438.out
Changeset: 2584f5358cba
Author: lana
Date: 2011-12-06 20:26 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/2584f5358cba
Merge
Changeset: abfa0d8ea803
Author: ksrini
Date: 2011-12-07 10:47 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/abfa0d8ea803
7086015: fix test/tools/javac/parser/netbeans/JavacParserTest.java
Reviewed-by: ksrini, jjg
Contributed-by: matherey.nunez at oracle.com
! test/tools/javac/parser/netbeans/JavacParserTest.java
Changeset: 9350d0498d21
Author: ksrini
Date: 2011-12-09 08:40 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/9350d0498d21
7119032: (javac) increase visibility of JavacParser methods to improve subtyping
Reviewed-by: jjg
Contributed-by: jan.lahoda at oracle.com
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
Changeset: e7d5e1a7cde5
Author: ksrini
Date: 2011-12-10 17:44 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/e7d5e1a7cde5
7119487: JavacParserTest.java test fails on Windows platforms
Reviewed-by: jjg
+ test/tools/javac/parser/JavacParserTest.java
- test/tools/javac/parser/netbeans/JavacParserTest.java
Changeset: e55270a7a022
Author: mcimadamore
Date: 2011-12-11 17:48 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/e55270a7a022
7120266: javac fails to compile hotspot code
Summary: Parser changes for method references cause bad intercation with method call syntax
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/T7120266.java
! test/tools/javac/lambda/MethodReferenceParserTest.java
Changeset: 1cbe86c11ba6
Author: lana
Date: 2011-12-12 10:08 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/1cbe86c11ba6
Merge
- test/tools/javac/parser/netbeans/JavacParserTest.java
From lana.steuck at oracle.com Tue Dec 13 15:11:58 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 13 Dec 2011 23:11:58 +0000
Subject: hg: jdk8/jdk8/jdk: 61 new changesets
Message-ID: <20111213232146.DE5AA476A0@hg.openjdk.java.net>
Changeset: 23acf34c80b0
Author: neugens
Date: 2011-12-03 15:40 +0100
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/23acf34c80b0
7117914: Fix javac warnings in src/share/classes/sun/java2d
Summary: Fix some javac warnings in java2d related code for the Warning Cleanup Day.
Reviewed-by: prr, flar
! src/share/classes/java/awt/geom/Path2D.java
! src/share/classes/sun/awt/image/BufImgSurfaceData.java
! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/SurfaceData.java
! src/share/classes/sun/java2d/SurfaceDataProxy.java
! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java
! src/share/classes/sun/java2d/loops/SurfaceType.java
! src/share/classes/sun/java2d/opengl/OGLBufImgOps.java
! src/share/classes/sun/java2d/opengl/OGLDrawImage.java
! src/share/classes/sun/java2d/opengl/OGLPaints.java
! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
! src/share/classes/sun/java2d/pipe/AAShapePipe.java
! src/share/classes/sun/java2d/pipe/BufferedPaints.java
! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java
! src/share/classes/sun/java2d/pipe/DrawImage.java
! src/share/classes/sun/java2d/pipe/GlyphListPipe.java
! src/share/classes/sun/java2d/pipe/LoopPipe.java
! src/share/classes/sun/java2d/pipe/RenderingEngine.java
! src/solaris/classes/sun/java2d/x11/X11Renderer.java
! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
Changeset: 70b40ea06df0
Author: prr
Date: 2011-12-03 16:26 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/70b40ea06df0
7117199: Fix javac warnings in src/share/classes/java/awt/font
Reviewed-by: jgodinez, bae
! src/share/classes/java/awt/font/StyledParagraph.java
! src/share/classes/java/awt/font/TextAttribute.java
! src/share/classes/java/awt/font/TextLayout.java
! src/share/classes/java/awt/font/TextLine.java
! src/share/classes/java/awt/font/TextMeasurer.java
Changeset: 4075d524fa46
Author: lana
Date: 2011-12-06 16:15 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/4075d524fa46
Merge
Changeset: e53a078c2840
Author: anthony
Date: 2011-11-09 13:43 +0300
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/e53a078c2840
7045370: Java Statically Determines Display Size on Linux platforms
Summary: Listen to ConfigureNotify events on the root window and update the current screen size accordingly
Reviewed-by: art, bae
! src/share/classes/java/awt/Component.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11GraphicsDevice.java
! src/solaris/native/sun/awt/awt_GraphicsEnv.c
Changeset: 84e473cf4531
Author: rupashka
Date: 2011-11-10 14:10 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/84e473cf4531
6938583: Unexpected NullPointerException by InputContext.endComposition()
Reviewed-by: rupashka
Contributed-by: Charles Lee <littlee at linux.vnet.ibm.com>
! src/share/classes/javax/swing/text/DefaultCaret.java
+ test/javax/swing/text/DefaultCaret/6938583/bug6938583.java
Changeset: 81f1b32f9e24
Author: malenkov
Date: 2011-11-10 17:15 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/81f1b32f9e24
7057459: Regression: Performance degradation with java.beans.XMLEncoder
Reviewed-by: rupashka
! src/share/classes/java/beans/Encoder.java
Changeset: e120c78cb45c
Author: malenkov
Date: 2011-11-10 17:27 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/e120c78cb45c
7064279: Introspector.getBeanInfo() should release some resources in timely manner
Reviewed-by: art, alexp
! src/share/classes/java/beans/Beans.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/PropertyEditorManager.java
+ src/share/classes/java/beans/ThreadGroupContext.java
! test/java/beans/Beans/6669869/TestDesignTime.java
! test/java/beans/Beans/6669869/TestGuiAvailable.java
! test/java/beans/Introspector/6380849/TestBeanInfo.java
+ test/java/beans/Introspector/7064279/Test7064279.java
+ test/java/beans/Introspector/7064279/test.jar
! test/java/beans/Introspector/Test6660539.java
! test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java
Changeset: 8b6a69b2e482
Author: malenkov
Date: 2011-11-10 17:32 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/8b6a69b2e482
7087876: java/beans/PropertyDescriptor.html#createPropertyEditor() throws RE if editor cannot be created
Reviewed-by: rupashka
! src/share/classes/java/beans/PropertyDescriptor.java
+ test/java/beans/PropertyEditor/Test7087876.java
Changeset: b02495c51b9c
Author: malenkov
Date: 2011-11-10 17:35 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b02495c51b9c
7092744: XMLEncoder fails to encode and breaks backward compatibility
Reviewed-by: rupashka
! src/share/classes/com/sun/beans/finder/AbstractFinder.java
! src/share/classes/com/sun/beans/finder/ConstructorFinder.java
! src/share/classes/com/sun/beans/finder/MethodFinder.java
+ test/java/beans/XMLEncoder/Test7092744.java
Changeset: 16327765859c
Author: malenkov
Date: 2011-11-10 17:37 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/16327765859c
7087429: Constructor of java.beans.PropertyChangeEvent should declare thrown NPE for null source
Reviewed-by: rupashka
! src/share/classes/java/beans/PropertyChangeEvent.java
+ test/java/beans/PropertyChangeSupport/Test7087429.java
Changeset: f614bcada2a9
Author: anthony
Date: 2011-11-11 15:17 +0300
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f614bcada2a9
7103610: _NET_WM_PID and WM_CLIENT_MACHINE are not set
Summary: Set the properties to all top-level windows
Reviewed-by: anthony
Contributed-by: Danesh Dadachanji <ddadacha at redhat.com>
! make/sun/xawt/mapfile-vers
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/solaris/native/sun/xawt/XToolkit.c
Changeset: c0f3f1558a94
Author: rupashka
Date: 2011-11-14 14:00 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c0f3f1558a94
7109617: Test was writed for Metal L&F but not set it
Reviewed-by: rupashka
Contributed-by: alexandr.scherbatiy at oracle.com
+ test/javax/swing/plaf/metal/MetalLookAndFeel/5073047/bug5073047.java
Changeset: a51777c9228a
Author: malenkov
Date: 2011-11-14 14:38 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a51777c9228a
7110521: Regression test failed: Introspector/TestTypeResolver.java
Reviewed-by: rupashka
! test/java/beans/Introspector/TestTypeResolver.java
Changeset: 28f768c41a90
Author: serb
Date: 2011-11-12 04:13 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/28f768c41a90
6996291: command line selection of MToolkit by -Dawt.toolkit=sun.awt.motif.MToolkit fails from jdk7 b21 on
Reviewed-by: art, dcherepanov, bae, prr
! make/sun/awt/FILES_c_unix.gmk
! make/sun/awt/FILES_export_unix.gmk
! make/sun/awt/mapfile-mawt-vers
! make/sun/awt/mapfile-vers-linux
! make/sun/awt/mawt.gmk
- make/sun/motif12/reorder-i586
- make/sun/motif12/reorder-sparc
- make/sun/motif12/reorder-sparcv9
! make/sun/xawt/mapfile-vers
! src/solaris/classes/sun/awt/X11/ListHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java
- src/solaris/classes/sun/awt/motif/AWTLockAccess.java
! src/solaris/classes/sun/awt/motif/MFontConfiguration.java
- src/solaris/classes/sun/awt/motif/MFontPeer.java
- src/solaris/classes/sun/awt/motif/MToolkit.java
- src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java
- src/solaris/classes/sun/awt/motif/MWindowAttributes.java
- src/solaris/classes/sun/awt/motif/X11FontMetrics.java
- src/solaris/native/sun/awt/MouseInfo.c
- src/solaris/native/sun/awt/XDrawingArea.c
- src/solaris/native/sun/awt/XDrawingArea.h
- src/solaris/native/sun/awt/XDrawingAreaP.h
! src/solaris/native/sun/awt/awt.h
! src/solaris/native/sun/awt/awt_AWTEvent.c
! src/solaris/native/sun/awt/awt_Component.h
- src/solaris/native/sun/awt/awt_Cursor.h
! src/solaris/native/sun/awt/awt_DrawingSurface.c
! src/solaris/native/sun/awt/awt_Font.c
! src/solaris/native/sun/awt/awt_Font.h
! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/awt/awt_InputMethod.c
- src/solaris/native/sun/awt/awt_KeyboardFocusManager.h
- src/solaris/native/sun/awt/awt_MToolkit.c
- src/solaris/native/sun/awt/awt_MToolkit.h
- src/solaris/native/sun/awt/awt_MenuItem.h
- src/solaris/native/sun/awt/awt_PopupMenu.h
! src/solaris/native/sun/awt/awt_Robot.c
- src/solaris/native/sun/awt/awt_TopLevel.h
- src/solaris/native/sun/awt/awt_Window.h
- src/solaris/native/sun/awt/awt_mgrsel.c
- src/solaris/native/sun/awt/awt_mgrsel.h
- src/solaris/native/sun/awt/awt_motif.h
! src/solaris/native/sun/awt/awt_p.h
! src/solaris/native/sun/awt/awt_util.c
! src/solaris/native/sun/awt/awt_util.h
- src/solaris/native/sun/awt/awt_wm.c
- src/solaris/native/sun/awt/awt_wm.h
- src/solaris/native/sun/awt/awt_xembed.h
- src/solaris/native/sun/awt/awt_xembed_server.c
- src/solaris/native/sun/awt/awt_xembed_server.h
! src/solaris/native/sun/awt/canvas.h
! src/solaris/native/sun/awt/multi_font.c
! src/solaris/native/sun/awt/multi_font.h
! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c
! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.h
! src/solaris/native/sun/java2d/x11/X11SurfaceData.c
! src/solaris/native/sun/xawt/XToolkit.c
Changeset: 6a9d735ebd0a
Author: bagiras
Date: 2011-11-16 15:40 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6a9d735ebd0a
7108598: Pogo Table Games freeze with JDK 7
Reviewed-by: art, ant
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
+ test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java
Changeset: 1df53949945d
Author: lana
Date: 2011-11-18 15:49 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1df53949945d
Merge
Changeset: 90d33a64a404
Author: rupashka
Date: 2011-11-21 18:22 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/90d33a64a404
7109085: Test use hotkeys not intended for Mac
Reviewed-by: rupashka
Contributed-by: alexandr.scherbatiy at oracle.com
! test/javax/swing/regtesthelpers/Util.java
+ test/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java
+ test/javax/swing/text/JTextComponent/5074573/bug5074573.java
+ test/javax/swing/text/html/HTMLEditorKit/5043626/bug5043626.java
Changeset: c3c80f96cb83
Author: rupashka
Date: 2011-11-25 11:52 +0300
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c3c80f96cb83
7113337: Swing closed test tries to click in the area reserved for resize by Mac OS X
Reviewed-by: rupashka
Contributed-by: alexandr.scherbatiy at oracle.com
+ test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java
Changeset: 9cbc208dcf08
Author: rupashka
Date: 2011-11-29 12:47 +0300
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9cbc208dcf08
7112925: closed/javax/swing/JTabbedPane/4624207/bug4624207.java fails on MacOS
Reviewed-by: rupashka
Contributed-by: alexandr.scherbatiy at oracle.com
+ test/javax/swing/JTabbedPane/4624207/bug4624207.java
Changeset: 051beb804b12
Author: rupashka
Date: 2011-11-30 16:54 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/051beb804b12
7110440: closed/javax/swing/JScrollBar/4865918/bug4865918.java fails on Aqua L&F
Reviewed-by: rupashka
Contributed-by: alexandr.scherbatiy at oracle.com
+ test/javax/swing/JScrollBar/4865918/bug4865918.java
Changeset: 7dd4395fe4a5
Author: rupashka
Date: 2011-11-30 19:38 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7dd4395fe4a5
7115357: closed/javax/swing/JTable/6263446/bug6263446Table.java fails on MacOS
Reviewed-by: rupashka
Contributed-by: alexandr.scherbatiy at oracle.com
+ test/javax/swing/JTable/6263446/bug6263446.java
Changeset: 4b416a0180dc
Author: lana
Date: 2011-11-29 15:57 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/4b416a0180dc
Merge
- test/java/io/FileDescriptor/FileChannelFDTest.java
- test/java/io/etc/FileDescriptorSharing.java
Changeset: 45eb5a61da07
Author: lana
Date: 2011-11-30 12:06 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/45eb5a61da07
Merge
Changeset: 79b5c5a8c7e9
Author: serb
Date: 2011-12-05 17:11 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/79b5c5a8c7e9
7115400: jdk 8 awt-gate build fails in headless toolkit on solaris.
Reviewed-by: prr, art, bae
! make/sun/awt/FILES_c_unix.gmk
+ src/solaris/native/sun/awt/HeadlessToolkit.c
! src/solaris/native/sun/java2d/x11/X11SurfaceData.h
Changeset: 2b1438297561
Author: lana
Date: 2011-12-06 16:17 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/2b1438297561
Merge
- make/sun/motif12/reorder-i586
- make/sun/motif12/reorder-sparc
- make/sun/motif12/reorder-sparcv9
- src/solaris/classes/sun/awt/motif/AWTLockAccess.java
- src/solaris/classes/sun/awt/motif/MFontPeer.java
- src/solaris/classes/sun/awt/motif/MToolkit.java
- src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java
- src/solaris/classes/sun/awt/motif/MWindowAttributes.java
- src/solaris/classes/sun/awt/motif/X11FontMetrics.java
- src/solaris/native/sun/awt/MouseInfo.c
- src/solaris/native/sun/awt/XDrawingArea.c
- src/solaris/native/sun/awt/XDrawingArea.h
- src/solaris/native/sun/awt/XDrawingAreaP.h
- src/solaris/native/sun/awt/awt_Cursor.h
- src/solaris/native/sun/awt/awt_KeyboardFocusManager.h
- src/solaris/native/sun/awt/awt_MToolkit.c
- src/solaris/native/sun/awt/awt_MToolkit.h
- src/solaris/native/sun/awt/awt_MenuItem.h
- src/solaris/native/sun/awt/awt_PopupMenu.h
- src/solaris/native/sun/awt/awt_TopLevel.h
- src/solaris/native/sun/awt/awt_Window.h
- src/solaris/native/sun/awt/awt_mgrsel.c
- src/solaris/native/sun/awt/awt_mgrsel.h
- src/solaris/native/sun/awt/awt_motif.h
- src/solaris/native/sun/awt/awt_wm.c
- src/solaris/native/sun/awt/awt_wm.h
- src/solaris/native/sun/awt/awt_xembed.h
- src/solaris/native/sun/awt/awt_xembed_server.c
- src/solaris/native/sun/awt/awt_xembed_server.h
Changeset: 387190e1f782
Author: chegar
Date: 2011-11-25 10:34 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/387190e1f782
7115150: java.net.HttpCookie code cleanup, style, formatting, typos
Reviewed-by: michaelm
! src/share/classes/java/net/HttpCookie.java
Changeset: e5ecbf555679
Author: chegar
Date: 2011-11-25 13:46 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/e5ecbf555679
7115586: Suppress creation of SocketImpl in SocketAdaptor's constructor
Reviewed-by: chegar, alanb
Contributed-by: sajia at taobao.com
! src/share/classes/sun/nio/ch/SocketAdaptor.java
Changeset: 022540b11147
Author: weijun
Date: 2011-11-28 18:16 +0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/022540b11147
7115744: Do not call File::deleteOnExit in security tests
Reviewed-by: xuelei
! test/sun/security/krb5/auto/CrossRealm.java
! test/sun/security/krb5/auto/HttpNegotiateServer.java
! test/sun/security/krb5/auto/KDC.java
! test/sun/security/krb5/auto/OkAsDelegateXRealm.java
! test/sun/security/krb5/auto/OneKDC.java
! test/sun/security/krb5/auto/SSL.java
! test/sun/security/krb5/auto/W83.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java
Changeset: d1928ae4e0a2
Author: xuelei
Date: 2011-11-28 02:35 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/d1928ae4e0a2
7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works
Reviewed-by: weijun
! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java
Changeset: 955aae8c1106
Author: ngmr
Date: 2011-11-24 11:34 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/955aae8c1106
7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should treat ESRCH as not found
Reviewed-by: alanb
Contributed-by: Jonathan Lu <luchsh at linux.vnet.ibm.com>
! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
Changeset: 6fbd69f8e3ab
Author: ngmr
Date: 2011-11-18 09:03 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6fbd69f8e3ab
7094995: Trailing daemon thread causes continuous GC in agentvm mode
Summary: Shutdown GcInducingThread once test (successfully) finishes
Reviewed-by: alanb, chegar, dholmes, darcy
Contributed-by: Neil Richards <neil.richards at ngmr.net>
! test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java
Changeset: cf47846165f4
Author: dholmes
Date: 2011-11-29 00:26 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cf47846165f4
7109092: Wrong computation results with double at armsflt
Summary: need to link to custom soft-float library with required FP accuracy
Reviewed-by: alanb, ohair
! make/common/Defs-embedded.gmk
Changeset: a47de985fec9
Author: sherman
Date: 2011-11-29 11:39 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a47de985fec9
7110149: Update the JDK8 bundled zlib library to the latest version 1.2.5
Summary: updated to zlib-1.2.5
Reviewed-by: alanb
! make/common/Defs.gmk
! make/java/zip/FILES_c.gmk
! make/sun/splashscreen/FILES_c.gmk
- 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
+ src/share/native/java/util/zip/zlib-1.2.5/ChangeLog
+ src/share/native/java/util/zip/zlib-1.2.5/README
+ src/share/native/java/util/zip/zlib-1.2.5/compress.c
+ src/share/native/java/util/zip/zlib-1.2.5/crc32.h
+ src/share/native/java/util/zip/zlib-1.2.5/deflate.c
+ src/share/native/java/util/zip/zlib-1.2.5/deflate.h
+ src/share/native/java/util/zip/zlib-1.2.5/gzclose.c
+ src/share/native/java/util/zip/zlib-1.2.5/gzguts.h
+ src/share/native/java/util/zip/zlib-1.2.5/gzlib.c
+ src/share/native/java/util/zip/zlib-1.2.5/gzread.c
+ src/share/native/java/util/zip/zlib-1.2.5/gzwrite.c
+ src/share/native/java/util/zip/zlib-1.2.5/infback.c
+ src/share/native/java/util/zip/zlib-1.2.5/inffast.c
+ src/share/native/java/util/zip/zlib-1.2.5/inffast.h
+ src/share/native/java/util/zip/zlib-1.2.5/inffixed.h
+ src/share/native/java/util/zip/zlib-1.2.5/inflate.c
+ src/share/native/java/util/zip/zlib-1.2.5/inflate.h
+ src/share/native/java/util/zip/zlib-1.2.5/inftrees.c
+ src/share/native/java/util/zip/zlib-1.2.5/inftrees.h
+ src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java
+ src/share/native/java/util/zip/zlib-1.2.5/trees.c
+ src/share/native/java/util/zip/zlib-1.2.5/trees.h
+ src/share/native/java/util/zip/zlib-1.2.5/uncompr.c
+ src/share/native/java/util/zip/zlib-1.2.5/zadler32.c
+ src/share/native/java/util/zip/zlib-1.2.5/zconf.h
+ src/share/native/java/util/zip/zlib-1.2.5/zcrc32.c
+ src/share/native/java/util/zip/zlib-1.2.5/zlib.h
+ src/share/native/java/util/zip/zlib-1.2.5/zutil.c
+ src/share/native/java/util/zip/zlib-1.2.5/zutil.h
+ test/java/util/zip/DeInflate.java
Changeset: 07e359b01d8a
Author: sherman
Date: 2011-11-29 13:05 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/07e359b01d8a
7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer
Summary: added methods Adler32/CRC32.update(ByteBuffer)
Reviewed-by: alanb
! make/java/zip/mapfile-vers
! src/share/classes/java/util/zip/Adler32.java
! src/share/classes/java/util/zip/CRC32.java
! src/share/native/java/util/zip/Adler32.c
! src/share/native/java/util/zip/CRC32.c
+ test/java/util/zip/TimeChecksum.java
Changeset: c5313d712ab0
Author: lana
Date: 2011-11-29 12:04 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c5313d712ab0
Merge
Changeset: a3edcdff37e1
Author: lana
Date: 2011-11-29 13:49 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a3edcdff37e1
Merge
Changeset: 4749df4f04f1
Author: alanb
Date: 2011-11-30 10:57 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/4749df4f04f1
7030624: size_t usages in src/windows/native/java/io/io_util_md.c need to be re-visited
Reviewed-by: lancea, chegar
! src/share/native/java/io/io_util.c
! src/windows/native/java/io/io_util_md.c
! src/windows/native/java/io/io_util_md.h
Changeset: 7795c41ed54c
Author: alanb
Date: 2011-11-30 12:42 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7795c41ed54c
7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes)
Reviewed-by: lancea, chegar, smarks
! src/share/classes/java/io/File.java
! src/share/classes/java/io/ObjectInputStream.java
! src/share/classes/java/io/ObjectOutputStream.java
! src/share/classes/java/io/ObjectStreamClass.java
! src/share/classes/java/io/SequenceInputStream.java
! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/Enum.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/Runtime.java
! src/share/classes/java/lang/SecurityManager.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/Thread.java
! src/share/classes/java/lang/ThreadGroup.java
! src/share/classes/java/rmi/MarshalledObject.java
! src/share/classes/java/rmi/dgc/VMID.java
! src/share/classes/java/rmi/server/LogStream.java
! src/share/classes/java/rmi/server/RemoteObject.java
! src/share/classes/sun/misc/JavaLangAccess.java
! src/share/classes/sun/misc/Launcher.java
! src/share/classes/sun/misc/Unsafe.java
! src/share/classes/sun/misc/VM.java
Changeset: 43a630f11af6
Author: smarks
Date: 2011-11-30 13:11 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43a630f11af6
7116322: enhance javac make rule with a little bit of instrumentation
Reviewed-by: dholmes, ohair
! make/common/Rules.gmk
Changeset: 3b8186aee592
Author: chegar
Date: 2011-12-01 11:09 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/3b8186aee592
7116722: Miscellaneous warnings sun.misc ( and related classes )
Reviewed-by: alanb, darcy, forax, hawtin, lancea
! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java
! src/share/classes/java/net/InetAddress.java
! src/share/classes/java/util/jar/JarVerifier.java
! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java
! src/share/classes/javax/script/ScriptEngineManager.java
! src/share/classes/sun/misc/BASE64Decoder.java
! src/share/classes/sun/misc/ExtensionDependency.java
! src/share/classes/sun/misc/JarIndex.java
! src/share/classes/sun/misc/JavaUtilJarAccess.java
! src/share/classes/sun/misc/ProxyGenerator.java
! src/share/classes/sun/misc/Service.java
! src/share/classes/sun/misc/Signal.java
! test/sun/misc/JarIndex/metaInfFilenames/Basic.java
Changeset: 89130611b178
Author: mcimadamore
Date: 2011-12-01 18:34 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/89130611b178
7116954: Misc warnings in java.beans/java.beans.context
Summary: Remove generic warnings form java.beans and java.beans.context
Reviewed-by: alanb, chegar
! src/share/classes/java/beans/BeanDescriptor.java
! src/share/classes/java/beans/Beans.java
! src/share/classes/java/beans/ChangeListenerMap.java
! src/share/classes/java/beans/DefaultPersistenceDelegate.java
! src/share/classes/java/beans/Encoder.java
! src/share/classes/java/beans/EventHandler.java
! src/share/classes/java/beans/EventSetDescriptor.java
! src/share/classes/java/beans/FeatureDescriptor.java
! src/share/classes/java/beans/IndexedPropertyDescriptor.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/MetaData.java
! src/share/classes/java/beans/MethodDescriptor.java
! src/share/classes/java/beans/NameGenerator.java
! src/share/classes/java/beans/PersistenceDelegate.java
! src/share/classes/java/beans/PropertyChangeSupport.java
! src/share/classes/java/beans/PropertyDescriptor.java
! src/share/classes/java/beans/PropertyEditorSupport.java
! src/share/classes/java/beans/ReflectionUtils.java
! src/share/classes/java/beans/SimpleBeanInfo.java
! src/share/classes/java/beans/Statement.java
! src/share/classes/java/beans/VetoableChangeSupport.java
! src/share/classes/java/beans/XMLEncoder.java
! src/share/classes/java/beans/beancontext/BeanContext.java
! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java
Changeset: 0e3f706741ca
Author: smarks
Date: 2011-12-01 16:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0e3f706741ca
7116890: additional warnings fixes for java.io
Reviewed-by: alanb, smarks
Contributed-by: Sebastian Sickelmann <sebastian.sickelmann at gmx.de>
! src/share/classes/java/io/ExpiringCache.java
! src/share/classes/java/io/LineNumberInputStream.java
! src/share/classes/java/io/LineNumberReader.java
! src/share/classes/java/io/ObjectOutputStream.java
! src/share/classes/java/io/RandomAccessFile.java
Changeset: b03da32c3186
Author: peytoia
Date: 2011-12-02 16:09 +0900
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b03da32c3186
7056472: Speed up test/java/util/ResourceBundle/Control/ExpirationTest.sh
Reviewed-by: okutsu
- test/java/util/ResourceBundle/Control/ExpirationTest.java
- test/java/util/ResourceBundle/Control/ExpirationTest.sh
Changeset: f615db07991e
Author: chegar
Date: 2011-12-02 11:39 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f615db07991e
7116946: JSSecurityManager should use java.util.ServiceLoader to lookup service providers
Reviewed-by: prr
! src/share/classes/com/sun/media/sound/JSSecurityManager.java
Changeset: 37f6e294759f
Author: chegar
Date: 2011-12-02 14:17 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/37f6e294759f
7116957: javax.script.ScriptEngineManager should use java.util.ServiceLoader to lookup service providers
Reviewed-by: alanb, lancea
! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java
! src/share/classes/javax/script/ScriptEngineManager.java
! src/share/classes/sun/net/ftp/FtpClientProvider.java
Changeset: 9950e2c9f3b5
Author: alanb
Date: 2011-12-02 17:37 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9950e2c9f3b5
7117357: Warnings in sun.instrument, tools and other sun.* classes
Reviewed-by: lancea, chegar
! src/share/classes/sun/instrument/InstrumentationImpl.java
! src/share/classes/sun/instrument/TransformerManager.java
! src/share/classes/sun/launcher/LauncherHelper.java
! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java
! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java
! src/share/classes/sun/net/RegisteredDomain.java
! src/share/classes/sun/net/www/protocol/jar/Handler.java
! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java
! src/share/classes/sun/tools/jinfo/JInfo.java
! src/share/classes/sun/tools/jmap/JMap.java
! src/share/classes/sun/tools/jps/Jps.java
! src/share/classes/sun/tools/jstack/JStack.java
! src/share/classes/sun/tools/serialver/SerialVer.java
Changeset: 42532a097816
Author: naoto
Date: 2011-12-02 16:04 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/42532a097816
7117465: Warning cleanup for IMF classes
Reviewed-by: okutsu
! src/share/classes/java/awt/im/InputMethodHighlight.java
! src/share/classes/sun/awt/im/CompositionArea.java
! src/share/classes/sun/awt/im/CompositionAreaHandler.java
! src/share/classes/sun/awt/im/InputContext.java
! src/share/classes/sun/awt/im/InputMethodContext.java
! src/share/classes/sun/awt/im/InputMethodJFrame.java
! src/share/classes/sun/awt/im/InputMethodManager.java
! src/share/classes/sun/awt/im/SimpleInputMethodWindow.java
Changeset: 1d7037df65ed
Author: sherman
Date: 2011-12-02 16:25 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1d7037df65ed
5035850: (str) String.CASE_INSENSITIVE_ORDER should override readResolve()
Summary: Fix to ensure singleton property of String.CaseInsensitiveComparator is maintained through de/serialization.
Reviewed-by: alanb, forax, smarks, dholmes
Contributed-by: darryl.mocek at oracle.com
! src/share/classes/java/lang/String.java
+ test/java/lang/String/CaseInsensitiveComparator.java
Changeset: 98502d7a3f98
Author: mchung
Date: 2011-12-02 16:29 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/98502d7a3f98
7117585: Eliminate java.lang.instrument, java.lang.management warnings
Reviewed-by: mchung
Contributed-by: Jon VanAlten <jon.vanalten at redhat.com>
! src/share/classes/java/lang/instrument/ClassDefinition.java
! src/share/classes/java/lang/management/ManagementFactory.java
! src/share/classes/java/lang/management/PlatformComponent.java
Changeset: 3c524deb8431
Author: lancea
Date: 2011-12-02 19:33 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/3c524deb8431
7116445: Miscellaneous warnings in the JDBC/RowSet classes
Reviewed-by: smarks, chegar
! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java
! src/share/classes/com/sun/rowset/JoinRowSetImpl.java
! src/share/classes/com/sun/rowset/WebRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java
! src/share/classes/com/sun/rowset/internal/Row.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java
! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java
! src/share/classes/java/sql/Date.java
! src/share/classes/java/sql/DriverManager.java
! src/share/classes/java/sql/Time.java
! src/share/classes/java/sql/Timestamp.java
! src/share/classes/javax/sql/StatementEvent.java
! src/share/classes/javax/sql/rowset/BaseRowSet.java
! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java
! src/share/classes/javax/sql/rowset/RowSetProvider.java
! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java
! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
! src/share/classes/javax/sql/rowset/serial/SerialArray.java
! src/share/classes/javax/sql/rowset/serial/SerialBlob.java
! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java
! src/share/classes/javax/sql/rowset/serial/SerialRef.java
! src/share/classes/javax/sql/rowset/serial/SerialStruct.java
! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
Changeset: f2a5d0001f15
Author: okutsu
Date: 2011-12-03 10:58 +0900
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f2a5d0001f15
7117487: Warnings Cleanup: some i18n classes in java.util and sun.util
Reviewed-by: lancea, naoto
! src/share/classes/java/util/Date.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/JapaneseImperialCalendar.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/sun/util/calendar/BaseCalendar.java
! src/share/classes/sun/util/calendar/CalendarSystem.java
! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java
! src/share/classes/sun/util/calendar/ZoneInfo.java
! src/share/classes/sun/util/calendar/ZoneInfoFile.java
! src/share/classes/sun/util/resources/OpenListResourceBundle.java
! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java
Changeset: 2ae848ea980a
Author: weijun
Date: 2011-12-05 10:19 +0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/2ae848ea980a
7116857: Warnings in javax.security and some sun.misc
Reviewed-by: smarks
! src/share/classes/javax/security/auth/kerberos/ServicePermission.java
! src/share/classes/sun/misc/CEFormatException.java
! src/share/classes/sun/misc/CEStreamExhausted.java
! src/share/classes/sun/misc/ClassLoaderUtil.java
! src/share/classes/sun/misc/CompoundEnumeration.java
! src/share/classes/sun/misc/ExtensionInstallationException.java
! src/share/classes/sun/misc/FloatingDecimal.java
! src/share/classes/sun/misc/FormattedFloatingDecimal.java
! src/share/classes/sun/misc/InvalidJarIndexException.java
! src/share/classes/sun/misc/LRUCache.java
! src/share/classes/sun/misc/Queue.java
! src/share/classes/sun/misc/RequestProcessor.java
! src/share/classes/sun/misc/ServiceConfigurationError.java
! src/share/classes/sun/misc/URLClassPath.java
Changeset: 053cb321467a
Author: alanb
Date: 2011-12-05 12:23 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/053cb321467a
7117717: (aio) Tests failing due to implementation bug 7052549
Reviewed-by: weijun, chegar
! test/ProblemList.txt
! test/java/nio/channels/AsynchronousSocketChannel/Basic.java
Changeset: da28826c5672
Author: alanb
Date: 2011-12-05 12:24 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/da28826c5672
Merge
Changeset: f352dd3cdff8
Author: dl
Date: 2011-12-05 13:58 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f352dd3cdff8
7117360: Warnings in java.util.concurrent.atomic package
Reviewed-by: chegar, dholmes
! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java
! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java
Changeset: 194faa6fdb3c
Author: sherman
Date: 2011-12-05 10:50 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/194faa6fdb3c
5063455: (fmt) MissingFormatArgumentException.getFormatSpecifier() incorrect return value
Summary: updated the incorrect StringBuilder constructor usage
Reviewed-by: dholmes, sherman
Contributed-by: brandon.passanisi at oracle.com
! src/share/classes/java/util/Formatter.java
+ test/java/util/MissingFormatArgumentException/GetFormatSpecifier.java
Changeset: ca383e32deaf
Author: peytoia
Date: 2011-12-06 08:39 +0900
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/ca383e32deaf
7116914: Miscellaneous warnings (sun.text)
Reviewed-by: smarks, okutsu
! src/share/classes/sun/text/CompactByteArray.java
! src/share/classes/sun/text/IntHashtable.java
! src/share/classes/sun/text/bidi/BidiBase.java
! src/share/classes/sun/text/normalizer/ICUData.java
! src/share/classes/sun/text/normalizer/NormalizerBase.java
! src/share/classes/sun/text/normalizer/NormalizerImpl.java
! src/share/classes/sun/text/normalizer/SymbolTable.java
! src/share/classes/sun/text/normalizer/UnicodeSet.java
! src/share/classes/sun/text/normalizer/UnicodeSetIterator.java
! src/share/classes/sun/text/normalizer/VersionInfo.java
Changeset: f4fe86bba8a2
Author: smarks
Date: 2011-12-05 16:30 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f4fe86bba8a2
7116993: fix warnings in java.applet
Reviewed-by: art, smarks
Contributed-by: Danesh Dadachanji <ddadacha at redhat.com>
! src/share/classes/java/applet/Applet.java
Changeset: 85363edbc92f
Author: naoto
Date: 2011-12-05 17:08 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/85363edbc92f
7117469: Warning cleanup for j.u.Currency and j.u.Locale related classes
Reviewed-by: okutsu, smarks
! src/share/classes/java/util/Currency.java
! src/share/classes/sun/util/LocaleServiceProviderPool.java
! src/share/classes/sun/util/resources/LocaleData.java
Changeset: 77f6d4360f4b
Author: smarks
Date: 2011-12-06 10:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/77f6d4360f4b
7116997: fix warnings in java.util.PropertyPermission
Reviewed-by: smarks
Contributed-by: Brandon Passanisi <brandon.passanisi at oracle.com>
! src/share/classes/java/util/PropertyPermission.java
Changeset: b71d1acfae52
Author: lana
Date: 2011-12-06 20:25 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b71d1acfae52
Merge
! src/share/classes/java/beans/Beans.java
! src/share/classes/java/beans/Encoder.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/PropertyDescriptor.java
- 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
- test/java/util/ResourceBundle/Control/ExpirationTest.java
- test/java/util/ResourceBundle/Control/ExpirationTest.sh
From lana.steuck at oracle.com Tue Dec 13 19:16:16 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 13 Dec 2011 19:16:16 -0800 (PST)
Subject: jdk8-b17: JSN, Tools, Core Libraries, Serviceability, 2d, Awt,
and Swing
Message-ID: <201112140316.pBE3GGDE002909@jano-app.us.oracle.com>
http://hg.openjdk.java.net/jdk8/jdk8/rev/4e06ae613e99
http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/1cbe86c11ba6
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b71d1acfae52
http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/3d45ab79643d
http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/09eb517404b0
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d1f29d4e0bc6
http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/82dc033975bb
---
Component : 2d
Status : 0 major failures, 0 minor failures
Date : 12/12/2011 at 08:44
Tested By : Tony
Cost(total man-days): 1
Workspace : http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/8/2d/
Bundles : /net/jano1.us.oracle.com/export1/jcg/ws-depot/8/tl/build-archive/2011-12-07-042827.jcg-integrator.tl-pit-2d-awt/link-to-jprt-build/bundles
Platforms :
Others
Tests : /net/jano1.us.oracle.com/export1/jcg/ws-depot/8/tl/repo.latest-pit/jdk
Browsers : NA
Patches : NA
Logs : /net/jano1.us.oracle.com/export1/jcg/ws-depot/8/tl/build-archive/2011-12-07-042827.jcg-integrator.tl-pit-2d-awt/logs/webrev/
Number of Tests Executed : 0 product tests, 0 unit tests, 0 tck tests
Bug verification status:
======================================
Tested, Pass:
Tested, Pass (partial fixes):
Tested, Fail:
Untested bug fixes:
Setup is not available:
7116080: kcms need to support macosx
7117199: Fix javac warnings in src/share/classes/java/awt/font
Build change only:
New bugs filed:
Bugs in PIT build:
Bugs in earlier promoted build:
Number of PIT requested: 1
Integration target J2SE build number: 1.8.0-b17
Issues and Notes:
-------------------------------
>From Tony
Component : JDBC
Status : 0 major failures, 0 minor failures
Date : 12/08/2011 at 23:02
Tested By : Eugene
Cost(total man-days): 1
Workspace : /net/jano1.us.oracle.com/export1/jcg/ws-depot/8/tl/build-archive/2011-12-07-042827.jcg-integrator.tl-pit-2d-awt/link-to-jprt-build/bundles
Bundles : /net/jano1.us.oracle.com/export1/jcg/ws-depot/8/tl/build-archive/2011-12-07-042827.jcg-integrator.tl-pit-2d-awt/link-to-jprt-build/bundles
Platforms :
Others
Tests : http://stt-13.ru.oracle.com/hg/quality/index.cgi/170_int_ws/jdbc/
Browsers : NA
Patches : NA
Logs : http://vice.ru.oracle.com/newroot/results/1.8.0/b17/pit/JDBC/workDir/tonga.output/
Number of Tests Executed : 1117 product tests, 0 unit tests, 0 tck tests
Bug verification status:
======================================
Tested, Pass:
7116445: Clean up JDBC compile time warnings
Tested, Pass (partial fixes):
Tested, Fail:
Untested bug fixes:
Setup is not available:
Build change only:
New bugs filed:
Bugs in PIT build:
Bugs in earlier promoted build:
Number of PIT requested: 1
Integration target J2SE build number: 1.8.0-b17
Issues and Notes:
-------------------------------
>From Eugene
Component : i18n
Status : 0 major failures, 0 minor failures
Date : 12/12/2011 at 23:37
Tested By : tomonori.shioda at oracle.com
Cost(total man-days): 1
Workspace : /net/jano1.us.oracle.com/export1/jcg/ws-depot/8/tl/repo.latest-pit/jdk
Bundles : /net/jano1.us.oracle.com/export1/jcg/ws-depot/8/tl/build-archive/2011-11-08-234419.jcg-integrator.tl-pit-2d-awt/link-to-jprt-build/bundles
Platforms :
Others
Tests : /net/jano1.us.oracle.com/export1/jcg/ws-depot/8/tl/repo.latest-pit/jdk
Browsers : NA
Patches : NA
Logs : http://machao22.cn.oracle.com/j2se/8/i18n/results/b17/regression/Windows7_x64-sp1-ja/reportDir/
Number of Tests Executed : 1 product tests, 4 unit tests, 0 tck tests
Bug verification status:
======================================
Tested, Pass:
7116914: Miscellaneous warnings (sun.text)
7117465: Warning cleanup for IMF classes
7117469: Warning cleanup for j.u.Currency and j.u.Locale related classes
7117487: Warnings Cleanup: some i18n classes in java.util and sun.util
Tested, Pass (partial fixes):
Tested, Fail:
Untested bug fixes:
Setup is not available:
7056472: Speed up test/java/util/ResourceBundle/Control/ExpirationTest.sh
Build change only:
New bugs filed:
Bugs in PIT build:
Bugs in earlier promoted build:
Number of PIT requested: 1
Integration target J2SE build number: 1.8.0-b17
Issues and Notes:
-------------------------------
>From tomonori.shioda at oracle.com
The following fixes were waived by SQE:
5035850 java classes_lang (str) String.CASE_INSENSITIVE_ORDER should override readReso
5063455 java classes_util (fmt) MissingFormatArgumentException.getFormatSpecifier() in
6938583 java classes_swing Unexpected NullPointerException by InputContext.endCompositi
6996291 java classes_awt command line selection of MToolkit by -Dawt.toolkit=sun.awt.
7030624 java classes_io size_t usages in src/windows/native/java/io/io_util_md.c nee
7045370 java classes_awt Java Statically Determines Display Size on Linux platforms
7057459 java classes_beans Regression: Performance degradation with java.beans.XMLEnco
7064279 java classes_beans Introspector.getBeanInfo() should release some resources in
7086015 java compiler fix test/tools/javac/parser/netbeans/JavacParserTest.java
7087429 java classes_beans Constructor of java.beans.PropertyChangeEvent should declare
7087876 java classes_beans java/beans/PropertyDescriptor.html#createPropertyEditor() th
7092744 java classes_beans XMLEncoder fails to encode and breaks backward compatibility
7094995 java classes_util_jar test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.jav
7103610 java classes_awt _NET_WM_PID and WM_CLIENT_MACHINE are not set
7108598 java classes_awt Pogo Table Games freeze with JDK 7
7109085 java classes_swing Test use hotkeys not intended for Mac
7109092 java embedded Wrong computation results with double at armsflt
7109617 java classes_swing Test was writed for Metal L&F but not set it.
7109837 java classes_util_jar Provide a mechanism for computing an Adler32 checksum for th
7110149 java classes_util_jar Update the JDK8 bundled zlib library to the latest version 1
7110440 java classes_swing closed/javax/swing/JScrollBar/4865918/bug4865918.java fails
7110521 java classes_beans Regression test failed: Introspector/TestTypeResolver.java
7112925 java classes_swing closed/javax/swing/JTabbedPane/4624207/bug4624207.java fails
7113337 java classes_swing Swing closed test tries to click in the area reserved for re
7115046 java compiler Add AST node for lambda expressions
7115049 java compiler Add AST node for method references
7115050 java compiler Add parser support for lambda expressions
7115052 java compiler Add parser support for method references
7115070 java classes_nio (fs) lookupPrincipalByName/lookupPrincipalByGroupName should
7115150 java classes_net java.net.HttpCookie code cleanup, style, formatting, typos
7115357 java classes_swing closed/javax/swing/JTable/6263446/bug6263446Table.java fails
7115400 java classes_awt jdk 8 awt-gate build fails in headless toolkit on solaris.
7115524 java classes_security Regression: keytool -printcert -sslserver failure
7115586 java classes_nio (so) Suppress creation of SocketImpl in SocketAdaptor's cons
7115744 java classes_security Do not call File::deleteOnExit in security tests
7116322 java build enhance javac make rule with a little bit of instrumentation
7116404 java other Miscellaneous warnings (java.rmi.**, serialization, some cor
7116722 java other Miscellaneous warnings sun.misc ( and related classes )
7116857 java classes_security Warnings in javax.security and some sun.misc
7116890 java classes_io additional warnings fixes for java.io
7116946 java classes_sound JSSecurityManager should use java.util.ServiceLoader to look
7116954 java classes_beans Misc warnings in java.beans/java.beans.context
7116957 scri api javax.script.ScriptEngineManager should use java.util.Servic
7116993 java classes_awt Misc warnings in java.applet
7116997 java classes_util Misc warnings in java.util.PropertyPermission
7117357 java other Warnings in sun.instrument, tools and other sun.* classes
7117360 java classes_util_con Warnings in java.util.concurrent.atomic package
7117585 java other Eliminate java.lang.instrument, java.lang.management warning
7117717 java classes_nio (aio) Tests failing due to implementation bug 7052549
7117914 hots runtime_system i keep getting reports on my desk top.
7119032 java compiler (javac) increase visibility of JavacParser methods to improv
7119487 java compiler JavacParserTest.java test fails on Windows platforms
7120266 java compiler javac fails to compile hotspot code
From stuart.marks at oracle.com Wed Dec 14 15:22:44 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 14 Dec 2011 15:22:44 -0800
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <FC2F76EA-9A99-4E27-9D50-4242B684A59A@oracle.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<20111202184726.GX2461@redhat.com>
<21DB2F64-8352-4574-8EFB-58A0C563D907@oracle.com>
<20111205203050.GL8668@redhat.com>
<FC2F76EA-9A99-4E27-9D50-4242B684A59A@oracle.com>
Message-ID: <4EE92FC4.1080400@oracle.com>
Hi Deepak,
Any update on this? It sounds like it's fairly close to being finished. Just
because Warnings Cleanup Day (Week) is over doesn't mean that we should give up.
s'marks
On 12/6/11 5:26 PM, John Rose wrote:
> On Dec 5, 2011, at 12:30 PM, Deepak Bhole wrote:
>
>>> Since this is an important point, I checked into it. Result: Wildcards
>>> cannot (in general) be compatibly switched with named type parameters
>>> in public APIs.
>>> See the demonstration here:
>>> [1]https://gist.github.com/1424776
>>> (This is subject to correction by someone more expert than me in API
>>> evolution, like Alex Buckley, Joe Darcy, or Maurizio Cimadamore. I'm a
>>> JVM hacker!)
>>>
>>
>> Thanks for the pointer! Yes, it is rather unfortunate that it cannot
>> changed then :( I have reverted it and added a more localized @SW
>> instead.
>
> Good. I puzzled some more over the localized @SW and found a formulation
> that does not require any @SW at all. It's a matter of choosing wildcards very
> carefully. See patch below.
>
> Basically, it's one of those cases where a type T isn't good enough, but a type
> "? extends T" will do the job. (I can't tell you all such cases, but this is one of them!)
>
>>> I'm OK with that. Replacing clone by an equivalent copy constructor
>>> looks trivial enough to me, even though it changes bytecode output.
>>>
>>
>> As mentioned in my other email to R?mi, the clone constructor was my
>> initial plan but didn't work. Instead I am just initializing a temp var
>> (so that I can add a localized @SW) and then assigning the outer scope
>> var to it.
>
> Good.
>
>>> Yep. SW("serial") seems to be the wrong thing, almost everywhere.
>>
>> Out of curiosity, why is this? Is it because not having a serial can
>> cause invalid class errors or are there other reasons?
>
> If you don't have a SVUID, the system makes one for you. (It is the same
> one your IDE can generate explicitly.) If you way @SW("serial"), you are
> telling the system that it can adjust the SVUID at will. You get into trouble
> with this if somebody adds another (non-transient) field. This changes the
> implicit SVUID. This can lead to surprising results down the road.
>
>> Thanks for taking a look. New webrev:
>> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.02/
>>
>> As with before, diff between rev 01 and 02 is there too:
>> http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.02/rev-01-02.patch
>
>
>
> On Dec 2, 2011, at 2:12 PM, John Rose wrote:
>
>>>> In the same way, consider pushing the annotation into the body of class AttributeEntry, even though that class is very simple.
>>>>
>>>
>>> That one is for the declaration itself -- the warning is about the Map
>>> supertype not being parameterized.
>>
>>
>> I didn't get that clearly from the comment. Suggest:
>> +// Suppress warning about raw Map.Entry. Parameterizing Map.Entry correctly
>> +// requires changing return of getKey
>> ++// Must suppress the whole class to suppress warning about raw supertype Map.Entry.
>> ++// Parameterizing Map.Entry correctly would requires changing return of getKey.
>
> I went back to class AttributeEntry and realized that it also does not need @SW.
> Since it is a non-public class, it is OK to change the supertype and the return value
> of getKey. A simple correction to the type parameters of a non-public name is in
> scope for this project, as I read Stuart here:
> http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000380.html
>
> -+// Must suppress the whole class to suppress warning about raw supertype Map.Entry.
> -+// Parameterizing Map.Entry correctly would requires changing return of getKey.
> -+ at SuppressWarnings("rawtypes")
> -class AttributeEntry implements Map.Entry {
> ++class AttributeEntry implements Map.Entry<Attribute,Object> {
> ...
> - public Object getKey() {
> ++ public Attribute getKey() {
>
> (I could be mistaken about this; please double check. I made a public API
> mistake in my own java.lang.invoke warnings cleanup!)
>
> Also, I noticed some extraneous blank lines surrounding @SW occurrences.
> They aren't needed. Also, a few occurrences of @SW({"foo"}) do not need
> the braces: @SW("foo").
>
> Here are all the adjustments I suggest, in one patch:
> https://gist.github.com/1440966
>
> See if they work for you. If so, we're done.
>
> -- John
From david.katleman at sun.com Thu Dec 15 13:18:06 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 15 Dec 2011 21:18:06 +0000
Subject: hg: jdk8/jdk8: Added tag jdk8-b17 for changeset 4e06ae613e99
Message-ID: <20111215211806.ED670476E4@hg.openjdk.java.net>
Changeset: 8606f4ab62dc
Author: katleman
Date: 2011-12-15 12:16 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/8606f4ab62dc
Added tag jdk8-b17 for changeset 4e06ae613e99
! .hgtags
From david.katleman at sun.com Thu Dec 15 13:18:17 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 15 Dec 2011 21:18:17 +0000
Subject: hg: jdk8/jdk8/corba: Added tag jdk8-b17 for changeset 82dc033975bb
Message-ID: <20111215211817.9C5EB476E6@hg.openjdk.java.net>
Changeset: 05f47d29b438
Author: katleman
Date: 2011-12-15 12:16 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/05f47d29b438
Added tag jdk8-b17 for changeset 82dc033975bb
! .hgtags
From david.katleman at sun.com Thu Dec 15 13:19:07 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 15 Dec 2011 21:19:07 +0000
Subject: hg: jdk8/jdk8/hotspot: Added tag jdk8-b17 for changeset d1f29d4e0bc6
Message-ID: <20111215211909.54458476E7@hg.openjdk.java.net>
Changeset: 698a22e99f74
Author: katleman
Date: 2011-12-15 12:16 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/698a22e99f74
Added tag jdk8-b17 for changeset d1f29d4e0bc6
! .hgtags
From david.katleman at sun.com Thu Dec 15 13:20:44 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 15 Dec 2011 21:20:44 +0000
Subject: hg: jdk8/jdk8/jaxp: Added tag jdk8-b17 for changeset 09eb517404b0
Message-ID: <20111215212044.EFA0D476E9@hg.openjdk.java.net>
Changeset: db44484a9d6e
Author: katleman
Date: 2011-12-15 12:16 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/db44484a9d6e
Added tag jdk8-b17 for changeset 09eb517404b0
! .hgtags
From david.katleman at sun.com Thu Dec 15 13:20:57 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 15 Dec 2011 21:20:57 +0000
Subject: hg: jdk8/jdk8/jaxws: Added tag jdk8-b17 for changeset 3d45ab79643d
Message-ID: <20111215212057.914FB476EA@hg.openjdk.java.net>
Changeset: b38846b9974c
Author: katleman
Date: 2011-12-15 12:16 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/b38846b9974c
Added tag jdk8-b17 for changeset 3d45ab79643d
! .hgtags
From david.katleman at sun.com Thu Dec 15 13:21:06 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 15 Dec 2011 21:21:06 +0000
Subject: hg: jdk8/jdk8/jdk: Added tag jdk8-b17 for changeset b71d1acfae52
Message-ID: <20111215212116.5F8DB476EB@hg.openjdk.java.net>
Changeset: cd95291bbbf3
Author: katleman
Date: 2011-12-15 12:16 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cd95291bbbf3
Added tag jdk8-b17 for changeset b71d1acfae52
! .hgtags
From david.katleman at sun.com Thu Dec 15 13:22:27 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 15 Dec 2011 21:22:27 +0000
Subject: hg: jdk8/jdk8/langtools: Added tag jdk8-b17 for changeset 1cbe86c11ba6
Message-ID: <20111215212230.0FADA476EC@hg.openjdk.java.net>
Changeset: 55a49c399603
Author: katleman
Date: 2011-12-15 12:16 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/55a49c399603
Added tag jdk8-b17 for changeset 1cbe86c11ba6
! .hgtags
From david.katleman at sun.com Thu Dec 15 16:00:35 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 16 Dec 2011 00:00:35 +0000
Subject: hg: jdk8/jdk8: 2 new changesets
Message-ID: <20111216000035.91F5B476F5@hg.openjdk.java.net>
Changeset: d82d3bb3a2e5
Author: katleman
Date: 2011-12-15 15:47 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/d82d3bb3a2e5
Added tag jdk8-b16 for changeset 4e06ae613e99
! .hgtags
Changeset: 7010bd24cdd0
Author: katleman
Date: 2011-12-15 15:51 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/7010bd24cdd0
Merge
! .hgtags
From david.katleman at sun.com Thu Dec 15 16:00:51 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 16 Dec 2011 00:00:51 +0000
Subject: hg: jdk8/jdk8/corba: 2 new changesets
Message-ID: <20111216000053.2CE60476F6@hg.openjdk.java.net>
Changeset: 6e51ad8d3707
Author: katleman
Date: 2011-12-15 15:47 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/6e51ad8d3707
Added tag jdk8-b16 for changeset 82dc033975bb
! .hgtags
Changeset: 312cf15d1657
Author: katleman
Date: 2011-12-15 15:52 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/312cf15d1657
Merge
! .hgtags
From david.katleman at sun.com Thu Dec 15 16:01:32 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 16 Dec 2011 00:01:32 +0000
Subject: hg: jdk8/jdk8/hotspot: 2 new changesets
Message-ID: <20111216000136.DB997476F7@hg.openjdk.java.net>
Changeset: 09f3b8a372b2
Author: katleman
Date: 2011-12-15 15:47 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/09f3b8a372b2
Added tag jdk8-b16 for changeset d1f29d4e0bc6
! .hgtags
Changeset: e46c2339d0fc
Author: katleman
Date: 2011-12-15 15:52 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/e46c2339d0fc
Merge
! .hgtags
From david.katleman at sun.com Thu Dec 15 16:02:56 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 16 Dec 2011 00:02:56 +0000
Subject: hg: jdk8/jdk8/jaxp: 2 new changesets
Message-ID: <20111216000256.1F110476F8@hg.openjdk.java.net>
Changeset: bc3ed3122933
Author: katleman
Date: 2011-12-15 15:47 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/bc3ed3122933
Added tag jdk8-b16 for changeset 09eb517404b0
! .hgtags
Changeset: ebec6a7e8d4e
Author: katleman
Date: 2011-12-15 15:54 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/ebec6a7e8d4e
Merge
! .hgtags
From david.katleman at sun.com Thu Dec 15 16:03:02 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 16 Dec 2011 00:03:02 +0000
Subject: hg: jdk8/jdk8/jaxws: 2 new changesets
Message-ID: <20111216000302.B062F476F9@hg.openjdk.java.net>
Changeset: e662b652098c
Author: katleman
Date: 2011-12-15 15:47 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/e662b652098c
Added tag jdk8-b16 for changeset 3d45ab79643d
! .hgtags
Changeset: 54928c8850f5
Author: katleman
Date: 2011-12-15 15:54 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/54928c8850f5
Merge
! .hgtags
From david.katleman at sun.com Thu Dec 15 16:03:30 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 16 Dec 2011 00:03:30 +0000
Subject: hg: jdk8/jdk8/jdk: 2 new changesets
Message-ID: <20111216000349.934C2476FA@hg.openjdk.java.net>
Changeset: 8f3d916a9164
Author: katleman
Date: 2011-12-15 15:47 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/8f3d916a9164
Added tag jdk8-b16 for changeset 929597c6e777
! .hgtags
Changeset: e55ac966ed95
Author: katleman
Date: 2011-12-15 15:55 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/e55ac966ed95
Merge
! .hgtags
- make/sun/motif12/reorder-i586
- make/sun/motif12/reorder-sparc
- make/sun/motif12/reorder-sparcv9
- 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
- src/solaris/classes/sun/awt/motif/AWTLockAccess.java
- src/solaris/classes/sun/awt/motif/MFontPeer.java
- src/solaris/classes/sun/awt/motif/MToolkit.java
- src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java
- src/solaris/classes/sun/awt/motif/MWindowAttributes.java
- src/solaris/classes/sun/awt/motif/X11FontMetrics.java
- src/solaris/native/sun/awt/MouseInfo.c
- src/solaris/native/sun/awt/XDrawingArea.c
- src/solaris/native/sun/awt/XDrawingArea.h
- src/solaris/native/sun/awt/XDrawingAreaP.h
- src/solaris/native/sun/awt/awt_Cursor.h
- src/solaris/native/sun/awt/awt_KeyboardFocusManager.h
- src/solaris/native/sun/awt/awt_MToolkit.c
- src/solaris/native/sun/awt/awt_MToolkit.h
- src/solaris/native/sun/awt/awt_MenuItem.h
- src/solaris/native/sun/awt/awt_PopupMenu.h
- src/solaris/native/sun/awt/awt_TopLevel.h
- src/solaris/native/sun/awt/awt_Window.h
- src/solaris/native/sun/awt/awt_mgrsel.c
- src/solaris/native/sun/awt/awt_mgrsel.h
- src/solaris/native/sun/awt/awt_motif.h
- src/solaris/native/sun/awt/awt_wm.c
- src/solaris/native/sun/awt/awt_wm.h
- src/solaris/native/sun/awt/awt_xembed.h
- src/solaris/native/sun/awt/awt_xembed_server.c
- src/solaris/native/sun/awt/awt_xembed_server.h
- test/java/util/ResourceBundle/Control/ExpirationTest.java
- test/java/util/ResourceBundle/Control/ExpirationTest.sh
From david.katleman at sun.com Thu Dec 15 16:05:19 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 16 Dec 2011 00:05:19 +0000
Subject: hg: jdk8/jdk8/langtools: 2 new changesets
Message-ID: <20111216000524.0F7EC476FB@hg.openjdk.java.net>
Changeset: 29a512337b79
Author: katleman
Date: 2011-12-15 15:47 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/29a512337b79
Added tag jdk8-b16 for changeset ec2c0973cc31
! .hgtags
Changeset: ab1b1cc78577
Author: katleman
Date: 2011-12-15 15:57 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ab1b1cc78577
Merge
! .hgtags
- test/tools/javac/parser/netbeans/JavacParserTest.java
From dbhole at redhat.com Mon Dec 19 10:01:04 2011
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 19 Dec 2011 13:01:04 -0500
Subject: Review request for java.text.** warning cleanup
In-Reply-To: <4EE92FC4.1080400@oracle.com>
References: <20111201231919.GQ2461@redhat.com>
<1D669183-D946-46C8-AB54-D6140D1C4093@oracle.com>
<20111202184726.GX2461@redhat.com>
<21DB2F64-8352-4574-8EFB-58A0C563D907@oracle.com>
<20111205203050.GL8668@redhat.com>
<FC2F76EA-9A99-4E27-9D50-4242B684A59A@oracle.com>
<4EE92FC4.1080400@oracle.com>
Message-ID: <20111219180103.GH752@redhat.com>
* Stuart Marks <stuart.marks at oracle.com> [2011-12-14 18:21]:
> Hi Deepak,
>
> Any update on this? It sounds like it's fairly close to being
> finished. Just because Warnings Cleanup Day (Week) is over doesn't
> mean that we should give up.
>
Hi Stuart,
As Andrew already mentioned, I was away and got back on Friday. I've
just sent a message to John to get the final matters sorted out.
Hopefully this will get pushed soon!
Cheers,
Deepak
> s'marks
>
> On 12/6/11 5:26 PM, John Rose wrote:
> >On Dec 5, 2011, at 12:30 PM, Deepak Bhole wrote:
> >
> >>> Since this is an important point, I checked into it. Result: Wildcards
> >>> cannot (in general) be compatibly switched with named type parameters
> >>> in public APIs.
> >>> See the demonstration here:
> >>> [1]https://gist.github.com/1424776
> >>> (This is subject to correction by someone more expert than me in API
> >>> evolution, like Alex Buckley, Joe Darcy, or Maurizio Cimadamore. I'm a
> >>> JVM hacker!)
> >>>
> >>
> >>Thanks for the pointer! Yes, it is rather unfortunate that it cannot
> >>changed then :( I have reverted it and added a more localized @SW
> >>instead.
> >
> >Good. I puzzled some more over the localized @SW and found a formulation
> >that does not require any @SW at all. It's a matter of choosing wildcards very
> >carefully. See patch below.
> >
> >Basically, it's one of those cases where a type T isn't good enough, but a type
> >"? extends T" will do the job. (I can't tell you all such cases, but this is one of them!)
> >
> >>> I'm OK with that. Replacing clone by an equivalent copy constructor
> >>> looks trivial enough to me, even though it changes bytecode output.
> >>>
> >>
> >>As mentioned in my other email to R?mi, the clone constructor was my
> >>initial plan but didn't work. Instead I am just initializing a temp var
> >>(so that I can add a localized @SW) and then assigning the outer scope
> >>var to it.
> >
> >Good.
> >
> >>> Yep. SW("serial") seems to be the wrong thing, almost everywhere.
> >>
> >>Out of curiosity, why is this? Is it because not having a serial can
> >>cause invalid class errors or are there other reasons?
> >
> >If you don't have a SVUID, the system makes one for you. (It is the same
> >one your IDE can generate explicitly.) If you way @SW("serial"), you are
> >telling the system that it can adjust the SVUID at will. You get into trouble
> >with this if somebody adds another (non-transient) field. This changes the
> >implicit SVUID. This can lead to surprising results down the road.
> >
> >>Thanks for taking a look. New webrev:
> >>http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.02/
> >>
> >>As with before, diff between rev 01 and 02 is there too:
> >>http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.02/rev-01-02.patch
> >
> >
> >
> >On Dec 2, 2011, at 2:12 PM, John Rose wrote:
> >
> >>>>In the same way, consider pushing the annotation into the body of class AttributeEntry, even though that class is very simple.
> >>>>
> >>>
> >>>That one is for the declaration itself -- the warning is about the Map
> >>>supertype not being parameterized.
> >>
> >>
> >>I didn't get that clearly from the comment. Suggest:
> >>+// Suppress warning about raw Map.Entry. Parameterizing Map.Entry correctly
> >>+// requires changing return of getKey
> >>++// Must suppress the whole class to suppress warning about raw supertype Map.Entry.
> >>++// Parameterizing Map.Entry correctly would requires changing return of getKey.
> >
> >I went back to class AttributeEntry and realized that it also does not need @SW.
> >Since it is a non-public class, it is OK to change the supertype and the return value
> >of getKey. A simple correction to the type parameters of a non-public name is in
> >scope for this project, as I read Stuart here:
> > http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000380.html
> >
> >-+// Must suppress the whole class to suppress warning about raw supertype Map.Entry.
> >-+// Parameterizing Map.Entry correctly would requires changing return of getKey.
> >-+ at SuppressWarnings("rawtypes")
> >-class AttributeEntry implements Map.Entry {
> >++class AttributeEntry implements Map.Entry<Attribute,Object> {
> >...
> >- public Object getKey() {
> >++ public Attribute getKey() {
> >
> >(I could be mistaken about this; please double check. I made a public API
> >mistake in my own java.lang.invoke warnings cleanup!)
> >
> >Also, I noticed some extraneous blank lines surrounding @SW occurrences.
> >They aren't needed. Also, a few occurrences of @SW({"foo"}) do not need
> >the braces: @SW("foo").
> >
> >Here are all the adjustments I suggest, in one patch:
> > https://gist.github.com/1440966
> >
> >See if they work for you. If so, we're done.
> >
> >-- John
From igor.nekrestyanov at oracle.com Mon Dec 19 10:41:43 2011
From: igor.nekrestyanov at oracle.com (igor.nekrestyanov at oracle.com)
Date: Mon, 19 Dec 2011 18:41:43 +0000
Subject: hg: jdk8/jdk8/jdk: 5 new changesets
Message-ID: <20111219184242.2E59547759@hg.openjdk.java.net>
Changeset: 134420afe9c2
Author: ngthomas
Date: 2011-11-13 21:39 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/134420afe9c2
7109885: security baseline for 7u2 or above is not set correctly
Reviewed-by: ccheung, igor, ohair
! make/common/shared/Sanity.gmk
Changeset: 6f594239e9dc
Author: ngthomas
Date: 2011-11-15 23:33 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6f594239e9dc
7112298: remove security baseline sanity check
Reviewed-by: ccheung, igor, ohair
! make/common/shared/Sanity.gmk
Changeset: fcc7cafa0027
Author: herrick
Date: 2011-11-18 06:35 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/fcc7cafa0027
Merge
- make/sun/rmi/rmi/mapfile-vers
- src/share/classes/sun/security/pkcs/EncodingException.java
- src/share/classes/sun/security/pkcs/PKCS10.java
- src/share/classes/sun/security/pkcs/PKCS10Attribute.java
- src/share/classes/sun/security/pkcs/PKCS10Attributes.java
- src/share/classes/sun/security/util/BigInt.java
- src/share/classes/sun/security/util/PathList.java
- src/share/classes/sun/security/x509/CertAndKeyGen.java
- src/share/native/sun/rmi/server/MarshalInputStream.c
- test/java/net/DatagramSocket/ChangingAddress.java
- test/sun/security/util/BigInt/BigIntEqualsHashCode.java
Changeset: 526e99f06a59
Author: igor
Date: 2011-12-06 16:31 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/526e99f06a59
Merge
- test/java/io/FileDescriptor/FileChannelFDTest.java
- test/java/io/etc/FileDescriptorSharing.java
Changeset: 334bd51fb3f3
Author: igor
Date: 2011-12-19 10:06 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/334bd51fb3f3
Merge
- make/sun/motif12/reorder-i586
- make/sun/motif12/reorder-sparc
- make/sun/motif12/reorder-sparcv9
- 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
- src/solaris/classes/sun/awt/motif/AWTLockAccess.java
- src/solaris/classes/sun/awt/motif/MFontPeer.java
- src/solaris/classes/sun/awt/motif/MToolkit.java
- src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java
- src/solaris/classes/sun/awt/motif/MWindowAttributes.java
- src/solaris/classes/sun/awt/motif/X11FontMetrics.java
- src/solaris/native/sun/awt/MouseInfo.c
- src/solaris/native/sun/awt/XDrawingArea.c
- src/solaris/native/sun/awt/XDrawingArea.h
- src/solaris/native/sun/awt/XDrawingAreaP.h
- src/solaris/native/sun/awt/awt_Cursor.h
- src/solaris/native/sun/awt/awt_KeyboardFocusManager.h
- src/solaris/native/sun/awt/awt_MToolkit.c
- src/solaris/native/sun/awt/awt_MToolkit.h
- src/solaris/native/sun/awt/awt_MenuItem.h
- src/solaris/native/sun/awt/awt_PopupMenu.h
- src/solaris/native/sun/awt/awt_TopLevel.h
- src/solaris/native/sun/awt/awt_Window.h
- src/solaris/native/sun/awt/awt_mgrsel.c
- src/solaris/native/sun/awt/awt_mgrsel.h
- src/solaris/native/sun/awt/awt_motif.h
- src/solaris/native/sun/awt/awt_wm.c
- src/solaris/native/sun/awt/awt_wm.h
- src/solaris/native/sun/awt/awt_xembed.h
- src/solaris/native/sun/awt/awt_xembed_server.c
- src/solaris/native/sun/awt/awt_xembed_server.h
- test/java/util/ResourceBundle/Control/ExpirationTest.java
- test/java/util/ResourceBundle/Control/ExpirationTest.sh
From john.coomes at oracle.com Tue Dec 20 16:47:14 2011
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 21 Dec 2011 00:47:14 +0000
Subject: hg: jdk8/jdk8/hotspot: 53 new changesets
Message-ID: <20111221004901.A5CA047773@hg.openjdk.java.net>
Changeset: da4182086289
Author: jcoomes
Date: 2011-11-18 17:39 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/da4182086289
7113503: Bump the hs23 build number to 07
Reviewed-by: johnc
Contributed-by: alejandro.murillo at oracle.com
! make/hotspot_version
Changeset: 36b057451829
Author: dholmes
Date: 2011-11-16 20:38 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/36b057451829
7110017: is_headless_jre should be updated to reflect the new location of awt toolkit libraries
Reviewed-by: dholmes, dsamersoff
Contributed-by: Chris Hegarty <chris.hegarty at oracle.com>
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
Changeset: 002cb3fc8256
Author: coleenp
Date: 2011-11-18 17:26 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/002cb3fc8256
Merge
Changeset: c17bc65648de
Author: brutisso
Date: 2011-11-21 08:02 +0100
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/c17bc65648de
7112308: Fix Visual Studio build for precompiled header
Summary: Add the new path to precompiled.hpp in the project make file
Reviewed-by: coleenp, dholmes, brutisso
Contributed-by: rbackman <rickard.backman at oracle.com>
! make/windows/makefiles/projectcreator.make
Changeset: 1d090cf33da6
Author: coleenp
Date: 2011-11-21 10:22 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1d090cf33da6
Merge
Changeset: 242b4e0e6f73
Author: phh
Date: 2011-11-29 09:21 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/242b4e0e6f73
7116189: Export JVM_SetNativeThreadName from Hotspot
Summary: Added JVM_SetNativeThreadName to linker mapfiles on Solaris and Linux.
Reviewed-by: dcubed, dholmes
Contributed-by: michael.x.mcmahon at oracle.com
! make/linux/makefiles/mapfile-vers-debug
! make/linux/makefiles/mapfile-vers-product
! make/solaris/makefiles/mapfile-vers
Changeset: 763f01599ff4
Author: phh
Date: 2011-11-29 17:00 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/763f01599ff4
7116481: Commercial features in Hotspot must be gated by a switch
Summary: Add -XX:+UnlockCommercialVMOptions to gate use of commercial feature switches in the same way as -XX:UnlockDiagnosticVMOptions gates use of diagnostic feature switches.
Reviewed-by: jwilhelm, kamg
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/globals_extension.hpp
Changeset: 358eca91be48
Author: phh
Date: 2011-11-30 12:48 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/358eca91be48
7116730: Revert 7116481: Commercial features in Hotspot must be gated by a switch
Summary: Revert 7116481 to current hsx/hotspot-main
Reviewed-by: kamg
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/globals_extension.hpp
Changeset: 81a08cd7f6a1
Author: coleenp
Date: 2011-12-01 13:42 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/81a08cd7f6a1
Merge
Changeset: a88de71c4e3a
Author: tonyp
Date: 2011-11-18 12:52 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a88de71c4e3a
7097002: G1: remove a lot of unused / redundant code from the G1CollectorPolicy class
Summary: Major cleanup of the G1CollectorPolicy class. It removes a lot of unused fields and methods and also consolidates replicated information (mainly various ways of counting the number of CSet regions) into one copy.
Reviewed-by: johnc, brutisso
! 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/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
Changeset: d06a2d7fcd5b
Author: brutisso
Date: 2011-11-21 07:47 +0100
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d06a2d7fcd5b
7110718: -XX:MarkSweepAlwaysCompactCount=0 crashes the JVM
Summary: Interpret MarkSweepAlwaysCompactCount < 1 as never do full compaction
Reviewed-by: ysr, tonyp, jmasa, johnc
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp
! src/share/vm/memory/space.hpp
Changeset: b5a5f30c483d
Author: johnc
Date: 2011-11-21 09:24 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b5a5f30c483d
7110173: GCNotifier::pushNotification publishes stale data.
Summary: GCNotifier::pushNotification() references GCMemoryManager::_last_gc_stat but is called from GCMemoryManager::gc_end() before GCMemoryManager::_last_gc_stat is set up using the values in GCMemoryManager::_current_gc_stat. As a result the GC notification code accesses unitialized or stale data. Move the notification call after GCMemoryManager::_las_gc_stat is set, but inside the same if-block.
Reviewed-by: poonam, dholmes, fparain, mchung
! src/share/vm/services/memoryManager.cpp
Changeset: 6071e0581859
Author: johnc
Date: 2011-11-18 12:27 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/6071e0581859
7111795: G1: Various cleanups identified during walk through of changes for 6484965
Summary: Various cleanups and formatting changes identified during a code walk through of the changes for 6484965 ("G1: piggy-back liveness accounting phase on marking").
Reviewed-by: brutisso, tonyp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
Changeset: 3a298e04d914
Author: tonyp
Date: 2011-11-22 04:47 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/3a298e04d914
Merge
Changeset: bca17e38de00
Author: jmasa
Date: 2011-08-09 10:16 -0700
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/bca17e38de00
6593758: RFE: Enhance GC ergonomics to dynamically choose ParallelGCThreads
Summary: Select number of GC threads dynamically based on heap usage and number of Java threads
Reviewed-by: johnc, ysr, jcoomes
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! 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/g1RemSet.cpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp
! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp
! 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/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/memory/sharedHeap.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp
! src/share/vm/utilities/yieldingWorkgroup.cpp
! src/share/vm/utilities/yieldingWorkgroup.hpp
Changeset: 00dd86e542eb
Author: johnc
Date: 2011-11-28 09:49 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/00dd86e542eb
7114303: G1: assert(_g1->mark_in_progress()) failed: shouldn't be here otherwise
Summary: Race between the VM thread reading G1CollectedHeap::_mark_in_progress and it being set by the concurrent mark thread when concurrent marking is aborted by a full GC. Have the concurrent mark thread join the SuspendibleThreadSet before changing the marking state.
Reviewed-by: tonyp, brutisso
! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
Changeset: dc467e8b2c5e
Author: johnc
Date: 2011-11-17 12:40 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/dc467e8b2c5e
7112743: G1: Reduce overhead of marking closure during evacuation pauses
Summary: Parallelize the serial code that was used to mark objects reachable from survivor objects in the collection set. Some minor improvments in the timers used to track the freeing of the collection set along with some tweaks to PrintGCDetails.
Reviewed-by: tonyp, brutisso
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! 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/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/oops/objArrayOop.hpp
Changeset: ea640b5e949a
Author: jmasa
Date: 2011-11-22 14:18 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/ea640b5e949a
7106024: CMS: Removed unused code for precleaning in remark phase
Summary: Remove dead code.
Reviewed-by: stefank, ysr
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp
Changeset: 7913e93dca52
Author: jmasa
Date: 2011-11-22 14:59 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/7913e93dca52
7112997: Remove obsolete code ResetObjectsClosure and VerifyUpdateClosure
Summary: Remove obsolete code.
Reviewed-by: brutisso, ysr, jcoomes
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_implementation/shared/markSweep.hpp
! src/share/vm/gc_implementation/shared/markSweep.inline.hpp
Changeset: 1bbf5b6fb7b0
Author: tonyp
Date: 2011-12-02 08:52 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1bbf5b6fb7b0
Merge
! src/share/vm/runtime/globals.hpp
Changeset: 6de8c9ba5907
Author: jcoomes
Date: 2011-12-02 15:11 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/6de8c9ba5907
Merge
Changeset: aed8bf036ce2
Author: jcoomes
Date: 2011-12-02 15:11 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/aed8bf036ce2
Added tag hs23-b07 for changeset 6de8c9ba5907
! .hgtags
Changeset: cf4dd13bbcd3
Author: jcoomes
Date: 2011-12-02 21:10 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/cf4dd13bbcd3
7117536: new hotspot build - hs23-b08
Reviewed-by: johnc
! make/hotspot_version
Changeset: cd00eaeebef6
Author: phh
Date: 2011-12-05 12:50 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/cd00eaeebef6
7117389: Add a framework for vendor-specific command line switch extensions to Hotspot
Summary: Add a file, globals_ext.hpp, containing a null interface, to be replaced by a vendor in altsrc as needed.
Reviewed-by: coleenp, kamg, dholmes, johnc, jrose
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
+ src/share/vm/runtime/globals_ext.hpp
! src/share/vm/runtime/globals_extension.hpp
Changeset: 8657ec177a14
Author: dcubed
Date: 2011-12-05 14:55 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/8657ec177a14
7117748: SA_APPLE_BOOT_JAVA and ALWAYS_PASS_TEST_GAMMA settings should not be required on MacOS X
Summary: Replace SA_APPLE_BOOT_JAVA with logic that checks the boot JDK for the location of JDI classes. ALWAYS_PASS_TEST_GAMMA is true by default on Darwin.
Reviewed-by: kvn, swingler
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/sa.make
Changeset: 41cce03b29a8
Author: dcubed
Date: 2011-12-06 05:28 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/41cce03b29a8
Merge
Changeset: 03865c41c4f3
Author: vladidan
Date: 2011-12-06 16:35 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/03865c41c4f3
Merge
! src/share/vm/runtime/globals.hpp
Changeset: 55d777c0860a
Author: dcubed
Date: 2011-12-07 07:27 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/55d777c0860a
7118648: disable compressed oops by default on MacOS X until 7118647 is fixed
Summary: UseCompressedOops is false by default on MacOS X; can still be set manually
Reviewed-by: jmelvin, kvn, dholmes
! src/share/vm/runtime/arguments.cpp
Changeset: e8fdaf4a66cb
Author: kvn
Date: 2011-11-10 20:17 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/e8fdaf4a66cb
7110586: C2 generates incorrect results
Summary: Exact limit of empty loop calculated incorrectly.
Reviewed-by: iveresov, never
! src/share/vm/opto/loopnode.cpp
+ test/compiler/7110586/Test7110586.java
Changeset: 8c57262447d3
Author: kvn
Date: 2011-11-14 18:38 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/8c57262447d3
7105605: Use EA info to optimize pointers compare
Summary: optimize pointers compare using EA information.
Reviewed-by: never, twisti
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/escape.hpp
Changeset: 6729bbc1fcd6
Author: twisti
Date: 2011-11-16 01:39 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/6729bbc1fcd6
7003454: order constants in constant table by number of references in code
Reviewed-by: kvn, never, bdelsart
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/matcher.hpp
Changeset: 1bd45abaa507
Author: kvn
Date: 2011-11-16 09:13 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1bd45abaa507
6890673: Eliminate allocations immediately after EA
Summary: Try to eliminate allocations and related locks immediately after escape analysis.
Reviewed-by: never
! src/share/vm/opto/block.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/macro.hpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
Changeset: 973293defacd
Author: iveresov
Date: 2011-11-16 19:42 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/973293defacd
7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks
Summary: Move the inlinee invoke notification callback into inlinee preamble
Reviewed-by: kvn, never
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp
! src/share/vm/runtime/simpleThresholdPolicy.hpp
! test/compiler/6792161/Test6792161.java
Changeset: a04a201f0f5a
Author: twisti
Date: 2011-11-17 04:07 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a04a201f0f5a
7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not
Reviewed-by: kvn, never
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/doCall.cpp
Changeset: 59bc0d4d9ea3
Author: never
Date: 2011-11-18 10:29 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/59bc0d4d9ea3
7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable
Reviewed-by: kvn, iveresov, twisti
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.hpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
Changeset: 7793051af7d6
Author: twisti
Date: 2011-11-21 00:57 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/7793051af7d6
7110058: change default for ScavengeRootsInCode to 2
Reviewed-by: kvn, never
! src/share/vm/runtime/globals.hpp
Changeset: f03a3c8bd5e5
Author: roland
Date: 2011-09-14 09:22 +0200
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/f03a3c8bd5e5
7077312: Provide a CALL effect for instruct declaration in the ad file
Summary: abstracted way to declare that the MachNode has the effect of a call (kills caller save registers, preserves callee save registers)
Reviewed-by: twisti, never
! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/adlparse.hpp
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/adlc/output_h.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/machnode.hpp
! src/share/vm/opto/node.hpp
Changeset: db2e64ca2d5a
Author: roland
Date: 2011-11-22 09:45 +0100
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/db2e64ca2d5a
7090968: Allow adlc register class to depend on runtime conditions
Summary: allow reg_class definition as a function.
Reviewed-by: kvn, never
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/formsopt.cpp
! src/share/vm/adlc/formsopt.hpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/opto/matcher.hpp
Changeset: cc81b9c09bbb
Author: kvn
Date: 2011-11-28 15:46 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/cc81b9c09bbb
7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE
Summary: Fixed several EA issues with Connection Graph construction.
Reviewed-by: never, twisti
! src/share/vm/ci/bcEscapeAnalyzer.cpp
! src/share/vm/ci/bcEscapeAnalyzer.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/escape.hpp
Changeset: 97825a4f7369
Author: iveresov
Date: 2011-11-30 17:35 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/97825a4f7369
7116795: Tiered: enable by default for server
Summary: Enable tiered compilation on server VM by default
Reviewed-by: kvn, never
! make/jprt.properties
! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp
Changeset: f745b2be3737
Author: kvn
Date: 2011-12-02 21:37 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/f745b2be3737
7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base)
Summary: Delay memory node transformation until the memory is processed.
Reviewed-by: iveresov, never
! src/share/vm/opto/memnode.cpp
Changeset: 81f7362f7bed
Author: kvn
Date: 2011-12-08 10:27 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/81f7362f7bed
Merge
! make/jprt.properties
! src/share/vm/runtime/globals.hpp
Changeset: 4406629aa157
Author: johnc
Date: 2011-12-02 12:39 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/4406629aa157
7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj
Summary: As a result of the changes for 4965777, the G1 reference field scanning closure could be applied to the discovered field of a reference object twice. The failing assert is too strong if the result of the first application of the closure is stolen, and the referenced object, evacuated by another worker thread.
Reviewed-by: ysr, tonyp
! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp
Changeset: e37aedaedccd
Author: tonyp
Date: 2011-12-05 12:26 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/e37aedaedccd
Merge
Changeset: f1391adc6681
Author: stefank
Date: 2011-11-28 10:19 +0100
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/f1391adc6681
7112034: Parallel CMS fails to properly mark reference objects
Summary: Enabled reference processing when work stealing during concurrent marking
Reviewed-by: jmasa, brutisso
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
Changeset: f4414323345f
Author: stefank
Date: 2011-11-28 14:58 +0100
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/f4414323345f
7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM
Summary: Changed the conditional to see if the precompiled header has been specified. Also, removed the unused PrecompiledOption.
Reviewed-by: dholmes, brutisso
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/top.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/top.make
! make/solaris/makefiles/gcc.make
Changeset: d23d2b18183e
Author: tonyp
Date: 2011-12-07 12:54 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d23d2b18183e
7118202: G1: eden size unnecessarily drops to a minimum
Summary: An integer underflow can cause the RSet lengths to be massively overpredicted which forces the eden size to the minimum.
Reviewed-by: brutisso, johnc
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
Changeset: e9b91fd07263
Author: jmasa
Date: 2011-12-09 06:46 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/e9b91fd07263
Merge
Changeset: 6d7d0790074d
Author: jmasa
Date: 2011-12-09 19:28 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/6d7d0790074d
7119584: UseParallelGC barrier task can be overwritten.
Summary: Provoke a GC for a metadata allocation failure.
Reviewed-by: johnc, iveresov
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp
Changeset: 3b688d6ff3d0
Author: fparain
Date: 2011-12-14 04:30 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/3b688d6ff3d0
7104647: Adding a diagnostic command framework
Reviewed-by: phh, dcubed
! src/share/vm/services/attachListener.cpp
+ src/share/vm/services/diagnosticArgument.cpp
+ src/share/vm/services/diagnosticArgument.hpp
+ src/share/vm/services/diagnosticCommand.cpp
+ src/share/vm/services/diagnosticCommand.hpp
+ src/share/vm/services/diagnosticFramework.cpp
+ src/share/vm/services/diagnosticFramework.hpp
! src/share/vm/services/jmm.h
! src/share/vm/services/management.cpp
Changeset: 31f6f10e4379
Author: vladidan
Date: 2011-12-14 20:06 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/31f6f10e4379
Merge
Changeset: a2fef924d8e6
Author: amurillo
Date: 2011-12-16 12:38 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a2fef924d8e6
Merge
! .hgtags
Changeset: 61165f53f165
Author: amurillo
Date: 2011-12-16 12:37 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/61165f53f165
Added tag hs23-b08 for changeset a2fef924d8e6
! .hgtags
From alejandro.murillo at oracle.com Tue Dec 20 17:26:30 2011
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 20 Dec 2011 18:26:30 -0700
Subject: jdk8-b18: HotSpot
Message-ID: <4EF135C6.6020004@oracle.com>
hs23-b08 has been integrated into jdk8-b18.
http://hg.openjdk.java.net/jdk8/jdk8/rev/7010bd24cdd0
http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/312cf15d1657
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/61165f53f165
http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/ebec6a7e8d4e
http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/54928c8850f5
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/334bd51fb3f3
http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ab1b1cc78577
Component : VM
Status : 0 major failures, 0 minor failures
Date : 12/20/2011 at 10:39
Tested By : VM SQE& leonid.mesnik at oracle.com
Cost(total man-days): 1
Workspace : /net/prt-archiver.us.oracle.com/data/jprt/archive/2011/12/2011-12-16-204738.jcoomes.hs23-b08-snapshot
Bundles : /net/prt-archiver.us.oracle.com/data/jprt/archive/2011/12/2011-12-16-204738.jcoomes.hs23-b08-snapshot
Platforms :
Others
Tests : /net/sqenfs-1.sfbay/export1/comp/vm/testbase/
Browsers : NA
Patches : NA
Logs : http://sqeweb.us.oracle.com/nfs/results/vm/gtee/HSX/PIT/VM/hs23/b08/8/b18/2011-12-17/
Number of Tests Executed : 333032 product tests, 0 unit tests, 0 tck tests
Bug verification status:
======================================
Tested, Pass:
7104647: Adding a diagnostic command framework
7105605: Use EA info to optimize pointers compare
7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not
7110017: is_headless_jre should be updated to reflect the new location of awt toolkit libraries
7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable
7110586: C2 generates incorrect results
7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks
7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE
7116189: Export JVM_SetNativeThreadName from Hotspot
7116481: Commercial features in Hotspot must be gated by a switch
7116730: Revert 7116481: Commercial features in Hotspot must be gated by a switch
7116795: Tiered: enable by default for server
7117282: Tiered: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base)->higher_equal(TypePtr:
7117389: Add a framework for vendor-specific command line switch extensions to Hotspot
7117748: SA_APPLE_BOOT_JAVA and ALWAYS_PASS_TEST_GAMMA settings should not be required on MacOS X
7118648: disable compressed oops by default on MacOS X until 7118647 is fixed
Tested, Pass (partial fixes):
Tested, Fail:
Untested bug fixes:
Setup is not available:
6593758: RFE: Enhance GC ergonomics to dynamically choose ParallelGCThreads
6890673: Eliminate allocations immediately after EA
7003454: order constants in constant table by number of references in code
7077312: Provide a CALL effect for instruct declaration in the ad file
7090968: Allow adlc register class to depend on runtime conditions
7110058: change default for ScavengeRootsInCode to 2
7110173: GCNotifier::pushNotification publishes stale data.
7110718: -XX:MarkSweepAlwaysCompactCount=0 crashes the JVM
7112034: Parallel CMS fails to properly mark reference objects
7112743: G1: Reduce overhead of marking closure during evacuation pauses
7112997: Remove obsolete code ResetObjectsClosure and VerifyUpdateClosure
7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj
7114303: G1: assert(_g1->mark_in_progress()) failed: shouldn't be here otherwise
7118202: G1: eden size unnecessarily drops to the minimum
7119584: UseParallelGC barrier task can be overwritten.
Build change only:
7097002: G1: remove a lot of unused / redundant code from the G1CollectorPolicy class
7106024: CMS: Removed unused code for precleaning in remark phase
7111795: G1: Various cleanups identified during walk through of changes for 6484965
7112308: Fix Visual Studio build for precompiled header
7113503: Bump the hs23 build number to 07
7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM
7117536: new hotspot build - hs23-b08
New bugs filed:
Bugs in PIT build:
Bugs in earlier promoted build:
Number of PIT requested: 1
Integration target J2SE build number: 1.8.0-b18
Issues and Notes:
This PIT for HS23 b08 into JDK8 b18.
-------------------------------
From VM SQE& leonid.mesnik at oracle.com
--
Alejandro E Murillo, Java Performance
Phone: (303) 955-2584.
Timezone: US/Mountain (UTC-0700)
From pranav.bhat at oracle.com Thu Dec 22 10:49:24 2011
From: pranav.bhat at oracle.com (pranav bhat)
Date: Thu, 22 Dec 2011 13:49:24 -0500
Subject: Is there any way to test run jcheck if you don't have commit rights?
Message-ID: <4EF37BB4.7060002@oracle.com>
Hello,
Not sure if this is the right ML to ask this question but I thought I'd
give it a try:
Is there anyways to kind of "test run" jcheck to see if your changeset
will be accepted for format / file permissions (eg: Reviewed-by:,
Contributed-by: tags, files should not have executable bit set etc) if
it were to be actually pushed especially when you don't have any
commit/push rights on any forest?
I haven't been here long enough and hence this might be a very trivial
question. I apologize in advance. :-)
Thanks,
- Pranav
From niklas.schlimm at provinzial.com Thu Dec 22 12:03:46 2011
From: niklas.schlimm at provinzial.com (niklas.schlimm at provinzial.com)
Date: Thu, 22 Dec 2011 21:03:46 +0100
Subject: =?windows-1252?Q?AUTO=3A_Schlimm=2C_Niklas_is_out_of_the_office=2E_=28?=
=?windows-1252?Q?R=FCckkehr_am_28=2E12=2E2011=29?=
Message-ID: <OF52C98A0C.32A53BFD-ONC125796E.006E357F-C125796E.006E357F@provinzial.com>
Ich bin bis 28.12.2011 abwesend.
Ich werde Ihre Nachricht nach meiner R?ckkehr beantworten.
Themen rund um Releaseverfahren und Tabex/4 betreuen Oliver Krebs (stellv.
Gruppenleiter) und Andreas Stenger.
Continuous Integration und Testautomatisierung betreut Dirk Pohle.
Java und Framework-Themen werden von Frau Danijela Steinacker betreut.
Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "jdk8-dev
Digest, Vol 8, Issue 36" gesendet am 22.12.2011 21:00:01.
Diese ist die einzige Benachrichtigung, die Sie empfangen werden, w?hrend
diese Person abwesend ist.
Provinzial Rheinland Versicherung AG ? Die Versicherung der Sparkassen ; Amtsgericht D?sseldorf HRB 41241;
Provinzial Rheinland Lebensversicherung AG ? Die Versicherung der Sparkassen; Amtsgericht D?sseldorf HRB 41741;
Sitz der Gesellschaften: Provinzialplatz 1, D-40591 D?sseldorf;
Vorsitzender der Aufsichtsr?te: Michael Breuer
Vorst?nde: Ulrich Jansen, Vorsitzender; Patric Fedlmeier, Sabine Krummenerl, Guido Schaefers, Peter Slawik
Die Berufsunf?higkeitsversicherung der Provinzial erh?lt im wichtigsten
Teilbereich "BU-Bedingungen" mit f?nf Sternen Spitzenbewertung der
Ratingagentur Morgen und Morgen!
www.provinzial.com
Denken Sie an die Umwelt, bevor Sie diese E-Mail ausdrucken!
From amitag at ca.ibm.com Thu Dec 22 13:01:45 2011
From: amitag at ca.ibm.com (Amit Aggarwal)
Date: Thu, 22 Dec 2011 16:01:45 -0500
Subject: AUTO: Amit Aggarwal is out of the office. (returning 01/16/2012)
Message-ID: <OFB1CFBEFC.155A8E99-ON8525796E.0073849D-8525796E.0073849D@ca.ibm.com>
I am out of the office until 01/16/2012.
I will respond to your message when I return.
For GPE, please contact Jill Sawatzky or Jason Mah
For any other issues, please contact my manager Warren Leslie.
Note: This is an automated response to your message "jdk8-dev Digest, Vol
8, Issue 36" sent on 12/22/11 15:00:01.
This is the only notification you will receive while this person is away.
From kelly.ohair at oracle.com Thu Dec 22 13:58:15 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 22 Dec 2011 13:58:15 -0800
Subject: Is there any way to test run jcheck if you don't have commit
rights?
In-Reply-To: <4EF37BB4.7060002@oracle.com>
References: <4EF37BB4.7060002@oracle.com>
Message-ID: <2169453E-C2F0-4DAD-A2AD-7FEA943D7411@oracle.com>
Try 'hg jcheck' more info with 'hg help jcheck'
-kto
On Dec 22, 2011, at 10:49 AM, pranav bhat wrote:
> Hello,
>
> Not sure if this is the right ML to ask this question but I thought I'd give it a try:
>
> Is there anyways to kind of "test run" jcheck to see if your changeset will be accepted for format / file permissions (eg: Reviewed-by:, Contributed-by: tags, files should not have executable bit set etc) if it were to be actually pushed especially when you don't have any commit/push rights on any forest?
>
> I haven't been here long enough and hence this might be a very trivial question. I apologize in advance. :-)
>
> Thanks,
> - Pranav
From omajid at redhat.com Thu Dec 22 14:36:53 2011
From: omajid at redhat.com (Omair Majid)
Date: Thu, 22 Dec 2011 17:36:53 -0500
Subject: Is there any way to test run jcheck if you don't have commit
rights?
In-Reply-To: <2169453E-C2F0-4DAD-A2AD-7FEA943D7411@oracle.com>
References: <4EF37BB4.7060002@oracle.com>
<2169453E-C2F0-4DAD-A2AD-7FEA943D7411@oracle.com>
Message-ID: <4EF3B105.70100@redhat.com>
On 12/22/2011 04:58 PM, Kelly O'Hair wrote:
>
> Try 'hg jcheck' more info with 'hg help jcheck'
>
$ hg jcheck
hg: unknown command 'jcheck'
Is that a custom mercurial extension? Where can I get it?
Thanks,
Omair
From mark.reinhold at oracle.com Thu Dec 22 15:09:29 2011
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 22 Dec 2011 15:09:29 -0800
Subject: Is there any way to test run jcheck if you don't have commit
rights?
In-Reply-To: omajid@redhat.com; Thu, 22 Dec 2011 17:36:53 EST;
<4EF3B105.70100@redhat.com>
Message-ID: <20111222230929.0E9571084@eggemoggin.niobe.net>
2011/12/22 14:36 -0800, omajid at redhat.com:
> $ hg jcheck
> hg: unknown command 'jcheck'
>
> Is that a custom mercurial extension? Where can I get it?
Yes, it's a custom extension. It's not available
outside Oracle, but we're working to fix that.
- Mark
From christine.lu at oracle.com Thu Dec 22 19:04:33 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 23 Dec 2011 03:04:33 +0000
Subject: hg: jdk8/jdk8: Added tag jdk8-b18 for changeset 7010bd24cdd0
Message-ID: <20111223030433.25BEA477A0@hg.openjdk.java.net>
Changeset: e1fc13802e0c
Author: cl
Date: 2011-12-22 19:00 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/e1fc13802e0c
Added tag jdk8-b18 for changeset 7010bd24cdd0
! .hgtags
From christine.lu at oracle.com Thu Dec 22 19:04:40 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 23 Dec 2011 03:04:40 +0000
Subject: hg: jdk8/jdk8/corba: Added tag jdk8-b18 for changeset 312cf15d1657
Message-ID: <20111223030440.CEA48477A1@hg.openjdk.java.net>
Changeset: 46bd4a46a5a8
Author: cl
Date: 2011-12-22 19:00 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/46bd4a46a5a8
Added tag jdk8-b18 for changeset 312cf15d1657
! .hgtags
From christine.lu at oracle.com Thu Dec 22 19:05:21 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 23 Dec 2011 03:05:21 +0000
Subject: hg: jdk8/jdk8/hotspot: Added tag jdk8-b18 for changeset 61165f53f165
Message-ID: <20111223030523.779DA477A2@hg.openjdk.java.net>
Changeset: 7e075537835d
Author: cl
Date: 2011-12-22 19:00 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/7e075537835d
Added tag jdk8-b18 for changeset 61165f53f165
! .hgtags
From christine.lu at oracle.com Thu Dec 22 19:06:34 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 23 Dec 2011 03:06:34 +0000
Subject: hg: jdk8/jdk8/jaxp: Added tag jdk8-b18 for changeset ebec6a7e8d4e
Message-ID: <20111223030634.B13A4477A3@hg.openjdk.java.net>
Changeset: 5fb25931f1c2
Author: cl
Date: 2011-12-22 19:00 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/5fb25931f1c2
Added tag jdk8-b18 for changeset ebec6a7e8d4e
! .hgtags
From christine.lu at oracle.com Thu Dec 22 19:06:41 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 23 Dec 2011 03:06:41 +0000
Subject: hg: jdk8/jdk8/jaxws: Added tag jdk8-b18 for changeset 54928c8850f5
Message-ID: <20111223030641.44BC5477A4@hg.openjdk.java.net>
Changeset: 72d410c3bab1
Author: cl
Date: 2011-12-22 19:00 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/72d410c3bab1
Added tag jdk8-b18 for changeset 54928c8850f5
! .hgtags
From christine.lu at oracle.com Thu Dec 22 19:06:50 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 23 Dec 2011 03:06:50 +0000
Subject: hg: jdk8/jdk8/jdk: Added tag jdk8-b18 for changeset 334bd51fb3f3
Message-ID: <20111223030659.D9051477A5@hg.openjdk.java.net>
Changeset: c6fab5332075
Author: cl
Date: 2011-12-22 19:00 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c6fab5332075
Added tag jdk8-b18 for changeset 334bd51fb3f3
! .hgtags
From christine.lu at oracle.com Thu Dec 22 19:08:17 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 23 Dec 2011 03:08:17 +0000
Subject: hg: jdk8/jdk8/langtools: Added tag jdk8-b18 for changeset ab1b1cc78577
Message-ID: <20111223030819.D3BC0477A6@hg.openjdk.java.net>
Changeset: 3c71fcc22b99
Author: cl
Date: 2011-12-22 19:00 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/3c71fcc22b99
Added tag jdk8-b18 for changeset ab1b1cc78577
! .hgtags
From lana.steuck at oracle.com Mon Dec 26 11:04:13 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 26 Dec 2011 19:04:13 +0000
Subject: hg: jdk8/jdk8/jaxws: 4 new changesets
Message-ID: <20111226190413.784CA477DA@hg.openjdk.java.net>
Changeset: 6d622b1b4db0
Author: ohair
Date: 2011-12-12 08:13 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/6d622b1b4db0
7117110: Remove target 1.5 from jaxp and jaxws repo builds for mac
Reviewed-by: alanb
! build.xml
Changeset: 6d2030eacdac
Author: ohair
Date: 2011-12-12 08:13 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/6d2030eacdac
7119829: Adjust default jprt testing configuration
Reviewed-by: alanb
! make/jprt.properties
Changeset: b2e4ab8b5fa3
Author: lana
Date: 2011-12-15 19:49 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/b2e4ab8b5fa3
Merge
Changeset: b73b733214aa
Author: lana
Date: 2011-12-23 16:36 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/b73b733214aa
Merge
From lana.steuck at oracle.com Mon Dec 26 11:04:13 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 26 Dec 2011 19:04:13 +0000
Subject: hg: jdk8/jdk8/jaxp: 4 new changesets
Message-ID: <20111226190413.7565C477D9@hg.openjdk.java.net>
Changeset: a482d45c93e9
Author: ohair
Date: 2011-12-12 08:12 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/a482d45c93e9
7117110: Remove target 1.5 from jaxp and jaxws repo builds for mac
Reviewed-by: alanb
! build.xml
Changeset: a49db7c01db7
Author: ohair
Date: 2011-12-12 08:12 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/a49db7c01db7
7119829: Adjust default jprt testing configuration
Reviewed-by: alanb
! make/jprt.properties
Changeset: f26e2ab2c2c7
Author: lana
Date: 2011-12-15 19:49 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/f26e2ab2c2c7
Merge
Changeset: dffeb62b1a7f
Author: lana
Date: 2011-12-23 16:36 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/dffeb62b1a7f
Merge
From lana.steuck at oracle.com Mon Dec 26 11:04:13 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 26 Dec 2011 19:04:13 +0000
Subject: hg: jdk8/jdk8: 3 new changesets
Message-ID: <20111226190413.72BE7477D8@hg.openjdk.java.net>
Changeset: 9acd7374ff8a
Author: ohair
Date: 2011-12-12 08:11 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/9acd7374ff8a
7119829: Adjust default jprt testing configuration
Reviewed-by: alanb
! make/jprt.properties
! test/Makefile
Changeset: 00d13c40d7a7
Author: lana
Date: 2011-12-15 19:49 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/00d13c40d7a7
Merge
Changeset: 237bc29afbfc
Author: lana
Date: 2011-12-23 16:36 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/237bc29afbfc
Merge
From lana.steuck at oracle.com Mon Dec 26 11:04:13 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 26 Dec 2011 19:04:13 +0000
Subject: hg: jdk8/jdk8/corba: 4 new changesets
Message-ID: <20111226190416.631E9477DB@hg.openjdk.java.net>
Changeset: 75529c21094f
Author: ohair
Date: 2011-12-12 08:15 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/75529c21094f
7119829: Adjust default jprt testing configuration
Reviewed-by: alanb
! make/jprt.properties
Changeset: 0289a94d653b
Author: lana
Date: 2011-12-15 19:49 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/0289a94d653b
Merge
Changeset: 052dda3b5ce3
Author: dmeetry
Date: 2011-12-18 22:12 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/052dda3b5ce3
7046238: new InitialContext(); hangs
Summary: Synchronization on a single monitor for contactInfo parameters with identical hashCode()
Reviewed-by: robm, skoppar
! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java
Changeset: e1366c5d84ef
Author: lana
Date: 2011-12-23 16:36 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/e1366c5d84ef
Merge
From lana.steuck at oracle.com Mon Dec 26 11:04:13 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 26 Dec 2011 19:04:13 +0000
Subject: hg: jdk8/jdk8/langtools: 11 new changesets
Message-ID: <20111226190439.DAE80477DC@hg.openjdk.java.net>
Changeset: 4822dfe0922b
Author: ohair
Date: 2011-12-12 08:15 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/4822dfe0922b
7119829: Adjust default jprt testing configuration
Reviewed-by: alanb
! make/jprt.properties
Changeset: 3809292620c9
Author: jjg
Date: 2011-12-13 11:21 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/3809292620c9
7120736: refactor javac option handling
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/api/JavacTool.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/file/Locations.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javac/util/Options.java
! test/tools/javac/diags/examples/UnsupportedEncoding.java
Changeset: 4e4fed1d02f9
Author: jjg
Date: 2011-12-13 14:33 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/4e4fed1d02f9
7121164: renamed files not committed
Reviewed-by: ksrini
- src/share/classes/com/sun/tools/javac/main/JavacOption.java
+ src/share/classes/com/sun/tools/javac/main/Option.java
+ src/share/classes/com/sun/tools/javac/main/OptionHelper.java
- src/share/classes/com/sun/tools/javac/main/OptionName.java
- src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java
Changeset: 4261dc8af622
Author: jjg
Date: 2011-12-14 16:16 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/4261dc8af622
7111022: javac no long prints last round of processing
7121323: Sqe tests using -Xstdout option fail with an invalid flag error message
Reviewed-by: darcy
! src/share/classes/com/sun/tools/javac/main/Option.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! test/tools/javac/4846262/Test.sh
+ test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java
! test/tools/javac/util/T6597678.java
Changeset: 281eeedf9755
Author: jjg
Date: 2011-12-14 17:52 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/281eeedf9755
7121681: compiler message file broken for javac -fullversion
Reviewed-by: jjh
! src/share/classes/com/sun/tools/javac/main/Option.java
Changeset: 42ffceeceeca
Author: jjg
Date: 2011-12-14 21:52 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/42ffceeceeca
7121682: remove obsolete import
Reviewed-by: jjh
! test/tools/javac/api/T6838467.java
Changeset: ab2a880cc23b
Author: lana
Date: 2011-12-15 19:53 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ab2a880cc23b
Merge
Changeset: 6b773fdeb633
Author: jjg
Date: 2011-12-16 13:49 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/6b773fdeb633
7121961: javadoc is missing a resource property
Reviewed-by: bpatel
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
Changeset: a7a2720c7897
Author: jjh
Date: 2011-12-16 16:41 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/a7a2720c7897
7122342: testPrintProcessorInfo/TestWithXstdout.java failed for JDK8 nightly build at 12/16/2011
Summary: Do not pass empty args to javac
Reviewed-by: jjg
! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java
Changeset: 1ae5988e201b
Author: mcimadamore
Date: 2011-12-19 12:07 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/1ae5988e201b
7120463: Fix method reference parser support in order to avoid ambiguities
Summary: Add lookahead routine to disambiguate between method reference in method context and binary expression
Reviewed-by: jjg, dlsmith
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/tools/javac/lambda/MethodReferenceParserTest.java
Changeset: 77b2c066084c
Author: lana
Date: 2011-12-23 16:39 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/77b2c066084c
Merge
- src/share/classes/com/sun/tools/javac/main/JavacOption.java
- src/share/classes/com/sun/tools/javac/main/OptionName.java
- src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java
From lana.steuck at oracle.com Mon Dec 26 11:04:25 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 26 Dec 2011 19:04:25 +0000
Subject: hg: jdk8/jdk8/jdk: 26 new changesets
Message-ID: <20111226190841.38920477DD@hg.openjdk.java.net>
Changeset: 7dbc53242c2a
Author: art
Date: 2011-12-07 17:45 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7dbc53242c2a
7117008: Warnings cleanup day: reduce number of javac warnings in the sun.awt package
Reviewed-by: anthony, denis, bagiras
! src/share/classes/sun/awt/AWTAutoShutdown.java
! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/awt/CausedFocusEvent.java
! src/share/classes/sun/awt/DebugSettings.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/share/classes/sun/awt/EventListenerAggregate.java
- src/share/classes/sun/awt/FocusingTextField.java
! src/share/classes/sun/awt/HeadlessToolkit.java
- src/share/classes/sun/awt/HorizBagLayout.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java
! src/share/classes/sun/awt/ModalityEvent.java
- src/share/classes/sun/awt/OrientableFlowLayout.java
! src/share/classes/sun/awt/PaintEventDispatcher.java
! src/share/classes/sun/awt/PeerEvent.java
! src/share/classes/sun/awt/SunDisplayChanger.java
! src/share/classes/sun/awt/SunGraphicsCallback.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/awt/UngrabEvent.java
- src/share/classes/sun/awt/VariableGridLayout.java
- src/share/classes/sun/awt/VerticalBagLayout.java
Changeset: 18925904efc2
Author: alexsch
Date: 2011-12-12 15:33 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/18925904efc2
7105890: closed/javax/swing/JScrollBar/4708809/bug4708809.java deadlocks on MacOS
Reviewed-by: alexp
+ test/javax/swing/JScrollBar/4708809/bug4708809.java
Changeset: 44b26d6a55a6
Author: alexsch
Date: 2011-12-13 15:32 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/44b26d6a55a6
7112931: closed/javax/swing/JTabbedPane/6416920/bug6416920.java fails on MacOS
Reviewed-by: alexp
+ test/javax/swing/JTabbedPane/6416920/bug6416920.java
Changeset: 70233f5e909c
Author: alexsch
Date: 2011-12-13 17:30 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/70233f5e909c
7120869: javax/swing/JScrollBar/4708809/bug4708809.java fails on Windows
Summary: The robot auto-delay is increased to fix the test failing on Windows.
Reviewed-by: alexp
! test/javax/swing/JScrollBar/4708809/bug4708809.java
Changeset: 032a91abc540
Author: alexsch
Date: 2011-12-13 18:38 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/032a91abc540
7116950: Reduce number of warnings in swing
Reviewed-by: art
! src/share/classes/com/sun/java/swing/Painter.java
! src/share/classes/java/beans/PropertyDescriptor.java
! src/share/classes/javax/swing/AbstractButton.java
! src/share/classes/javax/swing/ActionMap.java
! src/share/classes/javax/swing/ActionPropertyChangeListener.java
! src/share/classes/javax/swing/AncestorNotifier.java
! src/share/classes/javax/swing/ArrayTable.java
! src/share/classes/javax/swing/Box.java
! src/share/classes/javax/swing/BoxLayout.java
! src/share/classes/javax/swing/ButtonGroup.java
! src/share/classes/javax/swing/ComponentInputMap.java
! src/share/classes/javax/swing/InputMap.java
! src/share/classes/javax/swing/JButton.java
! src/share/classes/javax/swing/JComponent.java
! src/share/classes/javax/swing/JLabel.java
! src/share/classes/javax/swing/JLayeredPane.java
! src/share/classes/javax/swing/JMenu.java
! src/share/classes/javax/swing/JMenuBar.java
! src/share/classes/javax/swing/JMenuItem.java
! src/share/classes/javax/swing/JPopupMenu.java
! src/share/classes/javax/swing/JRootPane.java
! src/share/classes/javax/swing/JSeparator.java
! src/share/classes/javax/swing/JToolTip.java
! src/share/classes/javax/swing/JTree.java
! src/share/classes/javax/swing/JWindow.java
! src/share/classes/javax/swing/MenuSelectionManager.java
! src/share/classes/javax/swing/Popup.java
! src/share/classes/javax/swing/RepaintManager.java
! src/share/classes/javax/swing/Timer.java
! src/share/classes/javax/swing/border/AbstractBorder.java
! src/share/classes/javax/swing/border/CompoundBorder.java
! src/share/classes/javax/swing/border/EmptyBorder.java
! src/share/classes/javax/swing/border/MatteBorder.java
! src/share/classes/javax/swing/border/TitledBorder.java
! src/share/classes/javax/swing/event/AncestorEvent.java
! src/share/classes/javax/swing/event/ChangeEvent.java
! src/share/classes/javax/swing/event/EventListenerList.java
! src/share/classes/javax/swing/event/ListDataEvent.java
! src/share/classes/javax/swing/event/MenuDragMouseEvent.java
! src/share/classes/javax/swing/event/MenuEvent.java
! src/share/classes/javax/swing/event/MenuKeyEvent.java
! src/share/classes/javax/swing/event/PopupMenuEvent.java
! src/share/classes/javax/swing/plaf/ComponentUI.java
! src/share/classes/javax/swing/text/BadLocationException.java
! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java
Changeset: 282b2ce90afe
Author: lana
Date: 2011-12-16 12:12 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/282b2ce90afe
Merge
! src/share/classes/java/beans/PropertyDescriptor.java
- 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
- test/java/util/ResourceBundle/Control/ExpirationTest.java
- test/java/util/ResourceBundle/Control/ExpirationTest.sh
Changeset: 75bd7295c706
Author: bagiras
Date: 2011-12-19 15:21 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/75bd7295c706
7117334: Warnings cleanup day: reduce number of javac warnings in the java.awt package
Reviewed-by: art, denis, alexsch
! src/share/classes/java/awt/AWTEvent.java
! src/share/classes/java/awt/AWTEventMulticaster.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Font.java
! src/share/classes/java/awt/Toolkit.java
! src/share/classes/java/awt/image/ColorModel.java
Changeset: d15f38f08ce9
Author: denis
Date: 2011-12-19 16:44 +0400
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/d15f38f08ce9
7117011: Reduce number of warnings in sun/awt/windows and sun/awt/datatransfer
Reviewed-by: art
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java
! src/solaris/classes/sun/awt/X11/XClipboard.java
! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java
! src/windows/classes/sun/awt/windows/WBufferStrategy.java
! src/windows/classes/sun/awt/windows/WChoicePeer.java
! src/windows/classes/sun/awt/windows/WClipboard.java
! src/windows/classes/sun/awt/windows/WComponentPeer.java
! src/windows/classes/sun/awt/windows/WDataTransferer.java
! src/windows/classes/sun/awt/windows/WDesktopProperties.java
! src/windows/classes/sun/awt/windows/WDialogPeer.java
! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java
! src/windows/classes/sun/awt/windows/WFileDialogPeer.java
! src/windows/classes/sun/awt/windows/WFramePeer.java
! src/windows/classes/sun/awt/windows/WInputMethod.java
! src/windows/classes/sun/awt/windows/WMenuItemPeer.java
! src/windows/classes/sun/awt/windows/WPageDialog.java
! src/windows/classes/sun/awt/windows/WPageDialogPeer.java
! src/windows/classes/sun/awt/windows/WPrintDialog.java
! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java
! src/windows/classes/sun/awt/windows/WToolkit.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java
Changeset: cded2429cdbf
Author: anthony
Date: 2011-12-20 12:48 +0300
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cded2429cdbf
7122796: SunToolkit constructor should create the EventQueue for the Main AppContext
Summary: Always create an EQ for the main AppContext in SunToolkit constructor
Reviewed-by: art
! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/awt/SunToolkit.java
+ test/java/awt/EventQueue/MainAppContext/MainAppContext.java
Changeset: 94d7051cca13
Author: lana
Date: 2011-12-20 15:26 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/94d7051cca13
Merge
- src/share/classes/sun/awt/FocusingTextField.java
- src/share/classes/sun/awt/HorizBagLayout.java
- src/share/classes/sun/awt/OrientableFlowLayout.java
- src/share/classes/sun/awt/VariableGridLayout.java
- src/share/classes/sun/awt/VerticalBagLayout.java
Changeset: 4f0f9f9c4892
Author: smarks
Date: 2011-12-07 12:12 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/4f0f9f9c4892
7117249: fix warnings in java.util.jar, .logging, .prefs, .zip
Reviewed-by: alanb, dholmes, forax, sherman, smarks
Contributed-by: Prasannaa <prasannaa_ss at yahoo.com>, Martijn Verburg <martijnverburg at gmail.com>, Goerge_Albrecht <goerge.albrecht at gmx.net>, Graham Allan <grundlefleck at googlemail.com>, Michael Barker <mikeb01 at gmail.com>
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/jar/Manifest.java
! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/prefs/Preferences.java
! src/share/classes/java/util/prefs/XmlSupport.java
! src/share/classes/java/util/zip/ZipEntry.java
Changeset: f8897baf40ea
Author: omajid
Date: 2011-12-08 13:48 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f8897baf40ea
7117612: Miscellaneous warnings in java.lang
Reviewed-by: smarks, dholmes, alanb, darcy
! src/share/classes/java/lang/Boolean.java
! src/share/classes/java/lang/Byte.java
! src/share/classes/java/lang/Character.java
! src/share/classes/java/lang/CharacterName.java
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/ConditionalSpecialCasing.java
! src/share/classes/java/lang/Double.java
! src/share/classes/java/lang/EnumConstantNotPresentException.java
! src/share/classes/java/lang/Float.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/Short.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/ThreadLocal.java
! src/share/classes/java/lang/Void.java
! src/solaris/classes/java/lang/ProcessEnvironment.java
! src/windows/classes/java/lang/ProcessEnvironment.java
Changeset: 9bb7c3b97384
Author: smarks
Date: 2011-12-08 14:57 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9bb7c3b97384
7118546: fix warnings in javax.xml.crypto, javax.script
Reviewed-by: mullan
! src/share/classes/javax/script/ScriptException.java
! src/share/classes/javax/xml/crypto/NodeSetData.java
! src/share/classes/javax/xml/crypto/dom/DOMCryptoContext.java
! src/share/classes/javax/xml/crypto/dsig/Manifest.java
! src/share/classes/javax/xml/crypto/dsig/Reference.java
! src/share/classes/javax/xml/crypto/dsig/SignatureProperties.java
! src/share/classes/javax/xml/crypto/dsig/SignatureProperty.java
! src/share/classes/javax/xml/crypto/dsig/SignedInfo.java
! src/share/classes/javax/xml/crypto/dsig/TransformService.java
! src/share/classes/javax/xml/crypto/dsig/XMLObject.java
! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java
! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java
! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfo.java
! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java
! src/share/classes/javax/xml/crypto/dsig/keyinfo/PGPData.java
! src/share/classes/javax/xml/crypto/dsig/keyinfo/RetrievalMethod.java
! src/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java
! src/share/classes/javax/xml/crypto/dsig/spec/ExcC14NParameterSpec.java
! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.java
! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilterParameterSpec.java
! src/share/classes/javax/xml/crypto/dsig/spec/XPathType.java
Changeset: 77d41c0e4ffc
Author: jjh
Date: 2011-12-09 12:56 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/77d41c0e4ffc
7117053: Fix build warnings in com/sun/tools/jdi/*
Summary: Warnings fixed. Also reviewed by serguei.spitsyn at oracle.com, who is not yet an openjdk reviewer
Reviewed-by: ksrini
! make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java
! make/tools/src/build/tools/jdwpgen/OutNode.java
! src/share/classes/com/sun/jdi/AbsentInformationException.java
! src/share/classes/com/sun/jdi/ClassNotLoadedException.java
! src/share/classes/com/sun/jdi/ClassNotPreparedException.java
! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java
! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java
! src/share/classes/com/sun/jdi/InternalException.java
! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java
! src/share/classes/com/sun/jdi/InvalidLineNumberException.java
! src/share/classes/com/sun/jdi/InvalidStackFrameException.java
! src/share/classes/com/sun/jdi/InvalidTypeException.java
! src/share/classes/com/sun/jdi/InvocationException.java
! src/share/classes/com/sun/jdi/JDIPermission.java
! src/share/classes/com/sun/jdi/NativeMethodException.java
! src/share/classes/com/sun/jdi/ObjectCollectedException.java
! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java
! src/share/classes/com/sun/jdi/VMDisconnectedException.java
! src/share/classes/com/sun/jdi/VMMismatchException.java
! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java
! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java
! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java
! src/share/classes/com/sun/jdi/connect/VMStartException.java
! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java
! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java
! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java
! src/share/classes/com/sun/tools/jdi/ArrayReferenceImpl.java
! src/share/classes/com/sun/tools/jdi/ArrayTypeImpl.java
! src/share/classes/com/sun/tools/jdi/BooleanValueImpl.java
! src/share/classes/com/sun/tools/jdi/CharValueImpl.java
! src/share/classes/com/sun/tools/jdi/ClassLoaderReferenceImpl.java
! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java
! src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java
! src/share/classes/com/sun/tools/jdi/ConnectorImpl.java
! src/share/classes/com/sun/tools/jdi/DoubleValueImpl.java
! src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java
! src/share/classes/com/sun/tools/jdi/EventSetImpl.java
! src/share/classes/com/sun/tools/jdi/FloatValueImpl.java
! src/share/classes/com/sun/tools/jdi/GenericAttachingConnector.java
! src/share/classes/com/sun/tools/jdi/IntegerValueImpl.java
! src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java
! src/share/classes/com/sun/tools/jdi/InternalEventHandler.java
! src/share/classes/com/sun/tools/jdi/JDWPException.java
- src/share/classes/com/sun/tools/jdi/LinkedHashMap.java
! src/share/classes/com/sun/tools/jdi/LongValueImpl.java
! src/share/classes/com/sun/tools/jdi/MethodImpl.java
! src/share/classes/com/sun/tools/jdi/MirrorImpl.java
! src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java
! src/share/classes/com/sun/tools/jdi/ProcessAttachingConnector.java
! src/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java
! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java
! src/share/classes/com/sun/tools/jdi/ShortValueImpl.java
! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
! src/share/classes/com/sun/tools/jdi/TargetVM.java
! src/share/classes/com/sun/tools/jdi/ThreadAction.java
! src/share/classes/com/sun/tools/jdi/ThreadGroupReferenceImpl.java
! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java
! src/share/classes/com/sun/tools/jdi/VMAction.java
! src/share/classes/com/sun/tools/jdi/VMState.java
! src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java
Changeset: c508f38245f8
Author: ngmr
Date: 2011-12-12 11:41 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c508f38245f8
7118907: InetAddress.isReachable() should return false if sendto fails with EHOSTUNREACH
Reviewed-by: alanb, chegar
Contributed-by: Charles Lee <littlee at linux.vnet.ibm.com>
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
Changeset: 3216717f96f5
Author: dl
Date: 2011-12-12 10:45 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/3216717f96f5
7118066: Warnings in java.util.concurrent package
Reviewed-by: chegar, dholmes
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/Exchanger.java
! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/Phaser.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! test/java/util/Collections/EmptyIterator.java
Changeset: d4f9d7e86a92
Author: chegar
Date: 2011-12-12 03:54 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/d4f9d7e86a92
Merge
Changeset: 9c0a6185188f
Author: ohair
Date: 2011-12-12 08:17 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9c0a6185188f
7119829: Adjust default jprt testing configuration
Reviewed-by: alanb
! make/jprt.properties
! test/Makefile
Changeset: c647ebb3c4f7
Author: naoto
Date: 2011-12-13 15:41 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c647ebb3c4f7
4808233: "Locale" not thread-safe
Reviewed-by: okutsu
! src/share/classes/java/util/Locale.java
Changeset: e446c7d24d6c
Author: lana
Date: 2011-12-15 19:52 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/e446c7d24d6c
Merge
- make/sun/motif12/reorder-i586
- make/sun/motif12/reorder-sparc
- make/sun/motif12/reorder-sparcv9
- src/solaris/classes/sun/awt/motif/AWTLockAccess.java
- src/solaris/classes/sun/awt/motif/MFontPeer.java
- src/solaris/classes/sun/awt/motif/MToolkit.java
- src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java
- src/solaris/classes/sun/awt/motif/MWindowAttributes.java
- src/solaris/classes/sun/awt/motif/X11FontMetrics.java
- src/solaris/native/sun/awt/MouseInfo.c
- src/solaris/native/sun/awt/XDrawingArea.c
- src/solaris/native/sun/awt/XDrawingArea.h
- src/solaris/native/sun/awt/XDrawingAreaP.h
- src/solaris/native/sun/awt/awt_Cursor.h
- src/solaris/native/sun/awt/awt_KeyboardFocusManager.h
- src/solaris/native/sun/awt/awt_MToolkit.c
- src/solaris/native/sun/awt/awt_MToolkit.h
- src/solaris/native/sun/awt/awt_MenuItem.h
- src/solaris/native/sun/awt/awt_PopupMenu.h
- src/solaris/native/sun/awt/awt_TopLevel.h
- src/solaris/native/sun/awt/awt_Window.h
- src/solaris/native/sun/awt/awt_mgrsel.c
- src/solaris/native/sun/awt/awt_mgrsel.h
- src/solaris/native/sun/awt/awt_motif.h
- src/solaris/native/sun/awt/awt_wm.c
- src/solaris/native/sun/awt/awt_wm.h
- src/solaris/native/sun/awt/awt_xembed.h
- src/solaris/native/sun/awt/awt_xembed_server.c
- src/solaris/native/sun/awt/awt_xembed_server.h
Changeset: 33ac7a057b9c
Author: chegar
Date: 2011-12-16 16:09 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/33ac7a057b9c
7095980: Ensure HttpURLConnection (and supporting APIs) don't expose HttpOnly cookies
Reviewed-by: michaelm
! src/share/classes/java/net/HttpCookie.java
+ src/share/classes/sun/misc/JavaNetHttpCookieAccess.java
! src/share/classes/sun/misc/SharedSecrets.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/protocol/http/HttpOnly.java
Changeset: abbca81a98a7
Author: smarks
Date: 2011-12-17 08:21 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/abbca81a98a7
7122235: stop the build if javac fails
Reviewed-by: chegar, dholmes, mcimadamore, ohair
! make/common/Rules.gmk
Changeset: 528eb0d43e3a
Author: alanb
Date: 2011-12-17 20:07 +0000
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/528eb0d43e3a
7087549: (fs) Files.newInputStream throws UOE for custom provider options
Reviewed-by: alanb
Contributed-by: brandon.passanisi at oracle.com
! src/share/classes/java/nio/file/spi/FileSystemProvider.java
+ test/java/nio/file/Files/CustomOptions.java
Changeset: 5b27b978ed42
Author: sherman
Date: 2011-12-19 14:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/5b27b978ed42
6990617: Regular expression doesn't match if unicode character next to a digit.
Summary: updated RemoveQEQuotation() to deal with this case correctly
Reviewed-by: sherman
Contributed-by: stephen.flores at oracle.com
! src/share/classes/java/util/regex/Pattern.java
! test/java/util/regex/RegExTest.java
Changeset: 570f3d893596
Author: lana
Date: 2011-12-20 15:27 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/570f3d893596
Merge
- src/share/classes/com/sun/tools/jdi/LinkedHashMap.java
Changeset: 6f19ff39cff4
Author: lana
Date: 2011-12-23 16:38 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6f19ff39cff4
Merge
- src/share/classes/com/sun/tools/jdi/LinkedHashMap.java
- src/share/classes/sun/awt/FocusingTextField.java
- src/share/classes/sun/awt/HorizBagLayout.java
- src/share/classes/sun/awt/OrientableFlowLayout.java
- src/share/classes/sun/awt/VariableGridLayout.java
- src/share/classes/sun/awt/VerticalBagLayout.java
From lana.steuck at oracle.com Mon Dec 26 13:48:09 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 26 Dec 2011 13:48:09 -0800 (PST)
Subject: jdk8-b19: JSN, Tools, Core Libraries, Serviceability, 2d, Awt,
and Swing
Message-ID: <201112262148.pBQLm9DP012187@jano-app.us.oracle.com>
http://hg.openjdk.java.net/jdk8/jdk8/rev/237bc29afbfc
http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/77b2c066084c
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6f19ff39cff4
http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/b73b733214aa
http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/dffeb62b1a7f
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/7e075537835d
http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/e1366c5d84ef
---
All the fixes will be tested during promotion (no PIT testing at this point):
7117110 java build Remove target 1.5 from jaxp and jaxws repo builds for mac
7119829 java build Adjust default jprt testing configuration
7122235 java build Build succeeds even if JDK source file fails to compile
7093865 java classes_awt Win32TYMEDSelectionTest testcase not exiting correctly and c
7117008 java classes_awt Warnings cleanup day: reduce number of javac warnings in the
7117011 java classes_awt Reduce number of warnings in sun/awt/windows and sun/awt/dat
7117334 java classes_awt Warnings cleanup day: reduce number of javac warnings in the
7122796 java classes_awt SunToolkit constructor should create the EventQueue for the
7117612 java classes_lang Miscellaneous warnings in java.lang
7095980 java classes_net Ensure HttpURLConnection (and supporting APIs) don't expose
7118907 java classes_net InetAddress.isReachable() should return false if sendto fail
7087549 java classes_nio (fs) Files.newInputStream throws UOE for custom provider opt
7118546 java classes_security clean up warnings in javax.xml.crypto
7105890 java classes_swing closed/javax/swing/JScrollBar/4708809/bug4708809.java deadlo
7112931 java classes_swing closed/javax/swing/JTabbedPane/6416920/bug6416920.java fails
7116950 java classes_swing Reduce number of warnings in swing
7120869 java classes_swing javax/swing/JScrollBar/4708809/bug4708809.java fails on Wind
7117249 java classes_util clean up warnings in java.util.jar, .logging, .prefs
7118066 java classes_util_con Warnings in java.util.concurrent package
4808233 java classes_util_i18 "Locale" not thread-safe
6990617 java classes_util_reg Regular expression doesn't match if unicode character next t
7111022 java compiler javac no long prints last round of processing
7120463 java compiler Fix method reference parser support in order to avoid ambigu
7120736 java compiler refactor javac option handling
7121164 java compiler renamed files not committed
7121323 java compiler Sqe tests using -Xstdout option fail with an invalid flag er
7121681 java compiler compiler message file broken for javac -fullversion
7121682 java compiler remove obsolete import
7122342 java compiler testPrintProcessorInfo/TestWithXstdout.java failed for JDK8
7117053 java debugger Fix build warnings in com/sun/tools/jdi/*
7121961 java javadoctool javadoc is missing a resource property
7116862 java other Update JDK8 with Java DB 10.8.2.2
7046238 jets idl new InitialContext(); hangs
From john.coomes at oracle.com Tue Dec 27 20:49:23 2011
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 28 Dec 2011 04:49:23 +0000
Subject: hg: jdk8/jdk8/hotspot: 16 new changesets
Message-ID: <20111228044958.B45CF477EC@hg.openjdk.java.net>
Changeset: 434acc838772
Author: amurillo
Date: 2011-12-16 12:46 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/434acc838772
7122001: new hotspot build - hs23-b09
Reviewed-by: jcoomes
! make/hotspot_version
Changeset: 3c648b9ad052
Author: stefank
Date: 2011-12-14 12:15 +0100
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/3c648b9ad052
7121373: Clean up CollectedHeap::is_in
Summary: Fixed G1CollectedHeap::is_in, added tests, cleaned up comments and made Space::is_in pure virtual.
Reviewed-by: brutisso, tonyp, jcoomes
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/space.cpp
! src/share/vm/memory/space.hpp
! src/share/vm/oops/arrayOop.cpp
! src/share/vm/oops/arrayOop.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/utilities/quickSort.cpp
! src/share/vm/utilities/quickSort.hpp
Changeset: fd2b426c30db
Author: johnc
Date: 2011-12-14 17:43 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/fd2b426c30db
7119908: G1: Cache CSet start region for each worker for subsequent reuse
Summary: Cache workers' calculated starting heap region, used for parallel iteration over the collcection set, for subsequent reuse.
Reviewed-by: tonyp, brutisso
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
Changeset: 41406797186b
Author: tonyp
Date: 2011-12-16 02:14 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/41406797186b
7113012: G1: rename not-fully-young GCs as "mixed"
Summary: Renamed partially-young GCs as mixed and fully-young GCs as young. Change all external output that includes those terms (GC log and GC ergo log) as well as any comments, fields, methods, etc. The changeset also includes very minor code tidying up (added some curly brackets).
Reviewed-by: johnc, brutisso
! 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/g1ErgoVerbose.cpp
! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp
! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp
Changeset: adedfbbf0360
Author: johnc
Date: 2011-12-16 11:40 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/adedfbbf0360
7120038: G1: ParallelGCThreads==0 is broken
Summary: Running G1 with ParallelGCThreads==0 results in various crashes and asserts. Most of these are caused by unguarded references to the worker threads array or an incorrect number of active workers.
Reviewed-by: jmasa, tonyp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
Changeset: e7dead7e90af
Author: johnc
Date: 2011-12-19 10:02 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/e7dead7e90af
7117303: VM uses non-monotonic time source and complains that it is non-monotonic
Summary: Replaces calls to os::javaTimeMillis(), which does not (and cannot) guarantee monotonicity, in GC code to an equivalent expression that uses os::javaTimeNanos(). os::javaTimeNanos is guaranteed monotonically non-decreasing if the underlying platform provides a monotonic time source. Changes in OS files are to make use of the newly defined constants in globalDefinitions.hpp.
Reviewed-by: dholmes, ysr
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/utilities/globalDefinitions.hpp
Changeset: 129cd462ae89
Author: jmasa
Date: 2011-12-20 12:27 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/129cd462ae89
Merge
Changeset: 96ce4c27112f
Author: coleenp
Date: 2011-12-19 15:34 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/96ce4c27112f
7122939: TraceBytecodes broken with UseCompressedOops
Summary: Disable verify_heapbase on sparc if TraceBytecodes because the latter uses r12 as a temp register
Reviewed-by: coleenp, phh
Contributed-by: Volker Simonis <volker.simonis at gmail.com>
! src/cpu/x86/vm/assembler_x86.cpp
Changeset: 6c995c08526c
Author: phh
Date: 2011-12-19 15:50 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/6c995c08526c
7122880: Extend vendor-specific command interface to include manageable switches
Summary: Add Flag::external_ext()/writable_ext(), both return false.
Reviewed-by: coleenp, zgu
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/globals_ext.hpp
! src/share/vm/services/management.cpp
Changeset: 4502fd5c7698
Author: phh
Date: 2011-12-19 21:38 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/4502fd5c7698
Merge
Changeset: 11c26bfcf8c7
Author: phh
Date: 2011-12-21 15:48 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/11c26bfcf8c7
7091417: recvfrom's 6th input should be of type socklen_t
Summary: Revamp class os's socket method formal args to match socket.h, insert casts in appropriate places, and copyin-copyout int*'s that s/b socklen_t*'s in jvm.cpp.
Reviewed-by: coleenp, dholmes
Contributed-by: erik.gahlin at oracle.com, rickard.backman at oracle.com, nils.loodin at oracle.com, markus.gronlund at oracle.com
! src/os/bsd/vm/jvm_bsd.h
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/linux/vm/jvm_linux.h
! src/os/linux/vm/os_linux.inline.hpp
! src/os/solaris/vm/jvm_solaris.h
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/os_solaris.inline.hpp
! src/os/windows/vm/jvm_windows.h
! src/os/windows/vm/os_windows.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/utilities/ostream.cpp
Changeset: c01e115b095e
Author: coleenp
Date: 2011-12-21 16:41 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/c01e115b095e
7064927: retransformClasses() does not pass in LocalVariableTable of a method
Summary: Handle LVT attribute in the class file reconstitutor.
Reviewed-by: phh, coleenp
Contributed-by: thomaswue <thomas.wuerthinger at oracle.com>
! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.hpp
Changeset: d532160c55f7
Author: coleenp
Date: 2011-12-21 18:22 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d532160c55f7
Merge
Changeset: 4b18532913c7
Author: vladidan
Date: 2011-12-22 12:01 -0500
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/4b18532913c7
Merge
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
Changeset: 4bcf61041217
Author: amurillo
Date: 2011-12-23 15:24 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/4bcf61041217
Merge
Changeset: 9232e0ecbc2c
Author: amurillo
Date: 2011-12-23 15:24 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/9232e0ecbc2c
Added tag hs23-b09 for changeset 4bcf61041217
! .hgtags
From John.Coomes at oracle.com Tue Dec 27 21:03:41 2011
From: John.Coomes at oracle.com (John Coomes)
Date: Tue, 27 Dec 2011 21:03:41 -0800
Subject: jdk8-b19: HotSpot
Message-ID: <20218.41773.580128.703384@oracle.com>
hs23-b09 has been integrated into jdk8-b19.
http://hg.openjdk.java.net/jdk8/jdk8/rev/237bc29afbfc
http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/e1366c5d84ef
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/9232e0ecbc2c
http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/dffeb62b1a7f
http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/b73b733214aa
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6f19ff39cff4
http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/77b2c066084c
Component : VM
Status : 0 major failures, 0 minor failures
Date : 12/27/2011 at 09:49
Tested By : VM SQE & leonid.mesnik at oracle.com
Cost(total man-days): 1
Workspace : /net/prt-archiver.us.oracle.com/data/jprt/archive/2011/12/2011-12-23-233103.jcoomes.hs23-b09-snapshot
Bundles : /net/prt-archiver.us.oracle.com/data/jprt/archive/2011/12/2011-12-23-233103.jcoomes.hs23-b09-snapshot
Platforms :
Others
Tests : /net/sqenfs-1.sfbay/export1/comp/vm/testbase/
Browsers : NA
Patches : NA
Logs : http://sqeweb.us.oracle.com/nfs/results/vm/gtee/HSX/PIT/VM/hs23/b09/8/b19/2011-12-23/
Number of Tests Executed : 343556 product tests, 0 unit tests, 0 tck tests
Bug verification status:
======================================
Tested, Pass:
7122939: TraceBytecodes broken with UseCompressedOops
Tested, Pass (partial fixes):
Tested, Fail:
Untested bug fixes:
Setup is not available:
7064927: retransformClasses() does not pass in LocalVariableTable of a method
7113012: G1: rename not-fully-young GCs as "mixed"
7117303: VM uses non-monotonic time source and complains that it is non-monotonic
7119908: G1: Cache CSet start region for each worker for subsequent reuse
7120038: G1: ParallelGCThreads==0 is broken
7122880: Extend vendor-specific command interface to include manageable switches
Build change only:
7091417: recvfrom's 6th input should be of type socklen_t
7121373: Clean up CollectedHeap::is_in
7122001: new hotspot build - hs23-b09
New bugs filed:
Bugs in PIT build:
Bugs in earlier promoted build:
Number of PIT requested: 1
Integration target J2SE build number: 1.8.0-b19
Issues and Notes:
This is PIT of HS23 b09 for JDK8 b19.
-------------------------------
>From VM SQE & leonid.mesnik at oracle.com
From david.katleman at sun.com Wed Dec 28 15:52:58 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 28 Dec 2011 23:52:58 +0000
Subject: hg: jdk8/jdk8/jdk: 3 new changesets
Message-ID: <20111228235328.A52904781B@hg.openjdk.java.net>
Changeset: 60dd940eb58e
Author: yhuang
Date: 2011-12-12 18:21 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/60dd940eb58e
7003124: In Bulgarian Locale DateFormat is wrong
Reviewed-by: naoto, peytoia
! src/share/classes/sun/text/resources/FormatData_bg.java
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java
Changeset: cd03cd0e0965
Author: mfang
Date: 2011-12-15 11:29 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cd03cd0e0965
Merge
Changeset: 3778f8577305
Author: katleman
Date: 2011-12-28 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/3778f8577305
Merge
From david.katleman at sun.com Thu Dec 29 18:39:07 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 30 Dec 2011 02:39:07 +0000
Subject: hg: jdk8/jdk8: Added tag jdk8-b19 for changeset 237bc29afbfc
Message-ID: <20111230023907.A80F64782D@hg.openjdk.java.net>
Changeset: 5a5eaf6374bc
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/5a5eaf6374bc
Added tag jdk8-b19 for changeset 237bc29afbfc
! .hgtags
From david.katleman at sun.com Thu Dec 29 18:39:14 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 30 Dec 2011 02:39:14 +0000
Subject: hg: jdk8/jdk8/corba: Added tag jdk8-b19 for changeset e1366c5d84ef
Message-ID: <20111230023915.156844782E@hg.openjdk.java.net>
Changeset: 51d8b6cb18c0
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/51d8b6cb18c0
Added tag jdk8-b19 for changeset e1366c5d84ef
! .hgtags
From david.katleman at sun.com Thu Dec 29 18:40:02 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 30 Dec 2011 02:40:02 +0000
Subject: hg: jdk8/jdk8/hotspot: Added tag jdk8-b19 for changeset 9232e0ecbc2c
Message-ID: <20111230024004.3B90347830@hg.openjdk.java.net>
Changeset: fe2c87649981
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/fe2c87649981
Added tag jdk8-b19 for changeset 9232e0ecbc2c
! .hgtags
From david.katleman at sun.com Thu Dec 29 18:41:27 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 30 Dec 2011 02:41:27 +0000
Subject: hg: jdk8/jdk8/jaxp: Added tag jdk8-b19 for changeset dffeb62b1a7f
Message-ID: <20111230024127.C123A47831@hg.openjdk.java.net>
Changeset: f052abb8f374
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/f052abb8f374
Added tag jdk8-b19 for changeset dffeb62b1a7f
! .hgtags
From david.katleman at sun.com Thu Dec 29 18:41:34 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 30 Dec 2011 02:41:34 +0000
Subject: hg: jdk8/jdk8/jaxws: Added tag jdk8-b19 for changeset b73b733214aa
Message-ID: <20111230024134.3029147832@hg.openjdk.java.net>
Changeset: 2b2818e3386f
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/2b2818e3386f
Added tag jdk8-b19 for changeset b73b733214aa
! .hgtags
From david.katleman at sun.com Thu Dec 29 18:41:42 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 30 Dec 2011 02:41:42 +0000
Subject: hg: jdk8/jdk8/jdk: Added tag jdk8-b19 for changeset 3778f8577305
Message-ID: <20111230024152.7EE8C47833@hg.openjdk.java.net>
Changeset: 80350ee39fa8
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/80350ee39fa8
Added tag jdk8-b19 for changeset 3778f8577305
! .hgtags
From david.katleman at sun.com Thu Dec 29 18:42:58 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Fri, 30 Dec 2011 02:42:58 +0000
Subject: hg: jdk8/jdk8/langtools: Added tag jdk8-b19 for changeset 77b2c066084c
Message-ID: <20111230024300.DAEA147834@hg.openjdk.java.net>
Changeset: ffd294128a48
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ffd294128a48
Added tag jdk8-b19 for changeset 77b2c066084c
! .hgtags