Fwd: JDK 18 General Availability, and oracle-actions/setup-java

2022-03-28 Thread Craig Russell
Someone who knows how and what to do could look into this and we can discuss at 
our regular meeting...

Regards,
Craig

> Begin forwarded message:
> 
> From: David Delabassee 
> Subject: JDK 18 General Availability, and oracle-actions/setup-java
> Date: March 28, 2022 at 3:25:09 AM PDT
> To: bui...@apache.org
> Reply-To: bui...@apache.org
> Reply-To: david.delabas...@oracle.com
> 
> Greetings!
> 
> JDK 18 has been released (General Availability) on March 22nd as planned, the 
> release cadence is working like clockwork! As a small token of gratitude, 
> some of you have been specifically acknowledged in the "The Arrival of Java 
> 18" announcement [1]. On behalf of the entire team, let me extend our thanks 
> to all of you.
> 
> With JDK 18 released, the focus should now be on making sure your project(s) 
> compile and work on JDK 19. As always, if you face any issue with 
> early-access builds of JDK 19 please let us know. To help you in this task, 
> we have just released a GitHub action to install the OpenJDK Early-Access 
> builds. For more information, please check the heads-up below.
> 
> I'll conclude with a short teaser, i.e. JavaOne is Back! [2] Stay tuned for 
> more details.
> 
> [1] https://inside.java/2022/03/22/the-arrival-of-java18/
> [2] https://www.oracle.com/cloudworld/javaone/
> 
> 
> ## Heads-Up: oracle-actions/setup-java
> 
> To help you test your project(s), we have released a GitHub Action [3] to 
> download and install various JDK builds produced by Oracle. In addition to 
> the latest OpenJDK GA builds (GPL v2 W/CPE) and the Oracle JDK builds (NFTC 
> license), this action can also download and install OpenJDK early-access 
> builds, and early-access builds of OpenJDK projects (ex. Project Loom, 
> Project Valhalla, etc.).
> 
> When doing tests using EA builds, it is key to always use the upstream EA 
> builds from jdk.java.net as issues should be logged against those upstream 
> builds, and ideally against a specific build version. This GitHub action is 
> actively following the OpenJDK EA builds releases. Please make sure to check 
> the announcement [4] for more details, and short FAQ.
> 
> To help you isolate regression between different EA builds, we are working to 
> add support for archived builds. If you have feedback, please either issue 
> the Issue tracker [5] or just send me a mail.
> 
> [3] 
> https://github.com/marketplace/actions/setup-java-development-kits-built-by-oracle
> [4] https://inside.java/2022/03/11/setup-java/
> [5] https://github.com/oracle-actions/setup-java/issues
> 
> 
> ## General Availability of Java 18 / JDK 18
> 
> JDK 18 is now Generally Available [6]. The OpenJDK builds which are provided 
> under the GNU General Public License v2, with the Classpath Exception are 
> available [7], the JDK 18 Release Notes are also available [8].
> 
> [6] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-March/006458.html
> [7] https://jdk.java.net/18/
> [8] https://jdk.java.net/18/release-notes
> 
> Along with hundreds of smaller enhancements and over a thousand bug fixes, 
> JDK 18 includes following JEPs:
> - JEP 400: UTF-8 by Default
> - JEP 408: Simple Web Server
> - JEP 413: Code Snippets in Java API Documentation
> - JEP 416: Reimplement Core Reflection with Method Handles
> - JEP 417: Vector API (Third Incubator)
> - JEP 418: Internet-Address Resolution SPI
> - JEP 419: Foreign Function & Memory API (Second Incubator)
> - JEP 420: Pattern Matching for switch (Second Preview)
> - JEP 421: Deprecate Finalization for Removal
> 
> Thanks to everyone who contributed to JDK 18, whether by designing and 
> implementing features or enhancements, by fixing bugs, or by downloading and 
> testing the early-access builds.
> 
> 
> ## JDK 19 Early-Access builds
> 
> JDK 19 Early-Access builds 15 are now available [9], and are provided under 
> the GNU General Public License v2, with the Classpath Exception. The Release 
> Notes are also available [10].
> 
> [9] https://jdk.java.net/19/
> [10] https://jdk.java.net/19/release-notes
> 
> ### JEPs targeted to JDK 19, so far:
> - JEP 422: Linux/RISC-V Port https://openjdk.java.net/jeps/422
> 
> ### Recent changes that maybe of interest:
> - JDK-8283415: Update java.lang.ref to use sealed classes
> - JDK-8280494: (D)TLS signature schemes
> - JDK-8282081: java.time.DateTimeFormatter: wrong definition of symbol F
> - JDK-8281181: Do not use CPU Shares to compute active processor count
> - JDK-7192189: Support endpoint identification algorithm in RFC 6125
> - JDK-8277474: jarsigner does not check if algorithm parameters are disabled
> - JDK-8280357: If the users home directory is invalid, system property 
> user.home is set to $HOME
> - JDK-8277204: Implement PAC-RET branch protection on Linux/AArch64
> - JDK-8282411: Add useful predicates to ElementKind
> - JDK-8282131: java.time.ZoneId should be a sealed abstract class
> - JDK-8281375: Accelerate bitCount operation for AVX2 and AVX512 target
> 
> 
> ## Topics of 

[jira] [Commented] (JDO-806) Use apache URL for schemaLocation of JDO XSDs

2022-03-28 Thread Andy Jefferson (Jira)


[ 
https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17513216#comment-17513216
 ] 

Andy Jefferson commented on JDO-806:


Just a question why we (currently) have XSD XMLNS for a jdo XML file as

{{http://xmlns.jcp.org/xml/ns/jdo/jdo"}}
{{     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}}
{{     xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/jdo 
https://db.apache.org/jdo/xmlns/jdo_3_2.xsd; version="3.2">}}

and not

{{https://db.apache.org/jdo/xmlns/jdo"}}
{{     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}}
{{     xsi:schemaLocation="https://db.apache.org/jdo/xmlns/jdo 
https://db.apache.org/jdo/xmlns/jdo_3_2.xsd; version="3.2">}}

 

It seemingly makes no difference to XML validation in an IDE (e.g Eclipse), but 
why burden the user with having to think where to put xmlns.jcp.org (that this 
API doesn't use, nor is maintained) and where to put db.apache.org ?

 

For reference, Jakarta Persistence uses jakarta.ee for XMLNS as well as 
xsi:schemaLocation

> Use apache URL for schemaLocation of JDO XSDs
> -
>
> Key: JDO-806
> URL: https://issues.apache.org/jira/browse/JDO-806
> Project: JDO
>  Issue Type: Improvement
>  Components: api
>Affects Versions: JDO 3.2
>Reporter: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.3
>
>
> In JDO 3.2 the schemaLocation of JDO XSDs link to 
> [http://xmlns.jcp.org/xml/ns/jdo/] where  is one of jdo_3_2.xsd, 
> jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site 
> [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that 
> the 3.2 XSDs are available under this URL (see JDO-744).
> One idea ist might be to switch to an Apache URL, where we can control the 
> download sites.
> This change requires corresponding changes to the specification, api, and 
> tck. Here is a proposed plan to implement:
>  # Update the xsds and dtds in the api/resources to change the headers.
>  # Update the xsds and dtds in the db.apache.org/jdo/xmlns with the changes.
>  # Update the xsds and dtds in the tck with the changes. This step will fail 
> without a corresponding change to the reference implementation.
>  # Update the specification with the changes. A partial list of affected 
> sections:
>  ## 11.1.4 p. 122
>  ## 18.24 p. 261
>  ## 18.25 p. 265
>  ## 18.26 p. 287, 298
>  ## New C.23 Changes since 3.2 p. 404
> Open question: should we keep the version number of the xsd and dtd files as 
> 3.2 even though the api, tck, and specification will be updated to 3.2.1? I 
> would say yes, and only change the version number of the files if there is a 
> change to the content of the xsd and/or dtd.
> My proposal is: the 3.2.1 version of JDO would still refer to the 3.2 version 
> of the xsd and dtd.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)