Hello,
Please review the patch below to address
JDK-8037174: Fix serial lint warnings in sun.applet
http://cr.openjdk.java.net/~darcy/8037174.0/
Thanks,
-Joe
--- old/src/share/classes/sun/applet/AppletEvent.java2014-03-11
23:15:49.0 -0700
+++
cc'ing awt-dev as this where the Applet code is maintained.
In any case, the suppressing of serial warnings looks okay to me,
assuming of course they don't leak into the serialized stream of a
supported type.
-Alan.
On 12/03/2014 06:18, Joe Darcy wrote:
Hello,
Please review the patch
On 11/03/2014 22:31, Mike Duigou wrote:
Hello all;
The test java/util/Arrays/Correct.java (yeah, great name...) has failed
intermittently in nightly testing. Unfortunately the currently committed
version does not provide much information on the failure condition. This
changeset is a
Thanks Martin
On 12.03.2014 2:45, Martin Buchholz wrote:
Well done!
Not checking for interrupt in the loop is clearly my bug.
dumpAllStacks looks like a very useful utility method (basically what
jstack does). It feels like we're reinventing the wheel here, but I'm
not sure.
jstack
Thank you David
On 12.03.2014 8:46, David Holmes wrote:
On 11/03/2014 10:24 PM, Ivan Gerasimov wrote:
Hello everybody!
The test java/lang/ProcessBuilder/CloseRace.java was reported to
intermittently fail.
The test timed out, which should mean that at least one of the child
threads was never
On 03/11/2014 06:07 PM, Mike Duigou wrote:
You are making stringCache volatile - performance penalty on ARM PPC.
It is understood that the volatile is not free. For this purpose it was
believed that the performance cost was a fair trade off to avoid the heap pollution.
Regardless of the
On 03/11/2014 06:10 PM, Brian Burkhalter wrote:
Sergey,
On Mar 11, 2014, at 1:18 AM, Sergey Kuksenko wrote:
Could you share your benchmarks?
Of course. Please see:
benchmark source:
http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java
benchmark results:
On 03/11/2014 06:10 PM, Brian Burkhalter wrote:
Sergey,
On Mar 11, 2014, at 1:18 AM, Sergey Kuksenko wrote:
Could you share your benchmarks?
Of course. Please see:
benchmark source:
http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java
public class Bench6375303 {
* static
Ivan,
Ignore my earlier email as I hadn't seen the follow ups.
You don't need the CountDownLatch - but it is harmless.
Otherwise looks good to me.
Thanks,
David
On 12/03/2014 6:36 PM, Ivan Gerasimov wrote:
Thanks Martin
On 12.03.2014 2:45, Martin Buchholz wrote:
Well done!
Not checking
On Mar 11, 2014, at 9:05 AM, Sergey Kuksenko sergey.kukse...@oracle.com wrote:
Brian, Mike.
Could you explain what is the problem with the old caching?
String is immutable, BigDecimal is immutable. So we have data race at that
place, but it is safe data race. What is the problem if we
Hi Florian,
Thanks for doing this.
Do you have any more context on what RPMs/jars are using what methods of
Unsafe? such information would be useful to correlated with that on maven
central.
I think i can guess some aspects e.g.:
monitorEnter | (Ljava/lang/Object;)V
This is a request for review of this bug:
https://bugs.openjdk.java.net/browse/JDK-8036818
The method DateTimeFormatter withResolverFields() is supposed to
accept null. This is to allow a coy of the formatter to be returned
reset to the original state of having no resolver fields. The docs
say:
This is a request for review of this bug:
https://bugs.openjdk.java.net/browse/JDK-8035099
The implementation for LocalTime with(MILLI_OF_DAY, n) and LocalTime
with(MICRO_OF_DAY, n) fails to match the specification.
LocalTime base = LocalTime.of(12, 30, 40, 987654321);
LocalTime result =
This is a request for review of this bug:
https://bugs.openjdk.java.net/browse/JDK-8036785
During development, ChronoLocalDate had a generic type parameter. It
was removed during the development of JSR-310. The Javadoc was not
updated to reflect the removal.
The necessary change is to text that
On 03/11/2014 05:46 PM, Vladimir Ivanov wrote:
So all you're achieving by annotating prepend() method is that any
exception stack trace, in case it is thrown inside the prepend() method,
will hide where it was thrown from. In case all LambdaForm frames
leading to the prepend() method were also
On 03/12/2014 12:44 PM, Peter Levart wrote:
On 03/11/2014 05:46 PM, Vladimir Ivanov wrote:
So all you're achieving by annotating prepend() method is that any
exception stack trace, in case it is thrown inside the prepend()
method,
will hide where it was thrown from. In case all LambdaForm
This is a request for review of this bug:
https://bugs.openjdk.java.net/browse/JDK-8033662
and the duplicate:
https://bugs.openjdk.java.net/browse/JDK-8033659
The javadoc of the method java.time.format.DateTimeFormatter::withZone says:
If no zone has been parsed, then this override zone will be
Hello, Joe.
The fix looks good.
assuming of course they don't leak into the serialized stream of a supported
type.
These classes are related to the AppletViewer, so they should not.
With best regards. Petr.
On 12.03.2014, at 11:29, Alan Bateman alan.bate...@oracle.com wrote:
cc'ing
Looks fine, (not a reviewer).
I can sponsor the fix when reviewed.
Thanks, Roger
On 3/12/2014 6:45 AM, Stephen Colebourne wrote:
This is a request for review of this bug:
https://bugs.openjdk.java.net/browse/JDK-8036818
The method DateTimeFormatter withResolverFields() is supposed to
accept
Mike,
In the constructor do you think you should skip the call to isEmpty and just
check the length of toArray? Seems like since the implementation of the given
collection is unknown it is probably best to perform as little interaction with
it as possible. Also it would be possible for
The change look ok to me too.
There is a change in behavior here, but I don't expect it to be
surprising ( no NPE where there once was ), so I think it should be fine
for 8u-dev also.
The TCK test changes however, may not be suitable for 8u. Though I'm not
sure how these tests feed from the
I am happy for the tests to be located in the test.java.time package
rather than the tck.java.time package when backported. However, the
original (broken) TCK tests will need to be removed in that scenario.
I also do not know exactly how the TCK tests feed into the actual TCK
at this point.
Hello,
Can I have a review for a tzdata2014a [1] integration to JDK9:
http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00
The following test sets were executed on the build with latest tzdata:
test/sun/util/calendar test/java/util/Calendar
test/sun/util/resources/TimeZone
Hello,
Can I have a review for a 'test/sun/util/calendar/zi/Zoneinfo.java' test
bug failure [1] related to the latest tzdata2014a integration [2].
The test failure message:
Asia/Istanbul : Asia/Istanbul
On 12/03/2014 17:18, Mark Sheppard wrote:
Hi
an updated webrev as per suggested changes
http://cr.openjdk.java.net/~msheppar/8036603/webrev.01/
This looks good. One other thing in this code (pre-dates your patch but
your patch makes it a bit more obvious) is that if NewByteArray fails
then
Hi
an updated webrev as per suggested changes
http://cr.openjdk.java.net/~msheppar/8036603/webrev.01/
regards
Mark
On 07/03/2014 22:21, Mark Sheppard wrote:
Thanks Alan and Mandy for the feedback
I make the amendments as you both suggest
regards
Mark
On 07/03/2014 21:34, Alan Bateman
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8035870/webrev/
which address the issues raised in
https://bugs.openjdk.java.net/browse/JDK-8035870
summary:
checks to return values from malloc added with appropriate
JNU_ThrowOutOfMemoryError added
Hi Alan,
so L61 should be
if ((bytes = (*env)-NewByteArray(env, i)) == NULL) {
FreeEnvironmentStringsA(blockA);
return NULL;
}
regards
Mark
On 12/03/2014 17:24, Alan Bateman wrote:
On 12/03/2014 17:18, Mark Sheppard wrote:
Hi
an updated webrev as per suggested changes
Hi,
Please find below a trivial fix for [1]:
8036916: Deprecation warnings in LogManager
[1] https://bugs.openjdk.java.net/browse/JDK-8036916
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.00/
best regards,
-- daniel
On 3/12/2014 11:27 AM, Daniel Fuchs wrote:
Hi,
Please find below a trivial fix for [1]:
8036916: Deprecation warnings in LogManager
[1] https://bugs.openjdk.java.net/browse/JDK-8036916
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.00/
Oops.. I didn't catch the typo in
On 3/12/14 7:34 PM, Mandy Chung wrote:
On 3/12/2014 11:27 AM, Daniel Fuchs wrote:
Hi,
Please find below a trivial fix for [1]:
8036916: Deprecation warnings in LogManager
[1] https://bugs.openjdk.java.net/browse/JDK-8036916
webrev:
On 3/12/2014 11:51 AM, Daniel Fuchs wrote:
Hi Mandy,
Oh - of course - we don't need the new method actually. I was not
thinking right:
http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.01/
Thumbs up.
Mandy
On 12/03/2014 17:47, Mark Sheppard wrote:
Hi Alan,
so L61 should be
if ((bytes = (*env)-NewByteArray(env, i)) == NULL) {
FreeEnvironmentStringsA(blockA);
return NULL;
}
That would be good - thanks!
-Alan
On 12/03/2014 17:39, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8035870/webrev/
This looks okay me. It looks like the errno=ENOMEM at line 638 can be
removed as part of this.
-Alan.
Hi Jason,'
Using isEmpty() was intended to save the array creation but you make a valid
point regarding correctness. I have amended the webrev. This handling suggests
that it would useful for implementation to cache the empty result for toArray()
and I have also added this to ArrayList's
On Feb 28, 2014, at 10:11 PM, John Rose john.r.r...@oracle.com wrote:
On Feb 28, 2014, at 1:38 AM, Paul Sandoz paul.san...@oracle.com wrote:
But chances are, the day after I take it off, I will need it.
tryMonitorEnter() does no harm and it is out of reach of most programmers.
I think
On Mar 5, 2014, at 3:04 PM, Doug Lea d...@cs.oswego.edu wrote:
A few comments on catching up with this discussion...
Same here, back from a holiday last week.
tryMonitorEnter() does no harm and it is out of reach of most
programmers.
Built-in monitors are heavily optimized for typical
I think that we've covered all the angles, and that we can remove it.
– John
On Mar 12, 2014, at 1:44 PM, Paul Sandoz paul.san...@oracle.com wrote:
Currently i cannot find any external uses of it.
P.S. FTR, I wish we could also remove the per-object monitor from its
privileged position, so not all objects are burdened by it, and other forms of
lock can be switched into the existing notation on a type-by-type basis. This
is obviously a long, long term wish. A starting point is a notion of
Hello,
Appreciate if someone cane review this change, so that I can push this
into the jdk9 repository,
refreshing the internal ASM sources from rev 1700 to 1721, of particular
interest is
Rev 1710, which fixes [1] known to cause verification errors in the VM.
Thereafter I will be
40 matches
Mail list logo
