Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[Alan Bateman]

On 02/06/2018 06:36, David Holmes wrote:

On 2/06/2018 10:43 AM, Stuart Marks wrote:

:

It looks to me like this interface resides on the debugger side of 
JDWP. I don't know exactly where it's implemented in the target VM, 
but I imagine it goes through some VM-internal or JDWP implementation 
interface, not through the target VM's public 
java.lang.Thread.stop(thr) interface. Is that right? (I'm not that 
familiar with this area of the system.)


It's a rather complex setup but the backend that does the work is 
(usually?) JVM TI, which won't go back out through the Java API.
Right, there's a StopThread function in JVM TI and a corresponding Stop 
Command in the JDWP protocol. The JVM TI spec has a statement to say 
that it works "similar to Thread.stop" and the JDWP spec has "as if done 
by Thread.stop" so it would be good to update both of these.


-Alan

Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[Alan Bateman]

On 02/06/2018 06:45, David Holmes wrote:

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. Well, this hasn't been tested for Java SE APIs yet, as most of 
the deprecations-for-removal occurred in Java SE 9, before the CSR 
was active. Instead, those deprecations went through the (Oracle 
internal) CCC process.


Now that we're fully on the CSR system, I'd expect that deprecations 
(whether or not for removal) and removals of Java SE APIs would have 
separate CSR requests. The reason is that adding or changing a 
deprecation annotation is a spec change, and removing the API is a 
distinct spec change. They also occur in different releases.


Good points. Though given the annotation is on the method being 
removed it's really only one spec change.
Adding @Deprecated(forRemoval=true) in one release and then removing the 
element in a later release has to be tracked as two spec changes, and 
thus two CSRs. There may be more steps of course. In the case of 
Thread.stop(Throwable) under discussion here, and several 
SecurityManager methods, the methods were "degraded" (to always throw an 
exception or only check AllPermission in the case of the SM methods) 
before removal. So that's another intermediate spec change that has to 
be tracked via the CSR.


-Alan

Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[David Holmes]

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. Well, this hasn't been tested for Java SE APIs yet, as most of the 
deprecations-for-removal occurred in Java SE 9, before the CSR was 
active. Instead, those deprecations went through the (Oracle internal) 
CCC process.


Now that we're fully on the CSR system, I'd expect that deprecations 
(whether or not for removal) and removals of Java SE APIs would have 
separate CSR requests. The reason is that adding or changing a 
deprecation annotation is a spec change, and removing the API is a 
distinct spec change. They also occur in different releases.


Good points. Though given the annotation is on the method being removed 
it's really only one spec change.


Cheers,
David

I can easily see that a different procedure would be followed for VM 
flags, though, since they aren't part of Java SE.


s'marks

Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[David Holmes]

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 stop(Throwable) function (it doesn't have the no-arg 
one!). What happens to it? The JDI functions were never deprecated in 
line with the Thread functions (suspend/resume/stop).


The ThreadReference javadoc has:

    * @see java.lang.Thread#stop(Throwable)

so will need fixing.


Good catch! I had grepped around the source tree for stuff like this but 
I had missed this one.


It looks to me like this interface resides on the debugger side of JDWP. 
I don't know exactly where it's implemented in the target VM, but I 
imagine it goes through some VM-internal or JDWP implementation 
interface, not through the target VM's public java.lang.Thread.stop(thr) 
interface. Is that right? (I'm not that familiar with this area of the 
system.)


It's a rather complex setup but the backend that does the work is 
(usually?) JVM TI, which won't go back out through the Java API.




I'm presuming that it doesn't go through j.l.Thread.stop(Throwable) 
since that method has essentially been non-functional since JDK 8.


I see a couple tests for this in

     test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop

and I can see some evidence in our internal build/test systems that 
they're still being run, so it looks like these interfaces are still 
active. As you observe, they haven't been deprecated. There might even 
be valid uses cases for stopping a thread this way in a debugging 
situation that aren't valid for applications.


I'm yet to find one :) I pointed out this inconsistency many many years 
ago but it remains.


I guess that means the thing to do is to update the documentation to 
remove the reference to the soon-to-be-deleted Thread.stop(Throwable) 
but otherwise leave this stuff unchanged.


Yep that's what I thought too.

Thanks,
David


s'marks

Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[Stuart Marks]

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 APIs yet, as most of the 
deprecations-for-removal occurred in Java SE 9, before the CSR was active. 
Instead, those deprecations went through the (Oracle internal) CCC process.


Now that we're fully on the CSR system, I'd expect that deprecations (whether or 
not for removal) and removals of Java SE APIs would have separate CSR requests. 
The reason is that adding or changing a deprecation annotation is a spec change, 
and removing the API is a distinct spec change. They also occur in different 
releases.


I can easily see that a different procedure would be followed for VM flags, 
though, since they aren't part of Java SE.


s'marks

Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[Stuart Marks]

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 one!). What 
happens to it? The JDI functions were never deprecated in line with the Thread 
functions (suspend/resume/stop).


The ThreadReference javadoc has:

    * @see java.lang.Thread#stop(Throwable)

so will need fixing.


Good catch! I had grepped around the source tree for stuff like this but I had 
missed this one.


It looks to me like this interface resides on the debugger side of JDWP. I don't 
know exactly where it's implemented in the target VM, but I imagine it goes 
through some VM-internal or JDWP implementation interface, not through the 
target VM's public java.lang.Thread.stop(thr) interface. Is that right? (I'm not 
that familiar with this area of the system.)


I'm presuming that it doesn't go through j.l.Thread.stop(Throwable) since that 
method has essentially been non-functional since JDK 8.


I see a couple tests for this in

test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop

and I can see some evidence in our internal build/test systems that they're 
still being run, so it looks like these interfaces are still active. As you 
observe, they haven't been deprecated. There might even be valid uses cases for 
stopping a thread this way in a debugging situation that aren't valid for 
applications.


I guess that means the thing to do is to update the documentation to remove the 
reference to the soon-to-be-deleted Thread.stop(Throwable) but otherwise leave 
this stuff unchanged.


s'marks

Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[David Holmes]

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 label and subtask for one.


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).


David


s'marks

Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[Stuart Marks]

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

Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[David Holmes]

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 were never deprecated in 
line with the Thread functions (suspend/resume/stop).


The ThreadReference javadoc has:

   * @see java.lang.Thread#stop(Throwable)

so will need fixing.

Thanks,
David

On 2/06/2018 7:16 AM, Stuart Marks wrote:

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 
NoSuchMethodError back to the caller. Thread.stop(Throwable) was made 
non-functional in JDK 8, throwing UnsupportedOperationException back to 
the caller.


Note that the no-arg Thread.stop() method remains deprecated, not for 
removal, and is unaffected by this changeset.


Note also that ThreadGroup.destroy() doesn't actually destroy any 
threads -- just thread groups -- and that it is also unaffected by this 
changeset.


Bug:

 https://bugs.openjdk.java.net/browse/JDK-8204243

Webrev:

 http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.0/

Thanks,

s'marks
aka @DrDeprecator

Re: jlink / jmods version compatibiltiy

[mandy chung]

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 linking modules of the same runtime version
as jlink because jlink has a few plugins such as system-modules
and generate-jli-classes that are deeply tied with java.base.
It can be enhanced in the future in particular for plugins to
support version <= jlink version.

See JDK-8185130 that was integrated in JDK 10.  jlink linking with
older version of JMODS outputs a clear error message:

$ jdk11/bin/jlink  --module-path jdk10/jmods --output test-image 
--add-modules java.base

Error: jlink version 11.0 does not match target java.base version 10.0


If the JMOD files require newer jlink, should they have a Version
identifier to allow rejecting this. Or is it expected to normally
work?

:

Error reading module: jdk-11-oraopenjdk\jmods\java.base.jmod


JDK 10 jlink does not support class file version 55 when linking
with JDK 11 modules. I agree the error message should be improved.

I created https://bugs.openjdk.java.net/browse/JDK-8204256.

Mandy

jlink / jmods version compatibiltiy

[Bernd Eckenfels]

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 identifier to 
allow rejecting this. Or is it expected to normally work?

C:\ >"c:\Program Files\Java\jdk-9.0.4\bin\jlink" --verbose --module-path 
"jdk-11-oraopenjdk\jmods" --output o1 
--add-modules=java.base,jdk.crypto.mscapi,jdk.jartool,jdk.jcmd,jdk.jshell,jdk.naming.dns
 --strip-debug --compress 2 --no-header-files
…
Error: java.lang.IllegalArgumentException

C:\>"c:\Program Files\Java\jdk-10.0.1\bin\jlink" --verbose --module-path 
"jdk-11-oraopenjdk\jmods" --output o2 
--add-modules=java.base,jdk.crypto.mscapi,jdk.jartool,jdk.jcmd,jdk.jshell,jdk.naming.dns
 --strip-debug --compress 2 --no-header-files
Error: Error reading module: jdk-11-oraopenjdk\jmods\java.base.jmod

C:\>"c:\Program Files\Java\jdk-11\bin\jlink" --verbose --module-path 
"jdk-11-oraopenjdk\jmods" --output o3 
--add-modules=java.base,jdk.crypto.mscapi,jdk.jartool,jdk.jcmd,jdk.jshell,jdk.naming.dns
 --strip-debug --compress 2 --no-header-files
…
Providers:
…

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Re: [concurrency-interest] Durations in existing JDK APIs

[Gregg Wonderly]

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 Buchholz via Concurrency-interest 
>  wrote:
> 
> v.0.2 has both conversion methods in TimeUnit.  The unexpected weirdness is 
> that convert(Duration) saturates while toDuration throws ArithmeticException, 
> but both seem author-culture-consistent.  Perhaps TimeUnit#toDuration doesn't 
> provide enough value in view of the existing Duration.of and 
> TimeUnit#toChronoUnit.  And most of the time you'd expect to convert from 
> Duration to long, just before calling a TimeUnit based method.
> 
> /**
>  * Converts the given time duration to this unit.
>  *
>  * @param duration the time duration
>  * @return the converted duration in this unit,
>  * or {@code Long.MIN_VALUE} if conversion would negatively overflow,
>  * or {@code Long.MAX_VALUE} if it would positively overflow.
>  * @throws NullPointerException if {@code duration} is null
>  */
> public long convert(Duration duration) {
> long s = convert(duration.getSeconds(), SECONDS);
> if (s == Long.MIN_VALUE) return s;
> long n = convert(duration.getNano(), NANOSECONDS);
> assert n >= 0 && n < 1_000_000_000;
> return (s + n < s) ? Long.MAX_VALUE : s + n;
> }
> 
> /**
>  * Converts the given time duration in this unit to a Duration.
>  *
>  * @param duration the time duration
>  * @return the time duration represented as a Duration
>  * @throws ArithmeticException if the duration cannot be represented
>  * as a Duration due to numeric overflow
>  */
> public Duration toDuration(long duration) {
> return Duration.of(duration, toChronoUnit());
> }
> 
> ___
> Concurrency-interest mailing list
> concurrency-inter...@cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[Lance Andersen]

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 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 
> NoSuchMethodError back to the caller. Thread.stop(Throwable) was made 
> non-functional in JDK 8, throwing UnsupportedOperationException back to the 
> caller.
> 
> Note that the no-arg Thread.stop() method remains deprecated, not for 
> removal, and is unaffected by this changeset.
> 
> Note also that ThreadGroup.destroy() doesn't actually destroy any threads -- 
> just thread groups -- and that it is also unaffected by this changeset.
> 
> Bug:
> 
>   https://bugs.openjdk.java.net/browse/JDK-8204243
> 
> Webrev:
> 
>   http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.0/
> 
> Thanks,
> 
> s'marks
> aka @DrDeprecator

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[Stuart Marks]

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 NoSuchMethodError 
back to the caller. Thread.stop(Throwable) was made non-functional in JDK 8, 
throwing UnsupportedOperationException back to the caller.


Note that the no-arg Thread.stop() method remains deprecated, not for removal, 
and is unaffected by this changeset.


Note also that ThreadGroup.destroy() doesn't actually destroy any threads -- 
just thread groups -- and that it is also unaffected by this changeset.


Bug:

https://bugs.openjdk.java.net/browse/JDK-8204243

Webrev:

http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.0/

Thanks,

s'marks
aka @DrDeprecator

Re: RFR: 8203357 Container Metrics

[mandy chung]

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 the diff.
It may worth to state that the output is implementation detail.

It may help to clarify the behavior when running on non-linux platform,
i.e. the current launcher implementation accepts any suboption value.
So java -XshowSettings:system on non-linux platform displays vm,
properties, locale settings. (BTW, I file JDK-8204246 about invalid 
suboption).


Mandy

Re: RFR: 8203357 Container Metrics

[Bob Vandette]

> 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 webrev:

 http://cr.openjdk.java.net/~bobv/8203357/webrev.01/

> 
> Looks fine in general.  It's good to have this internal API ready
> for JFR and other library code to use.
> 
> I skimmed through the new tests.  It'd be good to add some comments
> to describe what it does (for example, set up a docker image etc).

DockerTestUtils.java does contain some comments describing what the
utility functions do.  I’ll add a brief comment in TestDockerCpuMetrics.java
and TestDockerMemoryMetrics.java explaining the test process.

> 
> launcher.properties
> 154 \-XshowSettings:system (Linux Only) show host system or container\n\
> 155 \  configuration and continue\n\
> 
> A newline can be placed after -XshowSettings:system consistent with
> other suboptions.

Done.  I also added a newline after the vm sub-option.

> 
> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java
> 
> There are several long lines in the new test files such as:
>   MetricsCpuTester.java
>   MetricsMemoryTester.java
>   MetricsTester.java

> 
> It'd help future side-by-side review if they are wrapped. I think
> most of them are the construction of an exception.

Fixed.

> 
> I see a pattern of a name after @test and that is not strictly needed.
> 
> TestCgroupMetrics.java
>  25  * @test TestCgroupMetrics
> 
> TestDockerCpuMetrics.java
>  34  * @test TestSystemMetrics
> 
> TestDockerMemoryMetrics.java
>  30  * @test TestSystemMetrics
> 
> TestSystemMetrics.java
>  25  * @test TestSystemMetrics

Remove the names after @test.

> 
> This needs a CSR for the new -XshowSettings:system option.

I filed a CSR for this a few days ago.

https://bugs.openjdk.java.net/browse/JDK-8204107

Bob.



> 
> Mandy

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Baesken, Matthias]

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: Remove mapfiles for JDK executables
http://hg.openjdk.java.net/jdk/jdk/rev/210cf224b690

8200178: Remove mapfiles for JDK native libraries
http://hg.openjdk.java.net/jdk/jdk/rev/396ea30afbd5

I guess it  might  need further  testing+adjustments  to make  the  "visibility 
hiding" work nicely   with XLC13  ,  but currently  we build only with XLC12 .  

As a workaround  you might want to  remove  the  "-qvisibility=hidden"  setting 
for XLC 13 as well  ,  like I did  for XLC12 with  the change   8202322   .


Best regards, Matthias




> -Original Message-
> From: Langer, Christoph
> Sent: Freitag, 1. Juni 2018 10:57
> To: Ichiroh Takiguchi 
> Cc: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' ; ppc-aix-port-
> d...@openjdk.java.net; core-libs-dev@openjdk.java.net; Lindenmaier,
> Goetz 
> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
> 
> 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 they are declared exported,
> e.g. JNIEXPORT. So I would think "-qvisibility=hidden" should be the correct
> default and whatever JNIEXPORT expands to should contain the right
> attributes to get that symbol visible.
> 
> Can you check if either my assumption is completely wrong, JNIEXPORT does
> not expand to the right thing, XLC 13 has a bug or maybe just sume specific
> required symbols are not declared correctly?
> 
> Best regards
> Christoph
> 
> > -Original Message-
> > From: Ichiroh Takiguchi [mailto:taki...@linux.vnet.ibm.com]
> > Sent: Donnerstag, 31. Mai 2018 09:55
> > To: Langer, Christoph 
> > Cc: Baesken, Matthias ; 'build-
> > d...@openjdk.java.net' ; ppc-aix-port-
> > d...@openjdk.java.net; core-libs-dev@openjdk.java.net; Lindenmaier,
> > Goetz 
> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> > 12.1
> >
> > Hello.
> > 8202322 was integrated into jdk-11+15.
> > I'm using XLC 13.1.3 on AIX 7.1.4.
> > Build was failed because of "-qvisibility=hidden" on
> > make/lib/LibCommon.gmk.
> > According to "XL C/C++ for AIX 13.1.3" documentation [1],
> > "-qvisibility=hidden" cannot create shared libraries entry points.
> > For example, libverify.so was there, but entry points were not resolved
> > by "-lverify" option.
> > I think it should be "-qvisibility=default" (I tried, it worked)
> > or "-qvisibility=protected" (I had not tried) ?
> > I'm not familiar with -qvisibility option, but I'd like to find out
> > right way.
> >
> > [1]
> >
> https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm.
> > xlcpp1313.aix.doc/compiler_ref/opt_visibility.html
> >
> > On 2018-05-16 16:08, Langer, Christoph wrote:
> > > Hi Matthias,
> > >
> > > yes, reviewed.
> > >
> > > Best regards
> > > Christoph
> > >
> > > From: Baesken, Matthias
> > > Sent: Mittwoch, 16. Mai 2018 09:06
> > > To: Langer, Christoph ;
> > > 'build-...@openjdk.java.net' ;
> > > ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net
> > > Cc: Lindenmaier, Goetz 
> > > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> > > xlc 12.1
> > >
> > > Hi  Christoph can I add you as second reviewer  (other reviewer was
> > > Erik Joelsson) can push the change ?
> > >
> > > Best regards, Matthias
> > >
> > >
> > >
> > > From: Langer, Christoph
> > > Sent: Donnerstag, 26. April 2018 16:38
> > > To: Baesken, Matthias
> > > mailto:matthias.baes...@sap.com>>;
> > > 'build-...@openjdk.java.net'
> > > mailto:build-...@openjdk.java.net>>;
> > > ppc-aix-port-...@openjdk.java.net > d...@openjdk.java.net>;
> > > core-libs-dev@openjdk.java.net d...@openjdk.java.net>
> > > Cc: Simonis, Volker
> > > mailto:volker.simo...@sap.com>>
> > > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> > > xlc 12.1
> > >
> > > Hi Matthias,
> > >
> > > to me the change in principal looks good.
> > >
> > > I'm wondering if it is possible to do a comparison like xlc < 13 (e.g.
> > > extract major number before the first dot, then compare numerically) -
> > > but maybe it is too complicated and the current single version compare
> > > suits our needs ?
> > >
> > > Best regards
> > > Christoph
> > >
> > > From: Baesken, Matthias
> > > Sent: Donnerstag, 26. April 2018 16:14
> > > To: 'build-...@openjdk.java.net'
> > > mailto:build-...@openjdk.java.net>>;
> > > ppc-aix-port-...@openjdk.java.net > d...@openjdk.java.net>;
> > > core-libs-dev@ope

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Langer, Christoph]

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 they are declared exported, e.g. 
JNIEXPORT. So I would think "-qvisibility=hidden" should be the correct default 
and whatever JNIEXPORT expands to should contain the right attributes to get 
that symbol visible.

Can you check if either my assumption is completely wrong, JNIEXPORT does not 
expand to the right thing, XLC 13 has a bug or maybe just sume specific 
required symbols are not declared correctly?

Best regards
Christoph

> -Original Message-
> From: Ichiroh Takiguchi [mailto:taki...@linux.vnet.ibm.com]
> Sent: Donnerstag, 31. Mai 2018 09:55
> To: Langer, Christoph 
> Cc: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' ; ppc-aix-port-
> d...@openjdk.java.net; core-libs-dev@openjdk.java.net; Lindenmaier,
> Goetz 
> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
> 
> Hello.
> 8202322 was integrated into jdk-11+15.
> I'm using XLC 13.1.3 on AIX 7.1.4.
> Build was failed because of "-qvisibility=hidden" on
> make/lib/LibCommon.gmk.
> According to "XL C/C++ for AIX 13.1.3" documentation [1],
> "-qvisibility=hidden" cannot create shared libraries entry points.
> For example, libverify.so was there, but entry points were not resolved
> by "-lverify" option.
> I think it should be "-qvisibility=default" (I tried, it worked)
> or "-qvisibility=protected" (I had not tried) ?
> I'm not familiar with -qvisibility option, but I'd like to find out
> right way.
> 
> [1]
> https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm.
> xlcpp1313.aix.doc/compiler_ref/opt_visibility.html
> 
> On 2018-05-16 16:08, Langer, Christoph wrote:
> > Hi Matthias,
> >
> > yes, reviewed.
> >
> > Best regards
> > Christoph
> >
> > From: Baesken, Matthias
> > Sent: Mittwoch, 16. Mai 2018 09:06
> > To: Langer, Christoph ;
> > 'build-...@openjdk.java.net' ;
> > ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net
> > Cc: Lindenmaier, Goetz 
> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> > xlc 12.1
> >
> > Hi  Christoph can I add you as second reviewer  (other reviewer was
> > Erik Joelsson) can push the change ?
> >
> > Best regards, Matthias
> >
> >
> >
> > From: Langer, Christoph
> > Sent: Donnerstag, 26. April 2018 16:38
> > To: Baesken, Matthias
> > mailto:matthias.baes...@sap.com>>;
> > 'build-...@openjdk.java.net'
> > mailto:build-...@openjdk.java.net>>;
> > ppc-aix-port-...@openjdk.java.net d...@openjdk.java.net>;
> > core-libs-dev@openjdk.java.net
> > Cc: Simonis, Volker
> > mailto:volker.simo...@sap.com>>
> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> > xlc 12.1
> >
> > Hi Matthias,
> >
> > to me the change in principal looks good.
> >
> > I'm wondering if it is possible to do a comparison like xlc < 13 (e.g.
> > extract major number before the first dot, then compare numerically) -
> > but maybe it is too complicated and the current single version compare
> > suits our needs ?
> >
> > Best regards
> > Christoph
> >
> > From: Baesken, Matthias
> > Sent: Donnerstag, 26. April 2018 16:14
> > To: 'build-...@openjdk.java.net'
> > mailto:build-...@openjdk.java.net>>;
> > ppc-aix-port-...@openjdk.java.net d...@openjdk.java.net>;
> > core-libs-dev@openjdk.java.net
> > Cc: Langer, Christoph
> > mailto:christoph.lan...@sap.com>>; Simonis,
> > Volker mailto:volker.simo...@sap.com>>
> > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> > 12.1
> >
> > Hello  ,  could you please review this small adjustment to  the symbol
> > visibility compilation settings on AIX ?
> > Currently  we use  XLC 12.1  to compile  JDK on AIX .
> >
> > However XLC 12.1   does not support  the "-qvisibility=hidden"
> > setting currently set on AIX.
> > It was introduced with  XLC 13.1 . Christoph found some info about it
> > here :
> >
> > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-
> visibility-part2/index.html
> >
> > Setting it  only generates  hundreds  of warnings  in the build log ,
> > warnings look like this :
> > XlC12.1
> >
> > bash-4.4$ xlC -qversion
> > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
> > Version: 12.01..0019
> >
> > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list
> > of valid options.
> >
> > Compare to XLC13.1
> >
> > bash-3.00$ xlC -qversion
> > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
> > Version: 13.01..0008
> > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
> > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc

Re: RFR(XS): 8202329 [AIX] Fix codepage mappings for IBM-943 and Big5

[Bhaktavatsal R Maram]

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): 8202329 [AIX] Fix codepage mappings for IBM-943 and Big5

Hi Bhaktavatsal,

the fix is fine. Reviewed. Thanks a lot for your work!

Could you please (its okay in a future patch) add a regression test
for IBM943 and IBM943C, in the form of a jtreg test? I would like to
test conversions for both code pages (at least for the crucial
tilde/backslash code points).

Additionally, that when started on AIX with Ja_JP.IBM-943, we
correctly default to IBM943C.

As an example, here is an old test I wrote years ago. You won't be
able to use it verbatim, so it is just a suggestion. Feel free to do
it differently.

http://cr.openjdk.java.net/~stuefe/other/IBM943MappingTest.java

If you have not written jtreg tests before:

http://openjdk.java.net/jtreg/

Also, under /test are many many examples.

Best Regards, Thomas

On Mon, May 21, 2018 at 9:47 AM, Bhaktavatsal R Maram
 wrote:
> Hi Thomas,
>
> Is this fix ready to merge?
>
> Thanks,
> Bhaktavatsal
>
>
>
>
> -"Thomas Stüfe"  wrote: -
> To: Ichiroh Takiguchi , Bhaktavatsal R Maram 
> 
> From: "Thomas Stüfe" 
> Date: 05/11/2018 11:49AM
> Cc: Volker Simonis , Java Core Libs 
> 
> Subject: Re: RFR(XS): 8202329 [AIX] Fix codepage mappings for IBM-943 and Big5
>
> Hi,
>
> I'll test and review next week. We also have some in-house tests which
> I'd like to run.
>
> You IBM folks should really apply for authorship so that this
> contribution process gets streamlined. After all, if something breaks
> in this code, you want to be able to fix it, yes? So even if you do
> not contribute much else, more patches may be forthcoming.
>
> Of course I hope these are not your last contributions :)
>
> Best, Thomas
>
>
>
> On Fri, May 11, 2018 at 7:57 AM, Ichiroh Takiguchi
>  wrote:
>> Hi.
>>
>> I tested this fix on AIX.
>>
>> I got following results.
>> $ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset
>> Ja_JP   x-IBM943C   IBM-943CIBM-943C
>> $ LANG=Ja_JP.IBM-943 ~/jdk/bin/java PrintDefaultCharset
>> Ja_JP.IBM-943   x-IBM943C   IBM-943CIBM-943C
>> $ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset
>> Zh_TW   x-IBM950IBM-950 IBM-950
>> $ LANG=Zh_TW.big5 ~/jdk/bin/java PrintDefaultCharset
>> Zh_TW.big5  x-IBM950IBM-950 IBM-950
>>
>> Also I reviewed source code, it's fine
>>
>> Since this testing requires locale installation for Ja_JP and Zh_TW,
>> so it's not easy to test it...
>> (At least, I think bos.loc.pc.Ja_JP and bos.loc.iso.Zh_TW filesets are
>> required)
>>
>>
>> On 2018-05-02 18:32, Volker Simonis wrote:
>>>
>>> Hi Bhaktavatsal Reddy,
>>>
>>> your change looks good. I can sponsor it.
>>>
>>> Just waiting for a second review...
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>>
>>> On Mon, Apr 30, 2018 at 11:29 AM, Bhaktavatsal R Maram
>>>  wrote:

 Hi All,

 Please review the fix.

 bug: https://bugs.openjdk.java.net/browse/JDK-8202329
 webrev: http://cr.openjdk.java.net/~aleonard/8202329/webrev.00/

 Thanks,
 Bhaktavatsal Reddy

 -"core-libs-dev"  wrote:
 -
 To: Volker Simonis 
 From: "Bhaktavatsal R Maram"
 Sent by: "core-libs-dev"
 Date: 04/26/2018 09:31PM
 Cc: Java Core Libs 
 Subject: Re: [AIX] Fix codepage mappings in Java for IBM-943 and Big5

 Hi Volker,

 Thank you. I will address your review comments and send webrev for
 review.

 - Bhaktavatsal Reddy



 -Volker Simonis  wrote: -
 To: Bhaktavatsal R Maram 
 From: Volker Simonis 
 Date: 04/26/2018 09:12PM
 Cc: Java Core Libs 
 Subject: Re: [AIX] Fix codepage mappings in Java for IBM-943 and Big5

 Hi Bhaktavatsal Reddy,

 I've opened the following issue for this problem:

 8202329: [AIX] Fix codepage mappings for IBM-943 and Big5

 https://bugs.openjdk.java.net/browse/JDK-8202329

 Looking at you fix, can you please replace the "#elif AIX" by "#ifdef
 AIX" and the original "#else" by "#ifdef __solaris__". The original
 else branch contains Solaris-only code anyway and it is an historical
 omission that there are still a lot of places in the code where "not
 Linux" implicitly means "Solaris", but that's often wrong.

 Regards,
 Volker


 On Thu, Apr 26, 2018 at 4:02 PM, Bhaktavatsal R Maram
  wrote:
>
> Oops! Looks like there is problem with attachment (might be because I
> attached .class file as well). I'm pasting the fix and test program here 
> in
> mail.
>
> Test Program:
>
> import java.nio.charset.*;
> class PrintDefaultCharset {
>  public static void main(String[] args) {
> Sy

Re: Draft JEP proposal: JDK-8200758: Packaging Tool

[Alan Bateman]

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 delivered as part of the JavaFX build. The 
javapackager tool has been removed from Oracle JDK 11 along with the 
removal of JavaFX.


Comments on this JEP are welcome. It is currently not targeted for a 
specific release, but we are aiming for JDK 12.


-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8200758


I read through the draft.

The Goals and Non-Goals looks very reasonable.

The Summary includes "self-contained Java Server ... applications" but 
the JEP doesn't say too much about that part. Can we assume it can be 
started and stopped with /etc/init.d or equivalent scripts, logs with 
the server output etc? A general observation is that most of the issues 
around end-user/GUI applications are clearly documented in the draft, 
the headless application environment case less so. It makes me wonder if 
this JEP should be split so that it initially focuses on the former.


I think it would be useful if the JEP explained what an "application" 
is. Is it a JAR file (with a Main-Class) that is deployed on the class 
path? Can it be a module? What about modules and libraries that the 
application uses. Users of javapackager might know these things but 
readers of the JEP may not.


The JEP mentions that JavaFX will be removed in JDK 11. I assume this 
should be clarified so that it's clear it will no longer be shipped in 
Oracle's JDK. It's a none issue for those using OpenJDK builds as the 
the JavaFX modules were never bundled/imported by default.


There are several references to "server JRE" that probably should be 
clarified as this notion does not exist in OpenJDK. It may be that the 
JEP just needs to clearer as to the modules that it links into the 
run-time image.


There are several references to "application launcher" and "native 
launcher". At some point we need to work out some issues with jlink as 
it it will need to generate native launchers too. The JEP could list it 
as an issue as the development of this JEP will at least touch on some 
of this.


The draft doesn't have a section on testing. If someone is building 
OpenJDK then will they will require additional tools in the build 
environment and can the tests be run without manual interaction? Also 
how about a developer using the tool, will the generated native packages 
be easy to un-install so they can easily test in a local environment?


-Alan