Changeset: 2013982bee34
Author:jjg
Date: 2012-10-16 21:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2013982bee34
8000673: remove dead code from HtmlWriter and subtypes
Reviewed-by: bpatel
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.
Hi Christian,
Is this just a preliminary review request, as actual backport requests
have to go to the jdk7u-dev mailing list for approval.
And are these all just bug fixes, or are there any API/spec changes
involved?
David
On 17/10/2012 5:54 AM, Christian Thalinger wrote:
http://cr.openj
Not sure what relevance there is to hotspot :)
Not meaning to be difficult but why not just apply this change to the 7u
code and use the appropriate constructors? As I general rule (there are
exceptions eg java.util.concurrent) I don't think the libraries code is
written to be directly usable
Okay, you convinced me. :)
Here's another webrev [1], updated to make use of Objects.hashCode() in
the fix (as well as in the testcase).
Can I now interest a Reviewer in endorsing this fix ?
Thanks,
Neil
[1] http://cr.openjdk.java.net/~ngmr/8000955/webrev.03/
On Tue, 2012-10-16 at 09:13 -0700,
Changeset: 3a6b76a468bd
Author:khazra
Date: 2012-10-16 15:23 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a6b76a468bd
7198073: (prefs) user prefs not saved [macosx]
Summary: Using class member field to get node instead of argument
Reviewed-by: alanb
! src/macosx/classes/j
http://cr.openjdk.java.net/~twisti/8000999
8000999: backport of JSR 292 to 7u
Reviewed-by:
This is an umbrella bug for these changes (which are backported in one
changeset):
6983728: JSR 292 remove argument count limitations
7128512: Javadoc typo in java.lang.invoke.MethodHandle
7117167: Misc
Thank you, John. After this is in 8 I will send a 7 backport webrev.
-- Chris
On Oct 16, 2012, at 11:11 AM, John Rose wrote:
> Reviewed; good. This removes a significant source of friction (mismerges)
> for sharing changes between 7 and 8. — John
>
> On Oct 16, 2012, at 11:01 AM, Christian
Reviewed; good. This removes a significant source of friction (mismerges) for
sharing changes between 7 and 8. — John
On Oct 16, 2012, at 11:01 AM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/8000989
>
> 8000989: smaller code changes to make future JSR 292 backports easier
http://cr.openjdk.java.net/~twisti/8000989
8000989: smaller code changes to make future JSR 292 backports easier
Reviewed-by:
In 8 we added two new constructors to InternalError which we use in
292. Factor InternalError generation to a method to make future
backports to 7u easier.
src/share/cla
Changeset: 32452042b781
Author:naoto
Date: 2012-10-16 10:59 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32452042b781
8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't
work as expected with custom extensions
8000273: java.util.Locale.getDisplayVar
That is true, and I'm just working on bringing Mike's Solaris changes
forward now. I hadn't considered that it would result in a difference in
Mac too. I'll get this work completed and see where it stands first.
-Rob
On 16/10/12 17:35, Alan Bateman wrote:
On 16/10/2012 17:15, Rob McKenna
On 16/10/2012 17:15, Rob McKenna wrote:
It has been suggested to me (at least twice at this stage) that these
files should be merged since they're identical. This requires an
adjustment in perspective from "every platform should have its own
implementation" to "those platforms that differ from
On Oct 15 2012, at 20:53 , Neil Richards wrote:
> Hi Mike,
> Thanks for the swift appraisal.
>
> Good suggestion to expand the test to cover other Map implementations -
> I'd toyed with the idea, but hadn't spotted Collisions.java as a
> template to follow.
>
> I've posted an new webrev [2] wit
It has been suggested to me (at least twice at this stage) that these
files should be merged since they're identical. This requires an
adjustment in perspective from "every platform should have its own
implementation" to "those platforms that differ from the norm should
have their own implement
On 10/16/12 2:54 AM, Alan Bateman wrote:
On 16/10/2012 01:53, Kurchi Hazra wrote:
Hi Alan,
Please find an updated webrev with a test included:
http://cr.openjdk.java.net/~khazra/7198073/webrev.01/
CheckUserPrefsStorage.sh is the main entry point - it runs
CheckUserPrefFirst first (which
On 10/15/2012 09:34 PM, Jeroen Frijters wrote:
I wrote:
The point about a non-final class being cloneable is simply that a base class
can always implement Cloneable, so that interface is currently meaningless.
Obviously that should read "... a derived class can always implement
Cloneable..."
Am 16.10.2012 05:53, schrieb Neil Richards:
I've posted an new webrev [2] with the updated (and moved) testcase,
which also makes use of Objects.hashCode() .
I suspect, that it's productive to use the same algorithm in test and testée.
=-O
-Ulf
On 16/10/2012 01:53, Kurchi Hazra wrote:
Hi Alan,
Please find an updated webrev with a test included:
http://cr.openjdk.java.net/~khazra/7198073/webrev.01/
CheckUserPrefsStorage.sh is the main entry point - it runs
CheckUserPrefFirst first (which creates and attempts to store a
preferenc
18 matches
Mail list logo
