Thank you Alan, this will clear up a lot of issues surrounding these API's.
I skimmed over the changes, paying particular attention to the
httpserver and sctp packages.
-Chris.
On 02/21/2013 06:46 PM, Alan Bateman wrote:
Joe Darcy recently added @jdk.Supported [1] to make it possible to
Changeset: 9078c34437ab
Author:msheppar
Date: 2013-02-21 20:01 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9078c34437ab
8006182: cleanup to use java.util.Base64 in java security component, providers,
and regression tests
Summary: Refactored code to use java.util.Base64
On 21/02/2013 22:02, Vladimir Danushevsky wrote:
:
Webrev:
http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/
http://cr.openjdk.java.net/%7Evladidan/8005545/webrev.00/
Separate change to the build script (e.g. in ARM Hard-Float ABI case):
setenv ARCHABIPROPNAME gnueabihf
Does anyone have anything strongly against this? This is a small change
just to add a performance counter, the code to increment it and read it
will live in other parts of the code and be a part of a larger separate
commit.
Alan Bateman gave the response that the name was inappropriate, but I
Changeset: 8e82e4f225e4
Author:mcimadamore
Date: 2013-02-22 13:31 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8e82e4f225e4
8008337: Write test to check for compiler error when static method in interface
is called via super()
Reviewed-by: mcimadamore
Contributed-by:
On 22/02/2013 13:10, Nils Loodin wrote:
Does anyone have anything strongly against this? This is a small
change just to add a performance counter, the code to increment it and
read it will live in other parts of the code and be a part of a larger
separate commit.
Alan Bateman gave the
H alli,
This is a review request for 8008716 to address a couple of typos in
CallableStatement:
$ hg diff CallableStatement.java
diff -r 7dcb74c3ffba src/share/classes/java/sql/CallableStatement.java
--- a/src/share/classes/java/sql/CallableStatement.java Tue Feb 12 09:25:43
2013 -0800
+++
Looks fine to me Lance.
-Chris.
On 02/22/2013 02:12 PM, Lance Andersen - Oracle wrote:
H alli,
This is a review request for 8008716 to address a couple of typos in
CallableStatement:
$ hg diff CallableStatement.java
diff -r 7dcb74c3ffba src/share/classes/java/sql/CallableStatement.java
The security related ones look ok to me.
--Sean
On 02/21/2013 01:46 PM, Alan Bateman wrote:
Joe Darcy recently added @jdk.Supported [1] to make it possible to
identify JDK-specific APIs.
I'd like to add this to a number of APIs in the com.sun namespace to
make it obvious these are supported.
On 22/02/2013 14:06, Martin Buchholz wrote:
I was under the impression that the general rule was that all of
com.sun.* fell under the jdk supported umbrella, and the level of
support was the distinction between sun.com.* and sun.* .
com.sun is a mixed bag. There are lots of
Changeset: 9f9dac5a9e74
Author:lancea
Date: 2013-02-22 09:29 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f9dac5a9e74
8008716: address typo in CallableStatement javadocs
Reviewed-by: chegar
! src/share/classes/java/sql/CallableStatement.java
Changeset: 8d8a35ac7d40
From this webrev
http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ you are
counting the number of throwables constructed. You might want to change the
name to reflect that. I don't think anyone would want to write a spec for how
many throwables are thrown given that a
Hello Dima,
Yes that would be helpful and appreciated. There is another patch to the same
files that I will be looking into, but the changes are disjoint so there should
not be a significant merge issue.
Thanks,
Brian
On Feb 21, 2013, at 7:27 PM, Dmitry Nadezhin wrote:
Do you want that I
Brian,
Class FloatingDecimal contains both conversion from String to
float/double and conversion from float/double to String.
My change is in conversion from String to float/double.
The methods if FloatingDecimal that implement this conversion are:
static FloatingDecimal readJavaFormatString(
Dima,
If the methods are definitely unused that would be correct. I suppose if a
clean build of the JDK does not complain then it is acceptable and correct.
Thanks,
Brian
On Feb 22, 2013, at 9:41 AM, Dmitry Nadezhin wrote:
So I think that the required change in FormattedFloatingDecimal is
Hi Brent,
I think the condition needs to check if it is on Unix environment, and
check not only C but also other locales that do not use UTF-8
encoding. Also, LC_ALL precedes LANG environment variable, so I'd
check LC_ALL first, and if it is not exported then check LANG variable.
Naoto
On
Changeset: 94e67bed460d
Author:mcimadamore
Date: 2013-02-22 18:19 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/94e67bed460d
8008708: Regression: separate compilation causes crash in wildcards inference
logic
Summary: Invalid use of WildcardType.bound in
Sweet. Just be aware that the floatValue() optimization requires
Float.parseFloat to be fixed to match IEEE 754 behavior, as you're
apparently doing with Double.parseDouble, to pass tests.
(The separate patch I sent in to fix that is probably invalidated by your
changes, but it shouldn't be too
On Feb 22, 2013, at 11:23 AM, Louis Wasserman wrote:
Sweet. Just be aware that the floatValue() optimization requires
Float.parseFloat to be fixed to match IEEE 754 behavior, as you're apparently
doing with Double.parseDouble, to pass tests.
Actually I missed that until yesterday but found
It's up to you guys, probably. The issue is that the reference
implementation being tested against is wrong, and which order you want to
fix things is up to you guys.
On Fri, Feb 22, 2013 at 11:48 AM, Brian Burkhalter
brian.burkhal...@oracle.com wrote:
On Feb 22, 2013, at 11:33 AM, Brian
On Feb 22, 2013, at 12:10 PM, Louis Wasserman wrote:
It's up to you guys, probably. The issue is that the reference
implementation being tested against is wrong,
Yes, I understand.
and which order you want to fix things is up to you guys.
Brian
Dima,
Great! Thanks. I will take a look later and re-post the review.
Brian
On Feb 22, 2013, at 12:29 PM, Dmitry Nadezhin wrote:
Brian,
I removed unused methods and fields from FormattedFloatingDecimal.
JDK build passes.
The result of hg diff is attached.
-Dima
On Fri, Feb 22,
looks good to me. Nice to see the JLS additions and good catch on the missing
@since.
On Feb 21 2013, at 17:46 , Joe Darcy wrote:
Hello,
Please review the simple fix below for
6556996: (ann spec) SuppressWarnings strings should be documented
Looks good to me.
Bob.
On Feb 22, 2013, at 4:33 PM, Vladimir Danushevsky wrote:
Thanks, webrev updated
http://cr.openjdk.java.net/~vladidan/8005545/webrev.01/
On Feb 22, 2013, at 5:57 AM, Alan Bateman wrote:
On 21/02/2013 22:02, Vladimir Danushevsky wrote:
:
Webrev:
Hi Joe,
On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy joe.da...@oracle.com wrote:
Should third-party vendor extensions that are supported for public use
by the third-party use jdk.Supported?
No; as I envision it, the jdk.Supported annotation is only meant to convey
supported-ness in the
Hi Alan, Xueming, build-ers,
I'd like you to do a code review.
I've finally figured out why fastdebug jdk occasionally gives InternalError
in the zip code.
Exception in thread main java.lang.InternalError
at java.util.zip.Inflater.init(Native Method)
at
Hi Martin,
On 2/22/2013 1:40 PM, Martin Buchholz wrote:
Hi Joe,
On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy joe.da...@oracle.com
mailto:joe.da...@oracle.com wrote:
Should third-party vendor extensions that are supported for
public use by the third-party use jdk.Supported?
Here is the bugid you will need.
8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so
On 02/22/2013 02:03 PM, Martin Buchholz wrote:
Hi Alan, Xueming, build-ers,
I'd like you to do a code review.
I've finally figured out why fastdebug jdk occasionally gives
On Fri, Feb 22, 2013 at 2:15 PM, Xueming Shen xueming.s...@oracle.comwrote:
**
Here is the bugid you will need.
8008759: Do not let internal JDK zlib symbols leak out of fastdebug
libzip.so
Thanks! webrev updated.
I understand (deeply!) the problem that @Supported is trying to solve.
Martin has raised a number of good questions about it already. Here are
some additional concerns I'd like to see addressed before we use it any
further in our source code. (I've been unable to find any earlier
discussion or
One more thought. @Supported has RUNTIME retention, and it will be
inevitable that some people will check the annotation at runtime. As a
practical matter, once the annotation is added, it will never be removed
(or removed only if the corresponding API is itself removed), (for fear of
breaking
On 2/21/13 7:33 PM, Kumar Srinivasan wrote:
A nit
- LC_ALL + LC_ALL + \n +
+ LC_ALL= + LC_ALL + \n +
Done, thanks.
If Mac is the only system affected by this, should we make the checks for
LC* and LANG specific to Macs since other platforms don't have this issue ?
I am concerned this
I agree, but at the same time CLASS retention is really the worst of both
worlds in my opinion. It doesn't have any (convenient) runtime benefit, but you
can be sure that someone will depend on it at runtime by parsing the class
files (this happens surprisingly often).
I'd really like to see
33 matches
Mail list logo
