On 2/06/2018 11:07 AM, Stuart Marks wrote:
On 6/1/18 5:15 PM, David Holmes wrote:
I would expect the CSR that marked them as deprecated for removal,
also serves for the actual removal. Certainly for VM flags we don't do
a separate CSR for each phase (deprecation, obsoletion, expiration).
Hm.
On 2/06/2018 10:43 AM, Stuart Marks wrote:
On 6/1/18 4:40 PM, David Holmes wrote:
Hi Stuart!
Nooo!
Just kidding!
Yaay
:-)
Actual removal looks fine but what about the corresponding JDI code:
./jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java
it still has a
On 6/1/18 5:15 PM, David Holmes wrote:
I would expect the CSR that marked them as deprecated for removal, also serves
for the actual removal. Certainly for VM flags we don't do a separate CSR for
each phase (deprecation, obsoletion, expiration).
Hm. Well, this hasn't been tested for Java SE
On 6/1/18 4:40 PM, David Holmes wrote:
Hi Stuart!
Nooo!
Just kidding!
Yaay
:-)
Actual removal looks fine but what about the corresponding JDI code:
./jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java
it still has a stop(Throwable) function (it doesn't have the no-arg
On 2/06/2018 9:53 AM, Stuart Marks wrote:
On 6/1/18 2:37 PM, Lance Andersen wrote:
The changes look fine. Is there a CSR or a release note that also
needs to be reviewed?
Thanks. No CSR yet. I usually do those after the code review. Good point
about a release note, though; I'll add the
On 6/1/18 2:37 PM, Lance Andersen wrote:
The changes look fine. Is there a CSR or a release note that also needs to be
reviewed?
Thanks. No CSR yet. I usually do those after the code review. Good point about a
release note, though; I'll add the label and subtask for one.
s'marks
Hi Stuart!
Nooo!
Just kidding!
Yaay
Actual removal looks fine but what about the corresponding JDI code:
./jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java
it still has a stop(Throwable) function (it doesn't have the no-arg
one!). What happens to it? The JDI functions
On 6/1/18 3:24 PM, Bernd Eckenfels wrote:
Hello,
I am not sure what the Policy for backward/Forward compatibility for
JMOD files is, but when I use JDK-9.0.4 jlink on 11ea JMODs I get a
IllegalArgumentException and „error reading“ by JDK-10.0.1 with no
further Details.
jlink only supports
Hello,
I am not sure what the Policy for backward/Forward compatibility for JMOD files
is, but when I use JDK-9.0.4 jlink on 11ea JMODs I get a
IllegalArgumentException and „error reading“ by JDK-10.0.1 with no further
Details.
If the JMOD files require newer jlink, should they have a Version
I am not sure I understand this implementation, but isn’t
>long s = convert(duration.getSeconds(), SECONDS);
needing to actually be
>long s = convert(duration.getSeconds(), NANOSECONDS);
so that s+n is in a common unit of measure?
Gregg
> On May 30, 2018, at 7:19 PM, Martin
Hi Stuart,
The changes look fine.Is there a CSR or a release note that also needs to
be reviewed?
Best
Lance
> On Jun 1, 2018, at 5:16 PM, Stuart Marks wrote:
>
> Hi all,
>
> Please review this changeset to remove the Thread.destroy() and
> Thread.stop(Throwable) methods. Both of these
Hi all,
Please review this changeset to remove the Thread.destroy() and
Thread.stop(Throwable) methods. Both of these methods have been deprecated for a
long time, and they were deprecated for removal in Java SE 9.
Thread.destroy() was never implemented, and has always thrown
On 6/1/18 8:52 AM, Bob Vandette wrote:
I filed a CSR for this a few days ago.
>
https://bugs.openjdk.java.net/browse/JDK-8204107
Typo: s/-XshowSetting/-XshowSettings
In the specification section, you can include the new lines adding
to java --extra-help output (that's the spec) and drop
> On May 31, 2018, at 11:36 PM, mandy chung wrote:
>
> Hi Bob,
>
> On 5/30/18 12:45 PM, Bob Vandette wrote:>
>> RFE: Container Metrics
>> https://bugs.openjdk.java.net/browse/JDK-8203357
>> WEBREV:
>> http://cr.openjdk.java.net/~bobv/8203357/webrev.00
Thanks for the review, here an updated
Hi , my change 8202322 just handled the fact that the visibility -
flags are not supported with xlc 12.1 , so setting them generated a TON
of compile - time warnings .
The introduction of the "-qvisibility=hidden"came with the mapfile
removal changes :
8200358:
Hi Ichiroh,
we do not use the XLC 13 compiler on AIX yet here at SAP and I believe nobody
of my colleagues has played with it yet. So you are on a new playground here
However, I believe the idea in OpenJDK with the abolition of map files is that
symbols should be invisible externally unless
Hi Thomas,
Sorry, I was on vacation. I will submit webrev with jtreg testcase.
Thanks,
Bhaktavatsal
-"Thomas Stüfe" wrote: -
To: Bhaktavatsal R Maram
From: "Thomas Stüfe"
Date: 05/23/2018 12:32AM
Cc: Ichiroh Takiguchi , Volker Simonis
, Java Core Libs
Subject: Re: RFR(XS):
On 31/05/2018 01:10, Kevin Rushforth wrote:
I would like to propose the following Draft JEP [1] for discussion.
JDK-8200758: Packaging Tool
This is intended as a JDK-scope replacement for the existing
javapackager tool that ships with Oracle JDK 10 (and earlier Oracle
JDK releases), and was
18 matches
Mail list logo
