Changeset: 82e7682c17e2
Author:darcy
Date: 2013-06-24 23:40 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82e7682c17e2
8017550: Fix doclint issues in java.lang and subpackages
Reviewed-by: alanb, chegar
! src/share/classes/java/lang/Boolean.java
!
Primitive integer types have well-specified value ranges
byte [ -pow(2,7) , pow(2,7) )
short [ -pow(2,15) , pow(2,15) )
int [ -pow(2,31) , pow(2,31) )
long [ -pow(2,63) , pow(2,63) ) .
Primitive operations on these types wrap-around in case of overflow,
but there are methods which throws
On 06/25/2013 03:53 AM, Brian Burkhalter wrote:
http://cr.openjdk.java.net/~bpb/8017540/
Thanks! Looks good to me.
Rather minor silly nit:
cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
for (int i = oldSize; i = exponent; i++) {
...is probably more consistent as:
cacheLine =
On 06/17/2013 01:00 PM, Aleksey Shipilev wrote:
This is the respin of the RFE filed a month ago:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
The webrev is here:
http://cr.openjdk.java.net/~shade/8014233/webrev.02/
The changeset is here:
Hi Mandy,
I noticed the @CallerSensitive annotation and machinery behind it has
been back-ported to JDK7. That was when one of my apps using
sun.reflect.Reflection.getCallerClass(int) failed. The native method
taking int was deprecated, but it also changed the behavior. If I run
the
Known issue, Mandy has a fix in progress [1].
-Chris.
[1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html
On 06/25/2013 11:06 AM, Peter Levart wrote:
Hi Mandy,
I noticed the @CallerSensitive annotation and machinery behind it has
been back-ported to JDK7. That was when
On 25/06/2013 11:06, Peter Levart wrote:
:
It seems that with 7u25 the result is shifted for one calling
frame. Is that behavior change intentional to encourage people to get
off that wagon?
Right, there is an additional frame that means that getClassClass is out
by one. This change was
Hi Chris,
I see it now, thanks.
Regards, Peter
On 06/25/2013 12:14 PM, Chris Hegarty wrote:
Known issue, Mandy has a fix in progress [1].
-Chris.
[1]
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html
On 06/25/2013 11:06 AM, Peter Levart wrote:
Hi Mandy,
I noticed
Hi,
I know that @CallerSensitive annotation was introduced to bring some
order to JDK internal plumbings. It's scope was to support JDK internal
usage, so it's use is limited to classes loaded by bootstrap or
extension class-loaders. In JDK-internal code it is used mainly for
implementing
Changeset: 01fcca3d2b8c
Author:bpb
Date: 2013-06-20 12:15 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01fcca3d2b8c
4641897: Faster string conversion of large integers
Summary: Accelerate conversion to string by means of Schoenhage recursive base
conversion.
Reviewed-by:
Changeset: 4a4d910e1504
Author:alanb
Date: 2013-06-25 13:53 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a4d910e1504
8017570: jfr.jar should not be in compact3 (for now)
Reviewed-by: erikj
! makefiles/profile-includes.txt
Changeset: 89631a384ee6
Author:weijun
Date: 2013-06-25 21:51 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89631a384ee6
8016051: Possible ClassCastException in KdcComm
Reviewed-by: weijun
Contributed-by: Artem Smotrakov artem.smotra...@oracle.com
!
Hello,
Please review this simple patch which updates regression test
langtools/tools/javac/T6725036.java to offset the time returned by
JavaFileObject.getLastModified() with the local time to UTC delta.
Please note that this patch is intended to address the test failures,
and that I will be
Changeset: 831467c4c6a7
Author:vromero
Date: 2013-06-25 16:12 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/831467c4c6a7
8017104: javac should have a class for primitive types that inherits from Type
Reviewed-by: jjg
!
On 25/06/2013 00:53, Brian Burkhalter wrote:
Branching off from this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018244.html
I filed this issue (should be public tomorrow)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
for the getRadixConversionCache()
Changeset: aceae9ceebbe
Author:kizune
Date: 2013-06-25 20:08 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aceae9ceebbe
8006973: jtreg test fails:
test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java
Reviewed-by: ksrini
!
Max,
Can you explain how to use your test library to run a simple test such
as the one attached with a 3rd party jar on bootclasspath?
e.g.
Proc pc = Proc.create(Test)
.args(-Xbootclasspath/p:+pathtoXercesImpljar)
.start();
is that how 3rd party jar file can be put on the
This is fine to be a workaround for the test case for now. It probably will
need to be
undo-ed after the propose change for #8015666 get integrated.
http://cr.openjdk.java.net/~sherman/8015666/webrev/
The proposal for #8015666 is to keep the existing behavior of
ZipEntry.getTime()
to return a
I am sympathetic to this naming issue (actually indifferent is more accurate)
but it will have to wait until I return from vacation. I have tagged this
thread and will follow up when I am back in the office. Please be patient, it
will be addressed.
Mike
On Jun 20 2013, at 07:10 , Remi Forax
Looks good. Only a few minor nits.
A few places (BiOperator) where it says Constructs rather than Returns. If
it is important that it constructs a new instance for consistency you may wish
to say Returns a new ...
There are a few places of incorrect capitalization in @return and @param tags
Is this a capital-R review?
On 06/25/13 13:50, Xueming Shen wrote:
This is fine to be a workaround for the test case for now. It probably
will need to be
undo-ed after the propose change for #8015666 get integrated.
http://cr.openjdk.java.net/~sherman/8015666/webrev/
The proposal for
It is intended to be an opinion. I would assume you would like a reviewer from
the langtool team to push the change, given the changset is for the lang repo.
You may want to update the check() method as well to low the granularity
to 2-second before comparing the equality. The timestamp from
On 6/25/13 3:24 AM, Alan Bateman wrote:
On 25/06/2013 11:06, Peter Levart wrote:
:
It seems that with 7u25 the result is shifted for one calling
frame. Is that behavior change intentional to encourage people to
get off that wagon?
Right, there is an additional frame that means that
Changeset: ac61efd8c593
Author:shade
Date: 2013-06-25 20:06 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac61efd8c593
8014233: java.lang.Thread should have @Contended on TLR fields
Summary: add the @Contended over three TLR fields.
Reviewed-by: psandoz, chegar, dholmes, dl
On 06/25/2013 12:13 PM, Peter Levart wrote:
else { // resizing
// increase by factor of 1.5 (like ArrayList)
int newLength = oldLength + (oldLength 1);
We probably don't ever want to extend any row of this cache any more
than we need to. The
On 06/25/2013 08:29 PM, Brian Burkhalter wrote:
Hi Aleksey,
On Jun 25, 2013, at 1:40 AM, Aleksey Shipilev wrote:
Thanks! Looks good to me.
Cool!
Hold on now. Similar to what Peter suggests in the separate thread,
there is the data race between 3458 and 3466:
3455 private static
On 6/25/13 3:50 AM, Peter Levart wrote:
Hi,
I know that @CallerSensitive annotation was introduced to bring some
order to JDK internal plumbings. It's scope was to support JDK
internal usage, so it's use is limited to classes loaded by bootstrap
or extension class-loaders. In JDK-internal
What about such code ?
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger retVal = null;
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
int oldSize = cacheLine.length;
if (exponent = oldSize) {
cacheLine =
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The trouble I'm seeing is weak enough
hardware, which will never see the updated value of cacheLine, always
falling back. Hence, I'm keen to keep
The proposed change for 8015666 is supposed to stop this test failure. But as I
said
last time that it may take a while for it to get into the repo. I will start
the CCC process
shortly, if there is no objection.
-Sherman
On 06/25/2013 12:27 PM, Eric McCorkle wrote:
Does the fix for 8015666
On 06/25/2013 11:36 PM, Dmitry Nadezhin wrote:
What about such code ?
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger retVal = null;
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
int oldSize = cacheLine.length;
if
On 06/25/2013 08:45 PM, Xueming Shen wrote:
The proposed change for 8015666 is supposed to stop this test failure.
But as I said
last time that it may take a while for it to get into the repo. I will
start the CCC process
shortly, if there is no objection.
There is no problem here. If 8015666
Please do; this test has been failing for almost a month now.
On 06/25/13 15:45, Xueming Shen wrote:
The proposed change for 8015666 is supposed to stop this test failure.
But as I said
last time that it may take a while for it to get into the repo. I will
start the CCC process
shortly, if
On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
On 06/25/2013 11:38 PM, Peter Levart wrote:
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The trouble I'm seeing is weak enough
hardware,
On 06/26/2013 12:34 AM, Peter Levart wrote:
On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
On 06/25/2013 11:38 PM, Peter Levart wrote:
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The
On 06/25/2013 10:34 PM, Peter Levart wrote:
On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
On 06/25/2013 11:38 PM, Peter Levart wrote:
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The
On 06/26/2013 12:56 AM, Peter Levart wrote:
Sorry, you are storing back when resizing. And you are resizing for
every exponent that is bigger that previous requested (cached). This can
lead to many resizings.
Dmitry had suggested going back to square one with his approach. I'll
let him post
On Jun 25, 2013, at 1:56 PM, Peter Levart peter.lev...@gmail.com wrote:
Sorry, you are storing back when resizing. And you are resizing for every
exponent that is bigger that previous requested (cached). This can lead to
many resizings.
Hi everyone,
Apologies to butt in, and maybe this
Changeset: 3700bb58c9a2
Author:juh
Date: 2013-06-25 14:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3700bb58c9a2
8017326: Cleanup of the javadoc code tag in java.security.spec
Summary: Convert javadoc code and tt tags to {@code ...}
Reviewed-by: darcy
!
On 06/25/2013 09:09 PM, Alan Eliasen wrote:
On 06/25/2013 12:13 PM, Peter Levart wrote:
else { // resizing
// increase by factor of 1.5 (like ArrayList)
int newLength = oldLength + (oldLength 1);
We probably don't ever want to extend any row
That should be enough. Then you only need to waitFor it.
--Max
在 Jun 26, 2013，1:10 AM，huizhe wang huizhe.w...@oracle.com 写道：
Max,
Can you explain how to use your test library to run a simple test such as the
one attached with a 3rd party jar on bootclasspath?
e.g.
Proc pc =
On Jun 25, 2013, at 5:50 AM, Peter Levart wrote:
Hi,
I know that @CallerSensitive annotation was introduced to bring some order to
JDK internal plumbings. It's scope was to support JDK internal usage, so it's
use is limited to classes loaded by bootstrap or extension class-loaders. In
Hi Peter,
here is another use case, where someone might want to use this:
3 - in a static context, find out what the class is that you are in.
For example, if you want to create a logger, instead of doing this:
private static final Logger log = Logger.getLogger(SomeClass.class);
we could
This request for comment regards this issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6910473
BigInteger.bigLength() may return negative value for large numbers
but more importantly Dmitry's thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018345.html
What is the
Thanks! I'll give it a try. Do you plan to backport this to jdk7?
-Joe
On 6/25/2013 4:31 PM, Wang Weijun wrote:
That should be enough. Then you only need to waitFor it.
--Max
在 Jun 26, 2013，1:10 AM，huizhe wang huizhe.w...@oracle.com 写道：
Max,
Can you explain how to use your test library
On 6/26/13 9:32 AM, huizhe wang wrote:
Thanks! I'll give it a try. Do you plan to backport this to jdk7?
No, but you can smuggle it there inside your test.
--Max
-Joe
On 6/25/2013 4:31 PM, Wang Weijun wrote:
That should be enough. Then you only need to waitFor it.
--Max
在 Jun 26,
Oh, there is another test library with similar purpose at
https://jbs.oracle.com/bugs/browse/JDK-8007142
and it is already on all versions of java.
It can launch a Java process, wait for it to finish, and collect all the
output (stdout and stderr). Mine takes care of stdin and focus on
We have two versions after private discussion with Aleksey.
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
if (exponent cacheLine.length)
return cacheLine[exponent];
int oldSize =
Changeset: 510035b7
Author:yhuang
Date: 2013-06-25 21:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/510035b7
8013836: getFirstDayOfWeek reports wrong day for pt-BR locale
Reviewed-by: naoto
+ src/share/classes/sun/util/resources/pt/CalendarData_pt_BR.properties
49 matches
Mail list logo
