Hi,
This story has a long tail. It started with:
https://bugs.openjdk.java.net/browse/JDK-7038914
Some stress tests triggered OOME in ReferenceHandler thread which would
die. The first attempt at fixing this was the following discussion:
https://www.mail-archive.com/core-libs-dev%40openj
Alan's suggestion of using the singular is a small improvement. I'm
committing
* A timer task is not reusable. Once a task has been scheduled
* for execution on a {@code Timer} or cancelled, subsequent attempts to
* schedule it for execution will throw {@code IllegalStateException}.
On Thu,
This looks fine to me.
-Chris.
On 18 Sep 2014, at 18:52, Martin Buchholz wrote:
> Hi Chris,
>
> I'd like you to do a code review.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TimerTask-clarification/
> https://bugs.openjdk.java.net/browse/JDK-8058550
Am 18.09.2014 um 20:54 schrieb Alan Bateman:
On 18/09/2014 18:52, Martin Buchholz wrote:
Hi Chris,
I'd like you to do a code review.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TimerTask-clarification/
https://bugs.openjdk.java.net/browse/JDK-8058550
This looks okay. If I were wording
On 18/09/2014 18:52, Martin Buchholz wrote:
Hi Chris,
I'd like you to do a code review.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TimerTask-clarification/
https://bugs.openjdk.java.net/browse/JDK-8058550
This looks okay. If I were wording this then I think I might word in the
singula
On Thu, Sep 18, 2014 at 10:57 AM, roger riggs
wrote:
> Much of the behavior is defined in Timer.
Agreed. This change is technically redundant - it's just a clarification.
@see's are often vestiges of an ancient time before the existence of @link.
On Thu, Sep 18, 2014 at 10:57 AM, roger riggs
wrote:
> Hi Martin,
>
> I'm not sure why the @see Timer is deleted. The added link is useful but
> not a substitute.
> Much of the behavior is defined in Timer.
>
> Roger
>
Hi Martin,
I'm not sure why the @see Timer is deleted. The added link is useful
but not a substitute.
Much of the behavior is defined in Timer.
Roger
On 9/18/2014 1:52 PM, Martin Buchholz wrote:
Hi Chris,
I'd like you to do a code review.
http://cr.openjdk.java.net/~martin/webrevs/openjdk
Hi Chris,
I'd like you to do a code review.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TimerTask-clarification/
https://bugs.openjdk.java.net/browse/JDK-8058550
On 09/17/2014 11:42 AM, Martin Buchholz wrote:
On Tue, Sep 16, 2014 at 9:03 AM, Xueming Shen mailto:xueming.s...@oracle.com>> wrote:
There is also some "regressions" reported later with the ZipFile path when
dealing with
some "wrong"/non-ZIP64-spec-compliant huge zip file, in which i
Ok then, the webrev updated:
http://cr.openjdk.java.net/~mkos/8038966/jdk.03/
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
btw. I had to tweak the path - using simply Paths.get("org") we get
JTwork/scratch/org
but needed path is
JTwork/classes/javax/xml/ws/xsanymixed/org
(classes in
jtreg should remove the work/scratch directory upon test completion but
it's best practice to attempt to clean up generated files. No harm there
I think. Also needed in cases where test might be run manually. I'd
suggest keeping the clean up code in the testcase.
regards,
Sean.
On 18/09/2014
Oops, I missed that, thanks. One question yet - does it make sense any
more to clean generated files now, when the location was changed? I
think clean up should be done automatically by jtreg now, shouldn't it?
If you agree, I would delete the method instead.
Thanks
Miran
On 18/09/14 11:49, S
Thanks for the review Staffan!
cheers
/Joel
On 2014-09-18, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
> On 18 sep 2014, at 11:00, Joel Borggrén-Franck wrote:
>
> > Hi,
> >
> > Can I get a review for this anti-patch for JDK-8054984 (which is a
> > backport of JDK-8044629
On 18/09/2014 10:12, Miroslav Kos wrote:
Thanks, Sean, good catch ...
I changed the destination for generated files:
http://cr.openjdk.java.net/~mkos/8038966/jdk.02/
Regarding usage ProcessBuilder instead of shell script - the problem
is, that to compile test classes, wsdl must be compiled fi
Looks good!
Thanks,
/Staffan
On 18 sep 2014, at 11:00, Joel Borggrén-Franck wrote:
> Hi,
>
> Can I get a review for this anti-patch for JDK-8054984 (which is a backport
> of JDK-8044629 "(reflect) Constructor.getAnnotatedReceiverType() returns
> wrong value” to 8u).
>
> The fix shouldn’t
Remi,
Good question!
I looked into the code and my understanding is that they don't have the
same problem as compiled LambdaForms.
Proxy doesn't have instance methods (only public/private static), so no
unique_concrete_method dependencies in Proxy context.
Similar situation with Method: Se
Thanks, Sean, good catch ...
I changed the destination for generated files:
http://cr.openjdk.java.net/~mkos/8038966/jdk.02/
Regarding usage ProcessBuilder instead of shell script - the problem is,
that to compile test classes, wsdl must be compiled first - shell script
is setup required befor
Hi,
Can I get a review for this anti-patch for JDK-8054984 (which is a backport
of JDK-8044629 "(reflect) Constructor.getAnnotatedReceiverType() returns wrong
value” to 8u).
The fix shouldn’t have been back ported, so this change reverts it in 8u only.
Webrev: http://cr.openjdk.java.net/~jfr
Sorry about that, let's blame my crappy webmail ;)
(Strange that the patch appears fine in the mail archives and the webrev?)
Robert
On Thursday, 18 September 2014, 3:18, Alan Bateman
wrote:
On 17/09/2014 21:48, Brian Burkhalter wrote:
> Hello bad characters,
>
> Issue:https://bugs.openjdk
20 matches
Mail list logo
