On 12/16/2010 7:50 PM, Weijun Wang wrote:
Unfortunately, as Kelly points out (and I've also verified this)
changing the line breaks will change the .class file contents (though
not the bytecodes). The original changeset does have a very nice
property of not changing the .class files at all.
Ma
Changeset: 1f0f0737f04e
Author:weijun
Date: 2010-12-17 11:03 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f0f0737f04e
6975866: api/org_ietf/jgss/GSSContext/index.html#wrapUnwrapIOTest started to
fail since jdk7 b102
Reviewed-by: valeriep
! src/share/classes/sun/security/
Unfortunately, as Kelly points out (and I've also verified this)
changing the line breaks will change the .class file contents (though
not the bytecodes). The original changeset does have a very nice
property of not changing the .class files at all.
Maybe you can compile the codes without line
On 12/16/2010 7:14 PM, Stuart Marks wrote:
Thanks for the comments, folks.
I've been puzzling over the issue of joining lines after diamond
conversion if they're short enough. It turns out to be a surprisingly
complex interaction of tools, code style, and process.[1]
Joe and I actually talke
Thanks for the comments, folks.
I've been puzzling over the issue of joining lines after diamond conversion if
they're short enough. It turns out to be a surprisingly complex interaction of
tools, code style, and process.[1]
Joe and I actually talked about this issue briefly the other day and
On 16 December 2010 16:39, Neil Richards wrote:
> On 13 December 2010 20:04, Neil Richards wrote:
>> On 13 December 2010 18:46, Alan Bateman wrote:
>>> I haven't looked at your patch in detail yet but I suspect there may be
>>> similar issues in other places (like j.u.Hashtable) once you are don
Changeset: aca101db2361
Author:ohair
Date: 2010-12-16 13:14 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/aca101db2361
7006853: Integrate JAX-WS 2.2.2 RI into JDK 7
Reviewed-by: ramap
! jaxws.properties
Changeset: 63190d0ca619
Author:ohair
Date: 2010-12-16 13:10 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/63190d0ca619
7007257: jaxp 1.4.5 jdk7 1st integration
Reviewed-by: joehw
! jaxp.properties
On 12/16/2010 9:49 AM, Alan Bateman wrote:
Kelly O'Hair wrote:
:
But changing the line numbers will change the class file contents. :^(
True, but once this exercise moves beyond diamond then the class files
will be different anyway.
And the classfiles usually differ when we change the libra
Kelly O'Hair wrote:
:
But changing the line numbers will change the class file contents. :^(
True, but once this exercise moves beyond diamond then the class files
will be different anyway.
-Alan
Looks OK to me.
Mike
On Dec 15 2010, at 16:24 , Stuart Marks wrote:
> Hi all,
>
> As Joe Darcy mentioned yesterday [1], I'm working on updating the JDK
> libraries to use the new JDK 7 Coin features. The first feature is the
> diamond operator [2]. This first round of changes includes java.la
On Dec 16, 2010, at 12:45 AM, Alan Bateman wrote:
Stuart Marks wrote:
Hi all,
As Joe Darcy mentioned yesterday [1], I'm working on updating the
JDK libraries to use the new JDK 7 Coin features. The first feature
is the diamond operator [2]. This first round of changes includes
java.lang
Neil Richards wrote:
:
I now notice that there isn't a bug in Java bug database exactly for
the problem in Hashtable - though it's obviously related to 6934356,
and to 4741471 (which removed writeObject() synchronization from the
unsynchronized collection classes).
(As in Vector, the problem in
On 12/15/2010 4:24 PM, Stuart Marks wrote:
Hi all,
As Joe Darcy mentioned yesterday [1], I'm working on updating the JDK
libraries to use the new JDK 7 Coin features. The first feature is the
diamond operator [2]. This first round of changes includes java.lang,
java.io, java.sql, java.util, t
On 13 December 2010 20:04, Neil Richards wrote:
> On 13 December 2010 18:46, Alan Bateman wrote:
>> I haven't looked at your patch in detail yet but I suspect there may be
>> similar issues in other places (like j.u.Hashtable) once you are done with
>> Vector.
>
> You are correct, there is a simi
On 16 December 2010 13:01, Alan Bateman wrote:
> I've looked at the patch and don't see anything obviously wrong. I think
> Mike might is looking at it too. It clearly comes with a performance cost of
> course.
I've tried to write the fix so that the cost is minimized.
> One small comment is tha
Changeset: e67a399dd4ad
Author:sundar
Date: 2010-12-16 20:52 +0530
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e67a399dd4ad
6980447: Rhino JavaScript engine code in jdk-7 has to updated with the latest
code from Rhino 1.7R3.
Summary: Updating Rhino javascript engine with versio
Coin is part of Java 7. There may be *more* Coin features ("Coin: the flip
side") coming in 8.
On Dec 16, 2010, at 2:15 PM, Ulf Zibis wrote:
> Hi all,
>
> in the recent issue of the German "Java Spektrum" I read, that the project
> coin features are
> scheduled for JDK-8 2012 (Plan B). (Ji
Hi all,
in the recent issue of the German "Java Spektrum" I read, that the project coin features are
scheduled for JDK-8 2012 (Plan B). (Jigsaw and Lambda too)
Now I'm wondering, as the coin features are already in the JDK-7 codebase.
Can someone clarify ?
-Ulf
Neil Richards wrote:
Hello.
I have a fix and testcase for problem 6934356 in the Java bug database
- "Vector.writeObject() synchronization risks serialization deadlock".
I've included the 'hg diff -g' output below.
I've looked at the patch and don't see anything obviously wrong. I think
Mike
Chris Hegarty wrote:
:
Thanks for your comments Alan. I reworked the changes to include them.
Updated webrev:
http://cr.openjdk.java.net/~chegar/7000511/webrev.01/webrev/
This looks better. A few comments:
In PrintStream it looks like the charset will now be checked twice, once
by using is
Brian Goetz wrote:
:
Are there reasons to avoid fixing these when we're touching the code?
I can't think of any reasons. It's mostly a question as to whether the
automated refactoring can do this or whether we should "fix up" such
cases manually. I only spotted a few when reviewing this patch s
>>http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.0/
> Looks good to me, and very easy to review.
>
> One question on this. There are a couple of places where the original
> statement was "too long" to fit on a single line so the RHS of the assignment
> was pushed into a second lin
Stuart Marks wrote:
Hi all,
As Joe Darcy mentioned yesterday [1], I'm working on updating the JDK
libraries to use the new JDK 7 Coin features. The first feature is the
diamond operator [2]. This first round of changes includes java.lang,
java.io, java.sql, java.util, their corresponding test
24 matches
Mail list logo
