From Eric.Pierskalla at datalogic.com  Wed Nov  1 19:32:25 2017
From: Eric.Pierskalla at datalogic.com (Pierskalla, Eric)
Date: Wed, 1 Nov 2017 19:32:25 +0000
Subject: CORBA in JDK 9
Message-ID: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>

The following is from the JDK 9 Migration Guide  https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6



<start of quoted text>



Removed Endorsed Standards Override Mechanism



The java.endorsed.dirs system property and the lib/endorsed directory are no longer present. The javac compiler and java launcher will exit if either one is detected.

In JDK 9, you can use upgradeable modules or put the JAR files on the class path.



<some deleted text>



Modules Shared with Java EE Not Resolved by Default



In JDK 9, the modules that contain CORBA or the APIs shared between Java SE and Java EE are not resolved by default when you compile or run code on the class path. These are:

    java.corba - CORBA



<more deleted text>



Existing code with references to classes in these APIs will not compile without changes to the build. Similarly, code on the class path with references to classes in these APIs will fail with NoDefClassFoundError or ClassNotFoundException unless changes are made in how the application is deployed.



The code for these APIs was not removed in JDK 9, although the modules are deprecated for removal. The policy of not resolving these modules is a first step toward removing these APIs from Java SE and the JDK in a future release.



The migration options for libraries or applications that use these APIs are:



    1. Use the --add-modules command-line option to ensure that the module with the API is resolved at startup. For example, specify --add-module java.xml.bind to ensure that the java.xml.bind module is resolved. This allows existing code that uses the JAXB API and implementation to work as it did in JDK 8.



    This is a temporary workaround because eventually these modules will be removed from the JDK.



    Using --add-modules java.se.ee or --add-modules ALL-SYSTEM as a workaround is not recommended. These options will resolve all Java EE modules, which is problematic in environments that are also using the standalone versions of APIs.



    2. Deploy the standalone version of the API (and implementation if needed) on the class path. Each of the Java EE APIs are standalone technologies with projects published in Maven Central.



    3. Deploy the standalone version of these modules on the upgrade module path. The standalone versions are provided by the Java EE project.



<end of quoted text from Migration Guide>



Currently we use the endorsed standard override mechanism to run an alternate version of CORBA in our application.  There is obviously current and future issues with trying to do this in JDK 9.

Therefore, I am trying to implement migration option #2, however I am not able to locate anything that looks like a JDK 9 compatible CORBA project in Maven Central.



Does anyone know where this is located?



Eric







CONFIDENTIALITY NOTICE. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please destroy all copies of the original message, including any and all attachments, and notify the sender immediately.


From Alan.Bateman at oracle.com  Wed Nov  1 20:41:32 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 Nov 2017 20:41:32 +0000
Subject: CORBA in JDK 9
In-Reply-To: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>
References: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>
Message-ID: <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>

On 01/11/2017 19:32, Pierskalla, Eric wrote:
> :
>
> Currently we use the endorsed standard override mechanism to run an alternate version of CORBA in our application.  There is obviously current and future issues with trying to do this in JDK 9.
>
> Therefore, I am trying to implement migration option #2, however I am not able to locate anything that looks like a JDK 9 compatible CORBA project in Maven Central.
>
>
>
> Does anyone know where this is located?
>
The short answer is that RMI-IIOP is not a standalone technology in the 
JCP and this project does not publish a JAR file with the CORBA and 
RMI-IIOP classes.

Can you say anything about the "alternative version of CORBA" that you 
are using? Is it a complete replacement and does it include its own copy 
of the RMI-IIOP classes? Does it run when deployed on the class path or 
does it rely on augmenting the CORBA classes in the JDK.

Going forward then the proposal is to remove CORBA from Java SE and the 
JDK. JDK-8189188 [1] is the (still in draft) JEP with all the details.

-Alan

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

From Eric.Pierskalla at datalogic.com  Wed Nov  1 21:16:04 2017
From: Eric.Pierskalla at datalogic.com (Pierskalla, Eric)
Date: Wed, 1 Nov 2017 21:16:04 +0000
Subject: CORBA in JDK 9
In-Reply-To: <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>
References: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>
 <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>
Message-ID: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDB009@eugsrv402.dl.net>

We are using JacORB which apparently only augments the CORBA classes in the JDK.  In JDK-8189188, it notes that JacORB includes classes in the org.omg.** package hierarchy but not the javax.rmi.** package hierarchy.  This supports what I am seeing.  I moved the JacORB classes out of the endorsed folder onto the classpath, and it continued to function in JRE 8.
In JRE 9, without --add-modules java.corba, I get "java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub".
With --add-modules java.corba , the error becomes" java.lang.NoClassDefFoundError: org/omg/CORBA/ORBSingleton".  After some research, I suspect this is a result of http://bugs.java.com/view_bug.do?bug_id=8042789

It seems that the best route is to make JacORB truly stand-alone.  Doing this in a timely fashion in a legal way seems difficult.

Eric


-----Original Message-----
From: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
Sent: Wednesday, November 01, 2017 3:42 PM
To: Pierskalla, Eric; jdk9-dev at openjdk.java.net
Subject: Re: CORBA in JDK 9

On 01/11/2017 19:32, Pierskalla, Eric wrote:
> :
>
> Currently we use the endorsed standard override mechanism to run an alternate version of CORBA in our application.  There is obviously current and future issues with trying to do this in JDK 9.
>
> Therefore, I am trying to implement migration option #2, however I am not able to locate anything that looks like a JDK 9 compatible CORBA project in Maven Central.
>
>
>
> Does anyone know where this is located?
>
The short answer is that RMI-IIOP is not a standalone technology in the JCP and this project does not publish a JAR file with the CORBA and RMI-IIOP classes.

Can you say anything about the "alternative version of CORBA" that you are using? Is it a complete replacement and does it include its own copy of the RMI-IIOP classes? Does it run when deployed on the class path or does it rely on augmenting the CORBA classes in the JDK.

Going forward then the proposal is to remove CORBA from Java SE and the JDK. JDK-8189188 [1] is the (still in draft) JEP with all the details.

-Alan

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





CONFIDENTIALITY NOTICE. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please destroy all copies of the original message, including any and all attachments, and notify the sender immediately.







CONFIDENTIALITY NOTICE. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please destroy all copies of the original message, including any and all attachments, and notify the sender immediately.


From scolebourne at joda.org  Wed Nov  1 21:19:20 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 1 Nov 2017 21:19:20 +0000
Subject: CORBA in JDK 9
In-Reply-To: <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>
References: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>
 <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>
Message-ID: <CACzrW9AmuNg3PeP45hRYaDU-8BqGUsqCV_h04A9wLHqzDDEK+A@mail.gmail.com>

On 1 November 2017 at 20:41, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> Going forward then the proposal is to remove CORBA from Java SE and the JDK.

I think the key question here is whether a community GitHub project
could be created taking the original OpenJDK source code for CORBA in
the original packages, maintain it and release it.

Stephen

From david.lloyd at redhat.com  Wed Nov  1 21:23:17 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 1 Nov 2017 16:23:17 -0500
Subject: CORBA in JDK 9
In-Reply-To: <CACzrW9AmuNg3PeP45hRYaDU-8BqGUsqCV_h04A9wLHqzDDEK+A@mail.gmail.com>
References: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>
 <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>
 <CACzrW9AmuNg3PeP45hRYaDU-8BqGUsqCV_h04A9wLHqzDDEK+A@mail.gmail.com>
Message-ID: <CANghgrRFQWX-kc8sir5UjTuR2V+krR9a7AHEtkahK1_YhzsZeg@mail.gmail.com>

On Wed, Nov 1, 2017 at 4:19 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> On 1 November 2017 at 20:41, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> Going forward then the proposal is to remove CORBA from Java SE and the JDK.
>
> I think the key question here is whether a community GitHub project
> could be created taking the original OpenJDK source code for CORBA in
> the original packages, maintain it and release it.

Such a thing is possible.  We've been maintaining
https://github.com/jboss/openjdk-orb in order to add a few necessary
features not found in the JDK ORB.
-- 
- DML

From kanth909 at gmail.com  Wed Nov  1 23:35:05 2017
From: kanth909 at gmail.com (kant kodali)
Date: Wed, 1 Nov 2017 16:35:05 -0700
Subject: Can JVM generate Vectorized instructions?
In-Reply-To: <CA+iiNx87pLL2bH0ipPiJ7jnTrzUXFaTVO94sXfL1k7AsK_0e5Q@mail.gmail.com>
References: <CA+iiNx_mUv5EcWmHi1=_hT_uGnaV2OrU4hyaTdqt-JXb1s5LrQ@mail.gmail.com>
 <819478949.1235246.1497987570318.JavaMail.zimbra@u-pem.fr>
 <CA+iiNx87pLL2bH0ipPiJ7jnTrzUXFaTVO94sXfL1k7AsK_0e5Q@mail.gmail.com>
Message-ID: <CA+iiNx_p9dDstC2a6f=3bkxCmTP0kVSVLn0ZcVg9_bupd0sTEg@mail.gmail.com>

Hi All,

Does jdk-9 has Vector API now? I couldn't find it in the API docs.

Thanks!

On Tue, Jun 27, 2017 at 7:29 PM, kant kodali <kanth909 at gmail.com> wrote:

> http://prestodb.rocks/code/simd/
>
> On Tue, Jun 20, 2017 at 12:39 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> yes :)
>>
>> Vladimir Ivanov has a nice set of slides about vectorization in Java 8, 9
>> and the future:
>>   http://cr.openjdk.java.net/~vlivanov/talks/2017_Vectorizatio
>> n_in_HotSpot_JVM.pdf
>>
>> You can also follow the OpenJDK project Panama for more info.
>>
>> R?mi
>>
>> ----- Mail original -----
>> > De: "kant kodali" <kanth909 at gmail.com>
>> > ?: "jdk9-dev" <jdk9-dev at openjdk.java.net>
>> > Envoy?: Mardi 20 Juin 2017 20:19:17
>> > Objet: Can JVM generate Vectorized instructions?
>>
>> > Hi All,
>> >
>> > Can JVM generate Vectorized instructions (SIMD/MIMD)? Any pointers
>> would be
>> > great.
>> >
>> > Thanks!
>>
>
>

From Alan.Bateman at oracle.com  Thu Nov  2 07:44:36 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Nov 2017 07:44:36 +0000
Subject: CORBA in JDK 9
In-Reply-To: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDB009@eugsrv402.dl.net>
References: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>
 <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>
 <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDB009@eugsrv402.dl.net>
Message-ID: <17b9cee2-1522-051f-624d-8a980477ba57@oracle.com>

On 01/11/2017 21:16, Pierskalla, Eric wrote:
> We are using JacORB which apparently only augments the CORBA classes in the JDK.  In JDK-8189188, it notes that JacORB includes classes in the org.omg.** package hierarchy but not the javax.rmi.** package hierarchy.  This supports what I am seeing.  I moved the JacORB classes out of the endorsed folder onto the classpath, and it continued to function in JRE 8.
> In JRE 9, without --add-modules java.corba, I get "java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub".
> With --add-modules java.corba , the error becomes" java.lang.NoClassDefFoundError: org/omg/CORBA/ORBSingleton".
Right, JacORB seems to be incomplete and so not a drop-in replacement 
for the java.corba module. If it were a drop-in replacement then you 
could deploy it on the class path or deploy it as a module on the 
upgrade module path (to override the java.corba module in the JDK).

I expect this will work:

--add-modules java.corba \
--patch-module java.corba=<JacORB-JAR-files-with-API-classes>

> After some research, I suspect this is a result of http://bugs.java.com/view_bug.do?bug_id=8042789
JDK 9 does the right thing and will not attempt to load the system-wide 
singleton ORB using the per-application TCCL. The details of this change 
are documented in the release notes [1].

-Alan

[1] 
http://www.oracle.com/technetwork/java/javase/9-notes-3745703.html#JDK-8025005

From Alan.Bateman at oracle.com  Thu Nov  2 08:03:07 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Nov 2017 08:03:07 +0000
Subject: CORBA in JDK 9
In-Reply-To: <CACzrW9AmuNg3PeP45hRYaDU-8BqGUsqCV_h04A9wLHqzDDEK+A@mail.gmail.com>
References: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>
 <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>
 <CACzrW9AmuNg3PeP45hRYaDU-8BqGUsqCV_h04A9wLHqzDDEK+A@mail.gmail.com>
Message-ID: <904c9d89-cdb7-aac9-57e5-57c9b5b10433@oracle.com>

On 01/11/2017 21:19, Stephen Colebourne wrote:
> On 1 November 2017 at 20:41, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> Going forward then the proposal is to remove CORBA from Java SE and the JDK.
> I think the key question here is whether a community GitHub project
> could be created taking the original OpenJDK source code for CORBA in
> the original packages, maintain it and release it.
Maybe, although there is also tooling such as the IDL compiler, a 
back-end for the RMI compiler to generate IIOP stubs and IDL, and 
several other tools.

The other possibility is the Java EE move to Eclipse as I assume that 
will include the RI, as in Glassfish with its dependency on CORBA. It 
would need some tooling and probably the JNDI CosNaming provider but 
otherwise might be an alternative replacement for those that want to 
keeping this area alive.

-Alan

From stephen.felts at oracle.com  Thu Nov  2 11:54:08 2017
From: stephen.felts at oracle.com (Stephen Felts)
Date: Thu, 2 Nov 2017 04:54:08 -0700 (PDT)
Subject: CORBA in JDK 9
In-Reply-To: <904c9d89-cdb7-aac9-57e5-57c9b5b10433@oracle.com>
References: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>
 <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>
 <CACzrW9AmuNg3PeP45hRYaDU-8BqGUsqCV_h04A9wLHqzDDEK+A@mail.gmail.com>
 <904c9d89-cdb7-aac9-57e5-57c9b5b10433@oracle.com>
Message-ID: <436d5c81-c395-41ff-aa89-3784579465e6@default>

As part of the work in the Java EE 8 reference implementation Glassfish 5.0, the Glassfish ORB was updated to include the hidden CORBA classes and use the JDK9 API's for serialization
It's available in maven org.glassfish.corba jar files version 4.1.1-b001.  The API classes are in glassfish_corba_omgapi.   Note that org.glassfish.pfl_basic.jar is a multi release jar file with the serialization API's.

Also, the idlj-maven-plugin was updated to support the Glassfish orb in addition to JDK and JacORB.  For JDK8 and earlier, it defaults to type "JDK" and for JDK9 and later it defaults to the Glassfish orb.

I recently did an experiment to generate a JDK image using jlink to remove the hidden modules completely (jdk.rmic jdk.xml.bind (JAXB tools) jdk.xml.ws (JAX-WS tools) java.activation java.corba java.transaction java.xml.bind java.xml.ws java.xml.ws.annotation java.se.ee).
One of the noted outages is that the idlj command line is missing (the maven plugin was used).  We are trying to get this added to the list of work items for GF.


-----Original Message-----
From: Alan Bateman 
Sent: Thursday, November 2, 2017 4:03 AM
To: Stephen Colebourne <scolebourne at joda.org>; jdk9-dev at openjdk.java.net
Subject: Re: CORBA in JDK 9

On 01/11/2017 21:19, Stephen Colebourne wrote:
> On 1 November 2017 at 20:41, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> Going forward then the proposal is to remove CORBA from Java SE and the JDK.
> I think the key question here is whether a community GitHub project 
> could be created taking the original OpenJDK source code for CORBA in 
> the original packages, maintain it and release it.
Maybe, although there is also tooling such as the IDL compiler, a back-end for the RMI compiler to generate IIOP stubs and IDL, and several other tools.

The other possibility is the Java EE move to Eclipse as I assume that will include the RI, as in Glassfish with its dependency on CORBA. It would need some tooling and probably the JNDI CosNaming provider but otherwise might be an alternative replacement for those that want to keeping this area alive.

-Alan

From Eric.Pierskalla at datalogic.com  Thu Nov  2 15:14:18 2017
From: Eric.Pierskalla at datalogic.com (Pierskalla, Eric)
Date: Thu, 2 Nov 2017 15:14:18 +0000
Subject: CORBA in JDK 9
In-Reply-To: <436d5c81-c395-41ff-aa89-3784579465e6@default>
References: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>
 <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>
 <CACzrW9AmuNg3PeP45hRYaDU-8BqGUsqCV_h04A9wLHqzDDEK+A@mail.gmail.com>
 <904c9d89-cdb7-aac9-57e5-57c9b5b10433@oracle.com>
 <436d5c81-c395-41ff-aa89-3784579465e6@default>
Message-ID: <F38D7FA259D636469C7DD27B4B2F3F1E03E2937D7E@eugsrv402.dl.net>

A question related to this statement in the JEP: https://bugs.openjdk.java.net/browse/JDK-8189188
"There is no significant interest in developing modern applications with CORBA in Java."
What technologies do modern Java applications use for RPC? Thrift?






CONFIDENTIALITY NOTICE. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please destroy all copies of the original message, including any and all attachments, and notify the sender immediately.


From adinn at redhat.com  Thu Nov  2 15:40:35 2017
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 2 Nov 2017 15:40:35 +0000
Subject: CORBA in JDK 9
In-Reply-To: <F38D7FA259D636469C7DD27B4B2F3F1E03E2937D7E@eugsrv402.dl.net>
References: <F38D7FA259D636469C7DD27B4B2F3F1E03DFEDAFDF@eugsrv402.dl.net>
 <a8084b40-118d-b7fb-f622-177ecbaedc1d@oracle.com>
 <CACzrW9AmuNg3PeP45hRYaDU-8BqGUsqCV_h04A9wLHqzDDEK+A@mail.gmail.com>
 <904c9d89-cdb7-aac9-57e5-57c9b5b10433@oracle.com>
 <436d5c81-c395-41ff-aa89-3784579465e6@default>
 <F38D7FA259D636469C7DD27B4B2F3F1E03E2937D7E@eugsrv402.dl.net>
Message-ID: <c5f3591e-8319-1d35-fadb-f1d32b5a76dd@redhat.com>

Hi Eric,

On 02/11/17 15:14, Pierskalla, Eric wrote:
> A question related to this statement in the JEP: https://bugs.openjdk.java.net/browse/JDK-8189188
> "There is no significant interest in developing modern applications with CORBA in Java."
> What technologies do modern Java applications use for RPC? Thrift?

Well, as one example, Red Hat's app server (EAP/Widlfly) uses JBoss
Remoting (although it will still use CORBA if you want).

n.b. I currently work for Red Hat but I'm answering this mostly because
I used to work for Data Logic in the UK many, many years ago (no,
/really/ many -- we are talking 1990-91) when CORBA was the wave of the
future :-).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From scolebourne at joda.org  Thu Nov  2 23:06:45 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 2 Nov 2017 23:06:45 +0000
Subject: Impact of six month releases
Message-ID: <CACzrW9DP=MVCqeA4rbo9rPts0fZP+2Wsrn15j_VJysUt3ytRnA@mail.gmail.com>

Like many others my first reaction on hearing of six monthly releases
was very positive. Great to see things move forward faster. However,
as time has progressed and more detail has come out I find myself
struggling to see how it is actually useful in practice.

This is the proposed timeline (as I understand it):

- 10.0.0 - Feature release March 2018
- 10.0.1 - Update release April 2018
- 10.0.2 - Update release July 2018
- 11.0.0 - Feature release September 2018
- 11.0.1 - Update release October 2018
- 11.0.2 - Update release January 2019
- 12.0.0 - Feature release March 2019

Note that there is no overlap between the last v10 update (security)
release 10.0.2 and the first v11 release. In order to be protected in
security terms developers are required to upgrade to 11.0.0
immediately on release.

I believe that this cannot work in practice.

Every single major (feature) release of Java I can remember has caused
a problem in at least one of the tools in the stack of the application
I was working on. To upgrade to a new Java major/feature version I'd
currently need all of these to be ready:

- Eclipse
- IntelliJ
- Travis CI
- Shippable
- Amazon AWS
- Maven
- Maven plugins (compile, jar, source, javadoc, site, etc)
- Checkstyle, & associated IDE plugins and maven plugin
- JaCoCo, & associated IDE plugins and maven plugin
- PMD, & associated maven plugin
- SpotBugs, & associated maven plugin
- OSGi bundle metadata tool
- Bytecode tools (Byte buddy / ASM etc)
- Over 100 jar file dependencies
- Probably something else I've forgotten

If just one of these isn't ready then I can't upgrade to the new
version of Java.

Now, historically, the solution to upgrading has been to wait. Over
time, the open source community would - often in their unpaid spare
time - bring the stack back to be working again. Traditionally, it has
taken many months for the point where the whole stack is viable again.

But to state the obvious - this simply does not work anymore.

If it takes 3 months for the stack to be viable again (hugely
optimistic) the version has just 3 months of life before the whole
cycle has to start again. My experience would actually say that 6
months (and 2 updates) is generally the point at which the stack is
fully stable and it would be OK to put a system into production. But,
the six month point is where you get no more security updates. The
logical conclusion is that this is a trap, and you should therefore
not attempt to join the eternal upgrade train.

As it stands, the only advice any consultant or experienced developer
could give would be to stick with Java 8 or a future LTS (which is in
theory v12, but with time-boxing it seems unwise to rely on that). The
intermediate releases between LTS versions are fundamentally unsuited
for use in production systems. In fact one might sensibly call them
"milestones"...

----

Given the above, I find this proposal from Mark, deeply concerning:

"Features may be added in a feature release; they may also be removed,
if advance notice was given at least one feature release ahead of
time."

The statement above indicates that code can be deprecated and removed
in just two releases. But there are 5 intermediate releases between
LTS ones on the current schedule (from 12 to 18). This means that
developers moving from LTS v12 to LTS v18 will probably see code fail
to compile without ever seeing a deprecation.

I think this is throwing the baby (Java's long standing backwards
compatibility) out with the bathwater (frequent releases), but I'm
happy to hear other opinions.

Stephen

From aph at redhat.com  Fri Nov  3 09:14:50 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 3 Nov 2017 09:14:50 +0000
Subject: Impact of six month releases
In-Reply-To: <CACzrW9DP=MVCqeA4rbo9rPts0fZP+2Wsrn15j_VJysUt3ytRnA@mail.gmail.com>
References: <CACzrW9DP=MVCqeA4rbo9rPts0fZP+2Wsrn15j_VJysUt3ytRnA@mail.gmail.com>
Message-ID: <52078f75-e29d-7ddf-934f-15fe1092c6aa@redhat.com>

On 02/11/17 23:06, Stephen Colebourne wrote:
> Given the above, I find this proposal from Mark, deeply concerning:
> 
> "Features may be added in a feature release; they may also be removed,
> if advance notice was given at least one feature release ahead of
> time."
> 
> The statement above indicates that code can be deprecated and removed
> in just two releases. But there are 5 intermediate releases between
> LTS ones on the current schedule (from 12 to 18). This means that
> developers moving from LTS v12 to LTS v18 will probably see code fail
> to compile without ever seeing a deprecation.
> 
> I think this is throwing the baby (Java's long standing backwards
> compatibility) out with the bathwater (frequent releases), but I'm
> happy to hear other opinions.

I don't believe that such worries are necessarily justified.

We need to be able to roll back mistakes.  The Java tradition that
nothing ever gets removed, no matter how much mistaken, holds back
innovation.  It does this because of a justified fear that if we make
a mistake, we're stuck with it, so we have to be ultra-cautious.

We who work on Java will be no more reckless than we have been in the
past.  We know that people need to trust Java, and don't want to lose
that trust in us.  But if we do something that turns out to have been
a mistake, and everyone agrees that it was a mistake, we must not be
constrained simply because the rules forbid us from fixing it.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From jai.forums2013 at gmail.com  Thu Nov  9 12:35:49 2017
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 9 Nov 2017 18:05:49 +0530
Subject: 8190917: SSL session resumption broken for protocols other than
 TLSv1.2
Message-ID: <a024cf8b-a326-576f-254e-1c00e720a38d@gmail.com>

I would like to contribute a patch, containing a potential fix and a 
test case, to the issue reported at 
https://bugs.openjdk.java.net/browse/JDK-8190917. This is going to be my 
first contribution to OpenJDK, so I would need some guidance/help in 
having this reviewed/merged, please.

To give a quick overview of this specific bug - the issue relates to SSL 
session resumption which is no longer functional in Java 9 for SSL 
protocols other than TLSv1.2. The JIRA itself has more extensive details 
and a test case which reproduces the issue.

So far, I have followed various documentation to setup and build OpenJDK 
jdk9 locally. I use a Mac and at this point, I have completed the 
following set of basic tasks:

 ??? - Checked out the mercurial repo (the complete forest) for jdk9 (hg 
tclone http://hg.openjdk.java.net/jdk9/jdk9)
 ??? - Built the JDK locally, following the instructions under 
common/doc/building.md
 ??? - Run some of the basic tests successfully

I have a potential fix ready and am in the process of writing a jtreg 
test for this change. I am going to sign and submit the Oracle 
Contributor Agreement this week soon (I believe that's needed right?).

Before sending out the patch for review, I would like to understand if 
there's anything else that I need to do before that. One thing that I 
read in the contribution page[1] is that "Your patch must be built and 
tested on all relevant platforms before submission". For me, the only 
platform that I have access to is going to be my local Mac OS. When I 
submit the patch, am I expected to test the changes on other *nix and 
Windows OS too?

If there's anything else that I left out, please feel free to let me 
know or point me to the doc.

[1] http://openjdk.java.net/contribute/

P.S: I hope this is the right mailing list. I read the "how to 
contribute" page and then guessed this is the correct mailing list, but 
I'm not sure since I don't see any similar contributions requests in the 
archive of this mailing list, this past year.

-Jaikiran



From david.holmes at oracle.com  Thu Nov  9 12:41:40 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Nov 2017 22:41:40 +1000
Subject: 8190917: SSL session resumption broken for protocols other than
 TLSv1.2
In-Reply-To: <a024cf8b-a326-576f-254e-1c00e720a38d@gmail.com>
References: <a024cf8b-a326-576f-254e-1c00e720a38d@gmail.com>
Message-ID: <baf1c022-6113-19d5-df82-32a85cd7ac78@oracle.com>

Hi Jaikiran,

JDK 9 has shipped so this mailing list is pretty quiet now. A bug fix 
needs to go into the main JDK project, and from there it can be 
backported to update releases if appropriate. In this case it looks like 
this would be something to take to the net-dev at openjdk.java.net mailing 
list.

Cheers,
David

On 9/11/2017 10:35 PM, Jaikiran Pai wrote:
> I would like to contribute a patch, containing a potential fix and a 
> test case, to the issue reported at 
> https://bugs.openjdk.java.net/browse/JDK-8190917. This is going to be my 
> first contribution to OpenJDK, so I would need some guidance/help in 
> having this reviewed/merged, please.
> 
> To give a quick overview of this specific bug - the issue relates to SSL 
> session resumption which is no longer functional in Java 9 for SSL 
> protocols other than TLSv1.2. The JIRA itself has more extensive details 
> and a test case which reproduces the issue.
> 
> So far, I have followed various documentation to setup and build OpenJDK 
> jdk9 locally. I use a Mac and at this point, I have completed the 
> following set of basic tasks:
> 
>  ??? - Checked out the mercurial repo (the complete forest) for jdk9 (hg 
> tclone http://hg.openjdk.java.net/jdk9/jdk9)
>  ??? - Built the JDK locally, following the instructions under 
> common/doc/building.md
>  ??? - Run some of the basic tests successfully
> 
> I have a potential fix ready and am in the process of writing a jtreg 
> test for this change. I am going to sign and submit the Oracle 
> Contributor Agreement this week soon (I believe that's needed right?).
> 
> Before sending out the patch for review, I would like to understand if 
> there's anything else that I need to do before that. One thing that I 
> read in the contribution page[1] is that "Your patch must be built and 
> tested on all relevant platforms before submission". For me, the only 
> platform that I have access to is going to be my local Mac OS. When I 
> submit the patch, am I expected to test the changes on other *nix and 
> Windows OS too?
> 
> If there's anything else that I left out, please feel free to let me 
> know or point me to the doc.
> 
> [1] http://openjdk.java.net/contribute/
> 
> P.S: I hope this is the right mailing list. I read the "how to 
> contribute" page and then guessed this is the correct mailing list, but 
> I'm not sure since I don't see any similar contributions requests in the 
> archive of this mailing list, this past year.
> 
> -Jaikiran
> 
> 

From sean.coffey at oracle.com  Thu Nov  9 12:46:01 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 9 Nov 2017 12:46:01 +0000
Subject: 8190917: SSL session resumption broken for protocols other than
 TLSv1.2
In-Reply-To: <baf1c022-6113-19d5-df82-32a85cd7ac78@oracle.com>
References: <a024cf8b-a326-576f-254e-1c00e720a38d@gmail.com>
 <baf1c022-6113-19d5-df82-32a85cd7ac78@oracle.com>
Message-ID: <cfc67155-48c6-a139-6320-c7b7f753ff82@oracle.com>

Hi Jaikiran,

Thanks for stepping up to offer a patch for this issue. 
security-dev at openjdk.java.net is the mailing list where you'll need to 
have the code review performed. Also, once you sign the OCA, you'll need 
to contribute the patch to the new JDK Project[1] via its new repo : 
http://hg.openjdk.java.net/jdk/jdk

regards,
Sean.

[1] http://openjdk.java.net/projects/jdk/

On 09/11/2017 12:41, David Holmes wrote:
> Hi Jaikiran,
>
> JDK 9 has shipped so this mailing list is pretty quiet now. A bug fix 
> needs to go into the main JDK project, and from there it can be 
> backported to update releases if appropriate. In this case it looks 
> like this would be something to take to the net-dev at openjdk.java.net 
> mailing list.
>
> Cheers,
> David
>
> On 9/11/2017 10:35 PM, Jaikiran Pai wrote:
>> I would like to contribute a patch, containing a potential fix and a 
>> test case, to the issue reported at 
>> https://bugs.openjdk.java.net/browse/JDK-8190917. This is going to be 
>> my first contribution to OpenJDK, so I would need some guidance/help 
>> in having this reviewed/merged, please.
>>
>> To give a quick overview of this specific bug - the issue relates to 
>> SSL session resumption which is no longer functional in Java 9 for 
>> SSL protocols other than TLSv1.2. The JIRA itself has more extensive 
>> details and a test case which reproduces the issue.
>>
>> So far, I have followed various documentation to setup and build 
>> OpenJDK jdk9 locally. I use a Mac and at this point, I have completed 
>> the following set of basic tasks:
>>
>> ???? - Checked out the mercurial repo (the complete forest) for jdk9 
>> (hg tclone http://hg.openjdk.java.net/jdk9/jdk9)
>> ???? - Built the JDK locally, following the instructions under 
>> common/doc/building.md
>> ???? - Run some of the basic tests successfully
>>
>> I have a potential fix ready and am in the process of writing a jtreg 
>> test for this change. I am going to sign and submit the Oracle 
>> Contributor Agreement this week soon (I believe that's needed right?).
>>
>> Before sending out the patch for review, I would like to understand 
>> if there's anything else that I need to do before that. One thing 
>> that I read in the contribution page[1] is that "Your patch must be 
>> built and tested on all relevant platforms before submission". For 
>> me, the only platform that I have access to is going to be my local 
>> Mac OS. When I submit the patch, am I expected to test the changes on 
>> other *nix and Windows OS too?
>>
>> If there's anything else that I left out, please feel free to let me 
>> know or point me to the doc.
>>
>> [1] http://openjdk.java.net/contribute/
>>
>> P.S: I hope this is the right mailing list. I read the "how to 
>> contribute" page and then guessed this is the correct mailing list, 
>> but I'm not sure since I don't see any similar contributions requests 
>> in the archive of this mailing list, this past year.
>>
>> -Jaikiran
>>
>>


From jai.forums2013 at gmail.com  Thu Nov  9 12:56:08 2017
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 9 Nov 2017 18:26:08 +0530
Subject: 8190917: SSL session resumption broken for protocols other than
 TLSv1.2
In-Reply-To: <cfc67155-48c6-a139-6320-c7b7f753ff82@oracle.com>
References: <a024cf8b-a326-576f-254e-1c00e720a38d@gmail.com>
 <baf1c022-6113-19d5-df82-32a85cd7ac78@oracle.com>
 <cfc67155-48c6-a139-6320-c7b7f753ff82@oracle.com>
Message-ID: <e3c15c4e-674f-54e1-5cb3-02df81e1b6ec@gmail.com>

Thank you Sean and David. I'll checkout this correct jdk project locally 
and open a new discussion in the security-dev mailing list.

-Jaikiran


On 09/11/17 6:16 PM, Se?n Coffey wrote:
> Hi Jaikiran,
>
> Thanks for stepping up to offer a patch for this issue. 
> security-dev at openjdk.java.net is the mailing list where you'll need to 
> have the code review performed. Also, once you sign the OCA, you'll 
> need to contribute the patch to the new JDK Project[1] via its new 
> repo : http://hg.openjdk.java.net/jdk/jdk
>
> regards,
> Sean.
>
> [1] http://openjdk.java.net/projects/jdk/
>
> On 09/11/2017 12:41, David Holmes wrote:
>> Hi Jaikiran,
>>
>> JDK 9 has shipped so this mailing list is pretty quiet now. A bug fix 
>> needs to go into the main JDK project, and from there it can be 
>> backported to update releases if appropriate. In this case it looks 
>> like this would be something to take to the net-dev at openjdk.java.net 
>> mailing list.
>>
>> Cheers,
>> David
>>
>> On 9/11/2017 10:35 PM, Jaikiran Pai wrote:
>>> I would like to contribute a patch, containing a potential fix and a 
>>> test case, to the issue reported at 
>>> https://bugs.openjdk.java.net/browse/JDK-8190917. This is going to 
>>> be my first contribution to OpenJDK, so I would need some 
>>> guidance/help in having this reviewed/merged, please.
>>>
>>> To give a quick overview of this specific bug - the issue relates to 
>>> SSL session resumption which is no longer functional in Java 9 for 
>>> SSL protocols other than TLSv1.2. The JIRA itself has more extensive 
>>> details and a test case which reproduces the issue.
>>>
>>> So far, I have followed various documentation to setup and build 
>>> OpenJDK jdk9 locally. I use a Mac and at this point, I have 
>>> completed the following set of basic tasks:
>>>
>>> ???? - Checked out the mercurial repo (the complete forest) for jdk9 
>>> (hg tclone http://hg.openjdk.java.net/jdk9/jdk9)
>>> ???? - Built the JDK locally, following the instructions under 
>>> common/doc/building.md
>>> ???? - Run some of the basic tests successfully
>>>
>>> I have a potential fix ready and am in the process of writing a 
>>> jtreg test for this change. I am going to sign and submit the Oracle 
>>> Contributor Agreement this week soon (I believe that's needed right?).
>>>
>>> Before sending out the patch for review, I would like to understand 
>>> if there's anything else that I need to do before that. One thing 
>>> that I read in the contribution page[1] is that "Your patch must be 
>>> built and tested on all relevant platforms before submission". For 
>>> me, the only platform that I have access to is going to be my local 
>>> Mac OS. When I submit the patch, am I expected to test the changes 
>>> on other *nix and Windows OS too?
>>>
>>> If there's anything else that I left out, please feel free to let me 
>>> know or point me to the doc.
>>>
>>> [1] http://openjdk.java.net/contribute/
>>>
>>> P.S: I hope this is the right mailing list. I read the "how to 
>>> contribute" page and then guessed this is the correct mailing list, 
>>> but I'm not sure since I don't see any similar contributions 
>>> requests in the archive of this mailing list, this past year.
>>>
>>> -Jaikiran
>>>
>>>
>


From aph at redhat.com  Wed Nov 15 16:18:22 2017
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Nov 2017 16:18:22 +0000
Subject: Running and building with NetBeans: a plea for help
Message-ID: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>


I've been trying to get the netbeans project at
jdk/make/jdk/netbeans/jdk working.  It all builds, but I can't get
tests to run.

Current output is:

ant -f /scratch/jdk/make/jdk/netbeans/j2se jtreg
/scratch/jdk/make/jdk/netbeans/common/shared.xml:266: No tests selected

I don't know what to do, and I've been puzzling for days.  If anyone
here uses netbeans and jtreg, please send me your build.properties (or
any other information) so I can try to figure out what I'm doing
wrong.  Thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From jan.lahoda at oracle.com  Wed Nov 15 17:40:22 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 15 Nov 2017 18:40:22 +0100
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
Message-ID: <5A0C7C06.9040108@oracle.com>

Hi Andrew,

Just for information, there's also:
https://bitbucket.org/jlahoda/nb-jdk-project

It does not currently support running all tests (although that's the 
longer-term goal; I personally use a jtreg script), but allows to run 
and debug a single test (Test File (Ctrl-F6), Debug Test File 
(Ctrl-Shift-F6)).

Jan

On 15.11.2017 17:18, Andrew Haley wrote:
>
> I've been trying to get the netbeans project at
> jdk/make/jdk/netbeans/jdk working.  It all builds, but I can't get
> tests to run.
>
> Current output is:
>
> ant -f /scratch/jdk/make/jdk/netbeans/j2se jtreg
> /scratch/jdk/make/jdk/netbeans/common/shared.xml:266: No tests selected
>
> I don't know what to do, and I've been puzzling for days.  If anyone
> here uses netbeans and jtreg, please send me your build.properties (or
> any other information) so I can try to figure out what I'm doing
> wrong.  Thanks.
>

From aph at redhat.com  Wed Nov 15 17:43:12 2017
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Nov 2017 17:43:12 +0000
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <5A0C7C06.9040108@oracle.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
 <5A0C7C06.9040108@oracle.com>
Message-ID: <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>

On 15/11/17 17:40, Jan Lahoda wrote:
> Hi Andrew,
> 
> Just for information, there's also:
> https://bitbucket.org/jlahoda/nb-jdk-project

I did try, but the link
http://lahoda.info/hudson/job/nb-jdk-project/lastSuccessfulBuild/artifact/build/updates/updates.xml
is dead.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From jan.lahoda at oracle.com  Wed Nov 15 17:47:59 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 15 Nov 2017 18:47:59 +0100
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
 <5A0C7C06.9040108@oracle.com>
 <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>
Message-ID: <5A0C7DCF.8070304@oracle.com>

Huh. Should hopefully be better now.

Jan

On 15.11.2017 18:43, Andrew Haley wrote:
> On 15/11/17 17:40, Jan Lahoda wrote:
>> Hi Andrew,
>>
>> Just for information, there's also:
>> https://bitbucket.org/jlahoda/nb-jdk-project
>
> I did try, but the link
> http://lahoda.info/hudson/job/nb-jdk-project/lastSuccessfulBuild/artifact/build/updates/updates.xml
> is dead.
>

From aph at redhat.com  Wed Nov 15 17:59:52 2017
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Nov 2017 17:59:52 +0000
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <5A0C7DCF.8070304@oracle.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
 <5A0C7C06.9040108@oracle.com>
 <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>
 <5A0C7DCF.8070304@oracle.com>
Message-ID: <9230ad4b-5885-e56c-3a4d-fec1d9ff9a8a@redhat.com>

On 15/11/17 17:47, Jan Lahoda wrote:
> Huh. Should hopefully be better now.

I'm sorry, I'm feeling very stupid.  I installed the projects, but I have
no idea what to do next.  Is there any information about how I should
build and test the core libraries?  Thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From jan.lahoda at oracle.com  Wed Nov 15 18:26:29 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 15 Nov 2017 19:26:29 +0100
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <9230ad4b-5885-e56c-3a4d-fec1d9ff9a8a@redhat.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
 <5A0C7C06.9040108@oracle.com>
 <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>
 <5A0C7DCF.8070304@oracle.com>
 <9230ad4b-5885-e56c-3a4d-fec1d9ff9a8a@redhat.com>
Message-ID: <5A0C86D5.2070407@oracle.com>

I admit the description is very concise. It should be possible to open 
modules as project, e.g. File/Open Project, select 
${jdkhome}/src/java.base - that should open the java.base module 
(ideally the "configure" has already been run). Tests from test/jdk are 
under the java.base project in the UI (test/langtools tests are placed 
under java.compiler project in the UI). Building should work using Build 
(/Clean and Build) actions (from Run menu) - these should run the make 
to do the build.

For tests, unfortunately currently only a single test can be 
run/debugged, after opening it (I usually use the Navigate/Go to File... 
dialog to find it, but it should be possible to browse to it in the 
Projects, or use File/Open File...)

Jan

On 15.11.2017 18:59, Andrew Haley wrote:
> On 15/11/17 17:47, Jan Lahoda wrote:
>> Huh. Should hopefully be better now.
>
> I'm sorry, I'm feeling very stupid.  I installed the projects, but I have
> no idea what to do next.  Is there any information about how I should
> build and test the core libraries?  Thanks.
>

From aph at redhat.com  Wed Nov 15 19:06:59 2017
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Nov 2017 19:06:59 +0000
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <5A0C86D5.2070407@oracle.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
 <5A0C7C06.9040108@oracle.com>
 <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>
 <5A0C7DCF.8070304@oracle.com>
 <9230ad4b-5885-e56c-3a4d-fec1d9ff9a8a@redhat.com>
 <5A0C86D5.2070407@oracle.com>
Message-ID: <04d17d8f-efad-aa1b-aa1a-5c17a0a35d6a@redhat.com>

On 15/11/17 18:26, Jan Lahoda wrote:
> I admit the description is very concise. It should be possible to open 
> modules as project, e.g. File/Open Project, select 
> ${jdkhome}/src/java.base - that should open the java.base module 
> (ideally the "configure" has already been run). Tests from test/jdk are 
> under the java.base project in the UI (test/langtools tests are placed 
> under java.compiler project in the UI). Building should work using Build 
> (/Clean and Build) actions (from Run menu) - these should run the make 
> to do the build.
> 
> For tests, unfortunately currently only a single test can be 
> run/debugged, after opening it (I usually use the Navigate/Go to File... 
> dialog to find it, but it should be possible to browse to it in the 
> Projects, or use File/Open File...)

And I have run my first test.  Thank you, thank you, thank you.
I have been crying with frustration for the past couple of
days trying to figure out how the netbeans projects are supposed
to work.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From bradford.wetmore at oracle.com  Wed Nov 15 23:54:45 2017
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 15 Nov 2017 15:54:45 -0800
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <04d17d8f-efad-aa1b-aa1a-5c17a0a35d6a@redhat.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
 <5A0C7C06.9040108@oracle.com>
 <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>
 <5A0C7DCF.8070304@oracle.com>
 <9230ad4b-5885-e56c-3a4d-fec1d9ff9a8a@redhat.com>
 <5A0C86D5.2070407@oracle.com>
 <04d17d8f-efad-aa1b-aa1a-5c17a0a35d6a@redhat.com>
Message-ID: <abc5ca39-a12a-ddab-e487-479d1e496d79@oracle.com>

Andrew,

Just a reminder of a previous discussion in jdk10-dev:

     http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/000291.html

I haven't run a JDK 10 build in the last few weeks, but expect it should 
be the mostly the same.

Hope this helps.

Brad


On 11/15/2017 11:06 AM, Andrew Haley wrote:
> On 15/11/17 18:26, Jan Lahoda wrote:
>> I admit the description is very concise. It should be possible to open
>> modules as project, e.g. File/Open Project, select
>> ${jdkhome}/src/java.base - that should open the java.base module
>> (ideally the "configure" has already been run). Tests from test/jdk are
>> under the java.base project in the UI (test/langtools tests are placed
>> under java.compiler project in the UI). Building should work using Build
>> (/Clean and Build) actions (from Run menu) - these should run the make
>> to do the build.
>>
>> For tests, unfortunately currently only a single test can be
>> run/debugged, after opening it (I usually use the Navigate/Go to File...
>> dialog to find it, but it should be possible to browse to it in the
>> Projects, or use File/Open File...)
> 
> And I have run my first test.  Thank you, thank you, thank you.
> I have been crying with frustration for the past couple of
> days trying to figure out how the netbeans projects are supposed
> to work.
> 

From aph at redhat.com  Thu Nov 16 12:19:33 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 16 Nov 2017 12:19:33 +0000
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <5A0C86D5.2070407@oracle.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
 <5A0C7C06.9040108@oracle.com>
 <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>
 <5A0C7DCF.8070304@oracle.com>
 <9230ad4b-5885-e56c-3a4d-fec1d9ff9a8a@redhat.com>
 <5A0C86D5.2070407@oracle.com>
Message-ID: <abfed503-16fd-6539-8933-e7556f8001d8@redhat.com>

So, I'm now every close, but...

I'm trying to debug jdk.vm.ci.common.JVMCIError.  But the source code
for that file, while it is built as part of OpenJDK, does not appear
anywhere in the source files for the NetBeans project.  Do you know
how to add the jdk.vm.etc files?  Thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From bradford.wetmore at oracle.com  Thu Nov 16 23:29:49 2017
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 16 Nov 2017 15:29:49 -0800
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <abfed503-16fd-6539-8933-e7556f8001d8@redhat.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
 <5A0C7C06.9040108@oracle.com>
 <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>
 <5A0C7DCF.8070304@oracle.com>
 <9230ad4b-5885-e56c-3a4d-fec1d9ff9a8a@redhat.com>
 <5A0C86D5.2070407@oracle.com>
 <abfed503-16fd-6539-8933-e7556f8001d8@redhat.com>
Message-ID: <e0ca38b8-1273-b955-c62e-8f021a2206b6@oracle.com>

If you are using Jan's OpenJDK Project plugin using JDK 9, then I 
believe you just open the following projects/modules:

     jdk.internal.vm.ci
     java.base   (dependency)

Then open your test project/jtreg case, and away you go.

Brad



On 11/16/2017 4:19 AM, Andrew Haley wrote:
> So, I'm now every close, but...
> 
> I'm trying to debug jdk.vm.ci.common.JVMCIError.  But the source code
> for that file, while it is built as part of OpenJDK, does not appear
> anywhere in the source files for the NetBeans project.  Do you know
> how to add the jdk.vm.etc files?  Thanks.
> 

From jan.lahoda at oracle.com  Mon Nov 20 20:29:24 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 20 Nov 2017 21:29:24 +0100
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <e0ca38b8-1273-b955-c62e-8f021a2206b6@oracle.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
 <5A0C7C06.9040108@oracle.com>
 <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>
 <5A0C7DCF.8070304@oracle.com>
 <9230ad4b-5885-e56c-3a4d-fec1d9ff9a8a@redhat.com>
 <5A0C86D5.2070407@oracle.com>
 <abfed503-16fd-6539-8933-e7556f8001d8@redhat.com>
 <e0ca38b8-1273-b955-c62e-8f021a2206b6@oracle.com>
Message-ID: <5A133B24.90808@oracle.com>

Hi,

As Brad mentioned, to get types from a specific project, it should 
usually be enough to open that project. For jdk.internal.vm.ci (and a 
few other modules), there may be more trouble, as their sources have 
sub-modules in them (so the sources are not in a package hierarchy 
starting from share/classes). That may need some more tweaking.

Jan

On 17.11.2017 00:29, Bradford Wetmore wrote:
> If you are using Jan's OpenJDK Project plugin using JDK 9, then I
> believe you just open the following projects/modules:
>
>      jdk.internal.vm.ci
>      java.base   (dependency)
>
> Then open your test project/jtreg case, and away you go.
>
> Brad
>
>
>
> On 11/16/2017 4:19 AM, Andrew Haley wrote:
>> So, I'm now every close, but...
>>
>> I'm trying to debug jdk.vm.ci.common.JVMCIError.  But the source code
>> for that file, while it is built as part of OpenJDK, does not appear
>> anywhere in the source files for the NetBeans project.  Do you know
>> how to add the jdk.vm.etc files?  Thanks.
>>

From aph at redhat.com  Wed Nov 22 13:58:35 2017
From: aph at redhat.com (Andrew Haley)
Date: Wed, 22 Nov 2017 13:58:35 +0000
Subject: Running and building with NetBeans: a plea for help
In-Reply-To: <5A133B24.90808@oracle.com>
References: <edfe7636-5ccb-b8f9-05a4-1042f464426f@redhat.com>
 <5A0C7C06.9040108@oracle.com>
 <5aac2fb1-db61-df0a-b382-c32f4f30a02a@redhat.com>
 <5A0C7DCF.8070304@oracle.com>
 <9230ad4b-5885-e56c-3a4d-fec1d9ff9a8a@redhat.com>
 <5A0C86D5.2070407@oracle.com>
 <abfed503-16fd-6539-8933-e7556f8001d8@redhat.com>
 <e0ca38b8-1273-b955-c62e-8f021a2206b6@oracle.com> <5A133B24.90808@oracle.com>
Message-ID: <ae839c31-0cfb-721a-0d43-221652ff1250@redhat.com>

On 20/11/17 20:29, Jan Lahoda wrote:
> As Brad mentioned, to get types from a specific project, it should 
> usually be enough to open that project. For jdk.internal.vm.ci (and a 
> few other modules), there may be more trouble, as their sources have 
> sub-modules in them (so the sources are not in a package hierarchy 
> starting from share/classes). That may need some more tweaking.

Yeah.  That seems to be the problem: there is no way to open the
jdk.internal.vm classes as a project.  They don't even appear in the
dialog as something that you can open.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From sadhak001 at gmail.com  Wed Nov 29 11:48:31 2017
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Wed, 29 Nov 2017 11:48:31 +0000
Subject: javapackager feedback and questions
Message-ID: <CAGHtMWm0osJjZuWnYwLd2w1RMPiYQ5n1Q6tyFgfANXmQcKOEYQ@mail.gmail.com>

Hi all,

First I hope I'm writing to the correct mailing list, if not please suggest
where to write instead. Also if it is worth writing back as separate
messages per issue or item, please do let me know.

Some of my observations and feedback when using *javapackager*:

*Positives*
- .dmg and .msi packaging work very well out of the box, easy to put
together configuration settings
- .rpm packages build very quickly
- a number of features from FPM (docs
<https://fpm.readthedocs.io/en/latest/> | GitHub
<https://github.com/jordansissel/fpm>) available but some more for the
individual types of packages would certainly help (for e.g. exposing some
more of the CLI flags for DEB and RPM packaging)

*Improvements*
- [doc and example required]: Additional documentation and examples around
how to add a license when building a package would be helpful. After a bit
of searching on google and experimenting with couple of combinations of CLI
options I was able to figure it out.
- [doc correction]: jvmUserArg is referred to in the documentation with
examples, while in the usage documentation jvmOptions is used (discrepancy
between the names of flags), see
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
 and
https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585
- [doc correction]: same goes for mac.signing-key-user-name while there is
no mention of it in the javapackager usage documentation, it takes the full
name of the user i.e. *Jane Doe*
*- *[doc and example required]: just adding
mac.signing-key-developer-id-app=xxxxx isn't enough, needs the other
code-sign related flags as well, possibly key should be in the Mac KeyStore
when building it (check if id provided is the correct one, additional
examples would definitely help to reduce or eliminate experimentation and
assumptions)
- [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
building on the MacOSX in non-gui mode, can be overridden by using the
-Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
systemWide=true does not help, still ends up building a .dmg package with
just the app in it (no icon, no background)
- code signing examples for Windows and MacOSX will certainly help quite a
bit
- [doc and example required] .deb packages take a long time to build, some
additional flags that can help. Some findings along the lines on how to
speed up dpkg-build:

export CCACHE_DIR=/home/$USER/.ccache

export CCACHE_HASHDIR=$CCACHE_DIR

export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS} --preserve-envvar=CCACHE_DIR
--prepend-path=/usr/lib/ccache parallel=jobs"

echo "Debian build options: ${DEB_BUILD_OPTIONS}"

-------------------------------

A response with answers for the above will be highly appreciated.

Thanks.

Cheers,
Mani
-- 

@theNeomatrix369 <http://twitter.com/theNeomatrix369>  |  Blog
<http://neomatrix369.wordpress.com/>  |  @adoptopenjdk | Dev communities

Meet-a-Project - MutabilityDetector <https://github.com/MutabilityDetector>
 |  Github <https://github.com/neomatrix369>  | Slideshare
<https://www.slideshare.net/neomatrix369>  | LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>

Come to Devoxx UK 2018: http://www.devoxx.co.uk/

Don't chase success, rather aim for "Excellence", and success will come
chasing after you!

From kanth909 at gmail.com  Thu Nov 30 08:17:57 2017
From: kanth909 at gmail.com (kant kodali)
Date: Thu, 30 Nov 2017 00:17:57 -0800
Subject: Random Idea
Message-ID: <CA+iiNx8qd95xDb3fWwHhsgcj+QX=YLsSJxdNfBit34-hdx1w1w@mail.gmail.com>

Hi All,

I am wondering if we can come up with a JDK framework proposal so people
can write smart contracts on JVM ? I tend to think that this can elevate
JVM even further and stay more cutting edge therefore Roughly speaking, the
framework should limit to the subset of Java language such that it would
allow for deterministic execution.

Thanks,
kant

From sadhak001 at gmail.com  Thu Nov 30 10:49:13 2017
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Thu, 30 Nov 2017 10:49:13 +0000
Subject: javapackager feedback and questions
In-Reply-To: <FF7D3BCD-19D1-4CFA-B222-32CA32F00ADE@gmail.com>
References: <CAGHtMWm0osJjZuWnYwLd2w1RMPiYQ5n1Q6tyFgfANXmQcKOEYQ@mail.gmail.com>
 <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com>
 <FF7D3BCD-19D1-4CFA-B222-32CA32F00ADE@gmail.com>
Message-ID: <CAGHtMWnyOj415k31RQ3K=r6aozdr85GZmXo+GjgWpHtcgx4YKg@mail.gmail.com>

Thanks Victor for you response and invite. I'll get back with details for
your query.

Just for your info, I was referring to javapackager in the context of Java
9 built artifacts.

On Thu, 30 Nov 2017 09:28 Michael Hall, <mik3hall at gmail.com> wrote:

>
> > On Nov 29, 2017, at 5:18 PM, victor.drozdov at oracle.com wrote:
> >
> > Hi, Mani.
> >
> > Thanks for providing the feedback!
> > We will consider adding more examples and more details in the docs as
> you proposed(there is an arg named jvmOptions but that's not mentioned in
> the table).
> > Looks like there is a bug when you specify systemWide=true on the MacOSX
> in non-gui mode. Can you provide more details about that (like full cmd
> line)?
> > Actually, if you want you can clone the repo:
> > http://hg.openjdk.java.net/openjfx/10-dev/rt/
> > (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> > and help to improve javapackager. Or you can just create Enhancements
> for deploy/packager, as it's not always clear what users expect.
> >
>
> Why was JEP 311 [1] Closed/Withdrawn?
>
> [1] http://openjdk.java.net/jeps/311
>
> --

@theNeomatrix369 <http://twitter.com/theNeomatrix369>  |  Blog
<http://neomatrix369.wordpress.com/>  |  @adoptopenjdk | Dev communities

Meet-a-Project - MutabilityDetector <https://github.com/MutabilityDetector>
 |  Github <https://github.com/neomatrix369>  | Slideshare
<https://www.slideshare.net/neomatrix369>  | LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>

Come to Devoxx UK 2018: http://www.devoxx.co.uk/

Don't chase success, rather aim for "Excellence", and success will come
chasing after you!

From martijnverburg at gmail.com  Thu Nov 30 18:43:57 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 30 Nov 2017 18:43:57 +0000
Subject: Random Idea
In-Reply-To: <CA+iiNx8qd95xDb3fWwHhsgcj+QX=YLsSJxdNfBit34-hdx1w1w@mail.gmail.com>
References: <CA+iiNx8qd95xDb3fWwHhsgcj+QX=YLsSJxdNfBit34-hdx1w1w@mail.gmail.com>
Message-ID: <CAP7YuARrirpj43Q+=7RwsMcDh=a0n6YzDtuVgROeoaxAVFunAg@mail.gmail.com>

Hi Kant,

This probably isn't the right mailing list to discuss this, but jClarity
was involved in creating a deterministic JVM for R3.  I'll ping you off
list.

Cheers,
Martijn

On 30 November 2017 at 08:17, kant kodali <kanth909 at gmail.com> wrote:

> Hi All,
>
> I am wondering if we can come up with a JDK framework proposal so people
> can write smart contracts on JVM ? I tend to think that this can elevate
> JVM even further and stay more cutting edge therefore Roughly speaking, the
> framework should limit to the subset of Java language such that it would
> allow for deterministic execution.
>
> Thanks,
> kant
>

From martijnverburg at gmail.com  Thu Nov 30 18:57:03 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 30 Nov 2017 18:57:03 +0000
Subject: javapackager feedback and questions
In-Reply-To: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com>
References: <CAGHtMWm0osJjZuWnYwLd2w1RMPiYQ5n1Q6tyFgfANXmQcKOEYQ@mail.gmail.com>
 <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com>
Message-ID: <CAP7YuAT19RCbCfnRGzW_yhtfzTmeUH837YM929bJwFNB0mJK7w@mail.gmail.com>

Hi Victor,

I can answer the last Q.  It's for two products, one is Censum our GC Log
analyser (Java swing desktop app, yes they still exist! ;p) and the second
is a stand alone Java 'daemon' for our APM SaaS tool (illuminate).

jlink and javapackager is a powerful combination for us, so thanks for
these tools!

Cheers,
Martijn

On 29 November 2017 at 23:18, <victor.drozdov at oracle.com> wrote:

> Hi, Mani.
>
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as you
> proposed(there is an arg named jvmOptions but that's not mentioned in the
> table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX
> in non-gui mode. Can you provide more details about that (like full cmd
> line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements for
> deploy/packager, as it's not always clear what users expect.
>
> By the way, what kind of apps you distribute using javapackager? Is that a
> UI app or services?
>
> --Victor
>
>
>
> On 11/29/17 3:48 AM, Mani Sarkar wrote:
>
>> Hi all,
>>
>> First I hope I'm writing to the correct mailing list, if not please
>> suggest
>> where to write instead. Also if it is worth writing back as separate
>> messages per issue or item, please do let me know.
>>
>> Some of my observations and feedback when using *javapackager*:
>>
>> *Positives*
>> - .dmg and .msi packaging work very well out of the box, easy to put
>> together configuration settings
>> - .rpm packages build very quickly
>> - a number of features from FPM (docs
>> <https://fpm.readthedocs.io/en/latest/> | GitHub
>> <https://github.com/jordansissel/fpm>) available but some more for the
>> individual types of packages would certainly help (for e.g. exposing some
>> more of the CLI flags for DEB and RPM packaging)
>>
>> *Improvements*
>> - [doc and example required]: Additional documentation and examples around
>> how to add a license when building a package would be helpful. After a bit
>> of searching on google and experimenting with couple of combinations of
>> CLI
>> options I was able to figure it out.
>> - [doc correction]: jvmUserArg is referred to in the documentation with
>> examples, while in the usage documentation jvmOptions is used (discrepancy
>> between the names of flags), see
>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/
>> javapackager.html
>>   and
>> https://docs.oracle.com/javase/9/deploy/self-contained-
>> application-packaging.htm#JSDPG585
>> - [doc correction]: same goes for mac.signing-key-user-name while there is
>> no mention of it in the javapackager usage documentation, it takes the
>> full
>> name of the user i.e. *Jane Doe*
>> *- *[doc and example required]: just adding
>> mac.signing-key-developer-id-app=xxxxx isn't enough, needs the other
>> code-sign related flags as well, possibly key should be in the Mac
>> KeyStore
>> when building it (check if id provided is the correct one, additional
>> examples would definitely help to reduce or eliminate experimentation and
>> assumptions)
>> - [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
>> building on the MacOSX in non-gui mode, can be overridden by using the
>> -Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
>> creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
>> systemWide=true does not help, still ends up building a .dmg package with
>> just the app in it (no icon, no background)
>> - code signing examples for Windows and MacOSX will certainly help quite a
>> bit
>> - [doc and example required] .deb packages take a long time to build, some
>> additional flags that can help. Some findings along the lines on how to
>> speed up dpkg-build:
>>
>> export CCACHE_DIR=/home/$USER/.ccache
>>
>> export CCACHE_HASHDIR=$CCACHE_DIR
>>
>> export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS}
>> --preserve-envvar=CCACHE_DIR
>> --prepend-path=/usr/lib/ccache parallel=jobs"
>>
>> echo "Debian build options: ${DEB_BUILD_OPTIONS}"
>>
>> -------------------------------
>>
>> A response with answers for the above will be highly appreciated.
>>
>> Thanks.
>>
>> Cheers,
>> Mani
>>
>
>

From mik3hall at gmail.com  Thu Nov 30 09:28:43 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 30 Nov 2017 03:28:43 -0600
Subject: javapackager feedback and questions
In-Reply-To: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com>
References: <CAGHtMWm0osJjZuWnYwLd2w1RMPiYQ5n1Q6tyFgfANXmQcKOEYQ@mail.gmail.com>
 <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com>
Message-ID: <FF7D3BCD-19D1-4CFA-B222-32CA32F00ADE@gmail.com>


> On Nov 29, 2017, at 5:18 PM, victor.drozdov at oracle.com wrote:
> 
> Hi, Mani.
> 
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as you proposed(there is an arg named jvmOptions but that's not mentioned in the table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX in non-gui mode. Can you provide more details about that (like full cmd line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements for deploy/packager, as it's not always clear what users expect.
> 

Why was JEP 311 [1] Closed/Withdrawn?

[1] http://openjdk.java.net/jeps/311