On Sun, 22 Nov 2020 16:00:45 GMT, Alan Bateman wrote:
>> This change terminally deprecates the following methods defined by
>> java.lang.ThreadGroup
>>
>> - stop
>> - destroy
>> - isDestroyed
>> - setDaemon
>> - isDaemon
>>
>> The stop method has been deprecated since=1.2 because it is
On Fri, 20 Nov 2020 19:59:52 GMT, Mandy Chung wrote:
>> Alan Bateman has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>> commits
On Fri, 11 Sep 2020 15:17:58 GMT, Bradford Wetmore wrote:
>> Ok, sorry for the distraction.
>
> Our local Santuario maintainer says:
>
> In general, changes to Apache Santuario should also be made at Apache so we
> stay in sync.
Hi @doom369, I hope we didn't end up wasting too much of your
For what it's worth, I've looked at the code and the CSR and I think where this
has ended up is fine.
Phil had previously raised some concerns about the change in behavior. I think
those are reasonable concerns; obviously I don't know about every place
Robot.delay() is used that could
I'd guess that security-dev would have reviewers for the change to
default.policy. Cc'd.
s'marks
On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
Hello.
Please review fix for jdk12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
clear this up and make the final call.
Mandy
On Jun 10, 2016, at 9:58 AM, Stuart Marks <stuart.ma...@oracle.com> wrote:
Hi, sorry I had missed this earlier.
It's surprising if forRemoval=true were to be added to this API when the rest
of the Applet API has forRemoval=false. Is it the intent
un 10, 2016, at 9:58 AM, Stuart Marks <stuart.ma...@oracle.com> wrote:
Hi, sorry I had missed this earlier.
It's surprising if forRemoval=true were to be added to this API when the rest
of the Applet API has forRemoval=false. Is it the intent, for example, to have
JSObject.getWi
brev.01
Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
Thank you!
Best regards,
Daniil
-Original Message-
From: Mandy Chung
Sent: Wednesday, June 08, 2016 3:09 PM
To: Daniil Titov
Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev;
build-infa-...@openjdk.java.net; awt-dev; Kevin R
Hi, the change looks fine to me.
I don't think there needs to be a CCC for this, but it does change a message
string, so the localization people need to be informed of this. (Unless there's
some way they get notified automatically when message files change; I'm not sure.)
s'marks
On 5/5/16
Thanks for doing this. Looks reasonable to me.
(It's also not clear to me that a regression test is worthwhile for testing
message output like this. In the RMI tests, we used to have tests that tested
the usage messages emitted by the launchers. The tests had race conditions that
led to
Doctor Deprecator approves.
Not only is this a win because it's a pure-deletion change, it's a double win
because it removes a side effect from a function that's supposed to "get" and
initialize Java properties values.
s'marks
On 9/17/15 9:12 AM, Martin Buchholz wrote:
Too late, I just
Michael,
Thanks for splitting up the patches and revising them in response to the review
comments.
I'm not yet entirely sure how to proceed with pushing these changes. I think
Chris assumed that I would push these changes. Since these are in awt,
printing, and beans, the changes might need
12 matches
Mail list logo
