Changeset: a47e28759666
Author:vromero
Date: 2013-06-27 09:51 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a47e28759666
7066788: javah again accepts -old option (ineffectively) which was removed in
1.5.
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javah/JavahT
Changeset: c30beaf3c42a
Author:jlaskey
Date: 2013-06-21 14:34 -0300
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c30beaf3c42a
8010732: BigDecimal, BigInteger and Long handling in nashorn
Reviewed-by: sundar
Contributed-by: james.las...@oracle.com
+ test/script/basic/JDK-8010
Changeset: 8e3d391c88c6
Author:vromero
Date: 2013-06-27 09:54 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8e3d391c88c6
8017609: javac, ClassFile.read(Path) should be ClassFile.read(Path,
Attribute.Factory)
Reviewed-by: jjg
! src/share/classes/com/sun/tools/classfil
On 27/06/2013 07:13, Alan Bateman wrote:
On 27/06/2013 05:37, Brad Wetmore wrote:
Brent/Alan/Mike,
Hashing.java was removed from the JDK workspace, but was not removed
from the old java/java/FILES_java.gmk. Things that still depend on the
old build (JCE/deploy) are currently broken.
http://cr.
Changeset: dcc6a52bf363
Author:erikj
Date: 2013-06-27 10:35 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dcc6a52bf363
8014513: Sjavac doesn't detect 32-bit jvm properly
Reviewed-by: jjg
! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java
Changeset: 370e7beff8a0
Author:wetmore
Date: 2013-06-27 10:19 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/370e7beff8a0
8019227: JDK-8010325 broke the old build
Reviewed-by: alanb, chegar
! make/java/java/FILES_java.gmk
Changeset: 4e69a7dfbeac
Author:chegar
Date:
Changeset: e42c27026290
Author:vromero
Date: 2013-06-27 16:04 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e42c27026290
8016099: Some @SuppressWarnings annotations ignored ( unchecked, rawtypes )
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/comp/Attr.java
Changeset: d137ce373c4c
Author:vromero
Date: 2013-06-27 16:06 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d137ce373c4c
7008643: inlined finally clauses confuse debuggers
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/T700864
Changeset: 26437287529d
Author:janvalenta
Date: 2013-06-27 17:47 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/26437287529d
8015720: since tag isn't copied while generating JavaFX documentation
Reviewed-by: jjg
!
src/share/classes/com/sun/tools/doclets/internal/toolk
Changeset: 1c31082f0a51
Author:darcy
Date: 2013-06-27 11:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c31082f0a51
8019304: Fix doclint issues in java.util.prefs
Reviewed-by: lancea
! src/share/classes/java/util/prefs/AbstractPreferences.java
! src/share/classes/java/ut
Changeset: 36e8bc1907a2
Author:bpatel
Date: 2013-06-26 20:45 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/36e8bc1907a2
8013738: Two javadoc tests have bug 000
Reviewed-by: jjg
! test/com/sun/javadoc/testNestedInlineTag/TestNestedInlineTag.java
! test/com/sun/java
Changeset: 27bd6a2302f6
Author:bpatel
Date: 2013-06-26 20:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/27bd6a2302f6
8014017: extra space in javadoc class heading
Reviewed-by: jjg
!
src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.jav
Changeset: 4fe5aab73bb2
Author:bpatel
Date: 2013-06-26 20:38 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4fe5aab73bb2
8007338: Method grouping tab line-folding
Reviewed-by: jjg
!
src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! te
Changeset: 065f8cb7bd89
Author:darcy
Date: 2013-06-27 11:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/065f8cb7bd89
8019308: Add descriptions of Java SE 7 and 8 language changes to SourceVersion
Reviewed-by: jjg
! src/share/classes/javax/lang/model/SourceVersion.ja
The old build has not produced usable bits for several months, it may
not have been failing but if you look closely (or run the tests) then
you'll see that there are several things missing. On build-dev then
you'll probably have seen a mail or two from me where I was trying to
encourage the buil
Changeset: b9ba04dc210f
Author:lancea
Date: 2013-06-27 15:07 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b9ba04dc210f
8017471: Fix JDBC -Xdoclint public errors
Reviewed-by: darcy
! src/share/classes/java/sql/Blob.java
! src/share/classes/java/sql/CallableStatement.java
!
Changeset: b8f16cb2d95b
Author:darcy
Date: 2013-06-27 12:24 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8f16cb2d95b
8019315: Fix doclint issues in java.util.logging
Reviewed-by: lancea
! src/share/classes/java/util/logging/Handler.java
! src/share/classes/java/util/loggi
Changeset: 97e798c06804
Author:ksrini
Date: 2013-06-27 12:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/97e798c06804
7080001: Need to bump version numbers in build.properties for 8
Reviewed-by: jjg
! make/build.properties
Changeset: 6729f7ef94cd
Author:smarks
Date: 2013-06-27 13:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6729f7ef94cd
8019224: add exception chaining to RMI CGIHandler
Reviewed-by: darcy
! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
Hello,
(sorry for answering to security-dev, I am not subscribed to the others)
the printStackTrace() seems wrong. This will ruin the HTTP Headers
produced by returnXXXError() (if it is not too late at that point anyway
as the execute() might also write data before).
I also think that if yo
Changeset: 1099fe14fb65
Author:darcy
Date: 2013-06-27 14:11 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1099fe14fb65
8019320: Fix doclint issues in javax.script
Reviewed-by: lancea
! src/share/classes/javax/script/Invocable.java
! src/share/classes/javax/script/ScriptCont
Changeset: e34e3ddb3cd8
Author:naoto
Date: 2013-06-27 14:40 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e34e3ddb3cd8
6609431: (rb) ResourceBundle.getString() returns incorrect value
Reviewed-by: okutsu, sherman
! src/share/classes/java/util/Properties.java
+ test/java/uti
Changeset: 5c548a8542b8
Author:emc
Date: 2013-06-27 17:45 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5c548a8542b8
8013357: javac accepts erroneous binary comparison operations
Summary: javac does not report type errors on illegal Object == primitive
comparisons
Rev
Going back to this...
On 6/18/2013 9:04 PM, Xuelei Fan wrote:
On 6/19/2013 10:50 AM, Brad Wetmore wrote:
Sorry for the delay.
Two comments about the property name.
I don't see the jdk.tls *System* Property prefix used anywhere else,
except as a *Security* properties:
jdk.tls.rejectClien
continued, I forgot this next part.
ServerHandshaker.java
=
283: My initial thought was a no_renegotiation(100) warning, but that
allows the client to decide what to do, rather than the server terminating.
No, we cannot. First of all, warning message is not very useful be
On 6/28/2013 6:44 AM, Brad Wetmore wrote:
> continued, I forgot this next part.
>
>>> ServerHandshaker.java
>>> =
>>> 283: My initial thought was a no_renegotiation(100) warning, but that
>>> allows the client to decide what to do, rather than the server
>>> terminating.
>>>
>
I agree that the property name is pretty confusing now. We need to
consolidate the property naming styles, at least in JSSE component. I
will go back to this topic later.
Xuelei
On 6/28/2013 6:36 AM, Brad Wetmore wrote:
> Going back to this...
>
> On 6/18/2013 9:04 PM, Xuelei Fan wrote:
>> On 6
Am 28.06.2013, 01:51 Uhr, schrieb Xuelei Fan :
"Please don't send a no_renegotiation warning alert. Warning message is
not very useful because in general the sending party cannot know how the
receiving party behave. The server side need to reject client initiated
renegotiation proactively."
Ju
Rearranging and tweaking a bit. What do you think of:
---
Reject client initiated renegotiation?
If server side should reject client-initiated renegotiation, send an
alert_handshake_failure fatal alert, not a no_renegotiation warning
alert (no_renegotiation must be a warning: RFC 2246). no_re
On 6/27/2013 4:59 PM, Xuelei Fan wrote:
I agree that the property name is pretty confusing now. We need to
consolidate the property naming styles, at least in JSSE component. I
will go back to this topic later.
I've filed:
JDK-8019346 Reconsider the namespace for JDK-7188658
to track f
On 6/28/2013 8:16 AM, Brad Wetmore wrote:
> Rearranging and tweaking a bit. What do you think of:
>
> ---
> Reject client initiated renegotiation?
>
> If server side should reject client-initiated renegotiation, send an
> alert_handshake_failure fatal alert, not a no_renegotiation warning
> alert
Thanks! But it may not apply to JDK-7188658. It is a naming style
applies to new names in the future.
Xuelei
On 6/28/2013 8:23 AM, Brad Wetmore wrote:
>
> On 6/27/2013 4:59 PM, Xuelei Fan wrote:
>> I agree that the property name is pretty confusing now. We need to
>> consolidate the property
On 6/28/2013 8:05 AM, Bernd Eckenfels wrote:
> Am 28.06.2013, 01:51 Uhr, schrieb Xuelei Fan :
>> "Please don't send a no_renegotiation warning alert. Warning message is
>> not very useful because in general the sending party cannot know how the
>> receiving party behave. The server side need to re
Hi Bernd,
A fair question. The Throwable.printStackTrace() call goes to the standard
error stream, which is *usually* not mixed with the HTTP response collected
from stdout and thus shouldn't spoil the protocol. But this really depends on
how it's invoked. My assumption is that stderr is usual
Changeset: 29136bc5
Author:darcy
Date: 2013-06-27 19:02 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29136bc5
8019357: Fix doclint warnings in java.lang.invoke
Reviewed-by: jrose
! src/share/classes/java/lang/invoke/LambdaConversionException.java
! src/share/classe
Changeset: 60d1994f63f7
Author:xuelei
Date: 2013-06-27 19:22 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60d1994f63f7
8019359: To comment why not use no_renegotiation to reject client initiated
renegotiation
Reviewed-by: wetmore
! src/share/classes/sun/security/ssl/Serve
Joe,
Could I please get a review of this changeset?
These changes convert the remaining ... and ...
tags to {@code ...} in java.security and its subpackages.
Webrev:
http://cr.openjdk.java.net/~juh/8019360/webrev.00/
I've also changed each package's package.html file to package-info.java.
I
Hi Jason,
On 06/27/2013 11:11 PM, Jason Uh wrote:
Joe,
Could I please get a review of this changeset?
These changes convert the remaining ... and ...
tags to {@code ...} in java.security and its subpackages.
Webrev:
http://cr.openjdk.java.net/~juh/8019360/webrev.00/
The {@code} related ch
38 matches
Mail list logo
