OpenJDK 15 EA build 24 is now available
by Rory O'Donnell
Hi David & Richard,
OpenJDK 15 EA build 24 is now available at http://jdk.java.net/15 *
*
* These early-access , open-source builds are provided under the
o GNU General Public License, version 2, with the Classpath
Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
* Features
o Proposed to target JDK 15
+ JEP 383 <https://openjdk.java.net/jeps/383> Foreign-Memory
Access API (Second Incubator)
o Targeted to JDK 15
+ JEP 360 <http://openjdk.java.net/jeps/360> Sealed Classes
(Preview)
+ JEP 379 <https://openjdk.java.net/jeps/379> Shenandoah: A
Low-Pause-Time Garbage Collector (Production)
o Integrated in JDK 15
+ JEP 339 <http://openjdk.java.net/jeps/339> Edwards-Curve
Digital Signature Algorithm (EdDSA)
+ JEP 371 <http://openjdk.java.net/jeps/371> Hidden Classes
+ JEP 372 <http://openjdk.java.net/jeps/372> Remove the
Nashorn JavaScript Engine
+ *JEP 373 <https://openjdk.java.net/jeps/373>**Reimplement
the Legacy DatagramSocket API*
+ JEP 374 <http://openjdk.java.net/jeps/374> Disable and
Deprecate Biased Locking
+ JEP 375 <https://openjdk.java.net/jeps/375> Pattern Matching
for instanceof (Second Preview)
+ JEP 377 <http://openjdk.java.net/jeps/377> ZGC: A Scalable
Low-Latency Garbage Collector
+ JEP 378 <http://openjdk.java.net/jeps/378> Text Blocks
+ JEP 381 <https://openjdk.java.net/jeps/381> Remove the
Solaris and SPARC Ports
+ JEP 384 <https://openjdk.java.net/jeps/384> Records (Second
Preview)
* Changes in recent builds that maybe of interest:
o build 24
+ *JEP 373 <https://openjdk.java.net/jeps/373>**Reimplement
the Legacy DatagramSocket API *(JDK-8241072
<https://bugs.openjdk.java.net/browse/JDK-8241072>)
+ *JEP 374 <http://openjdk.java.net/jeps/374> *Disable and
Deprecate Biased Locking (JDK-8231264
<https://bugs.openjdk.java.net/browse/JDK-8231264>)
+ Support for Unicode 13.0**(JDK-8239383
<https://bugs.openjdk.java.net/browse/JDK-8239383>)
+ Incorrect Man pages of Javadocs tool (JDK-8238697
<https://bugs.openjdk.java.net/browse/JDK-8238697>)
# reported by Apache Lucene
+ 32-bit builds are broken after JDK-8242524 (JDK-8245070
<https://bugs.openjdk.java.net/browse/JDK-8245070>)
# Reported by JaCoCo*
*
o build 23
+ localizedBy() should override localized values with default
values (JDK-8244245
<https://bugs.openjdk.java.net/browse/JDK-8244245>)
+ Add revocation checking to jarsigner (JDK-8242060)
<https://bugs.openjdk.java.net/browse/JDK-8242060>
o build 22
+ Deprecate -XX:ForceNUMA option (JDK-8243628
<https://bugs.openjdk.java.net/browse/JDK-8243628>)
+ Removal of Comodo Root CA Certificate (JDK-8225069
<https://bugs.openjdk.java.net/browse/JDK-8225069>)
+ Removal of DocuSign Root CA Certificate (JDK-8225068
<https://bugs.openjdk.java.net/browse/JDK-8225068>)
* Project Lanai Early-Access Builds - Build 15-lanai+1-101 (2020/5/14)
o These builds are intended for developers looking to test and
provide feedback on using Project Lanai, which implements a new
Java 2D graphics rendering pipeline for macOS.
o These builds are based upon the latest state of the current in
development JDK, and so may contain new features and unresolved
bugs unrelated to Project Lanai.
o These early-access , open-source builds are provided under the
+ GNU General Public License, version 2, with the Classpath
Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
o Please send feedback via e-mail to lanai-dev(a)openjdk.java.net
<mailto:lanai-dev@openjdk.java.net>. To send e-mail to this
address you must first subscribe to the mailing list
<https://mail.openjdk.java.net/mailman/listinfo/lanai-dev>.
* Project Loom Early-Access Builds - Build 15-loom+7-141 (2020/5/11)
o These builds are intended for developers looking to "kick the
tyres" and provide feedback on using the API or by sending bug
reports. Warning: This build is based on an incomplete version
of JDK 15 <http://openjdk.java.net/projects/jdk/15/>.
o These early-access , open-source builds are provided under the
+ GNU General Public License, version 2, with the Classpath
Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
o Please send feedback via e-mail to loom-dev(a)openjdk.java.net
<mailto:loom-dev@openjdk.java.net>. To send e-mail to this
address you must first subscribe to the mailing list
<http://mail.openjdk.java.net/mailman/listinfo/loom-dev>.
*The **Java Crypto Roadmap** has been updated [2]*
Rgds,Rory
[1] http://jdk.java.net/15/release-notes
[2] https://www.java.com/en/jre-jdk-cryptoroadmap.html
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
4 years, 6 months
Possible component upgrades report - Wildfly
by thofman＠redhat.com
Generated at 01:49:33 SGT 2020-05-17
Searched in following repositories:
* Central: https://repo1.maven.org/maven2/
* JBossPublic: https://repository.jboss.org/nexus/content/repositories/public/
Possible upgrades:
com.fasterxml.jackson.core:jackson-annotations:2.10.3 -> 2.10.4 (Central)
com.squareup.okhttp3:okhttp:3.9.0 -> 3.9.1 (Central)
com.sun.activation:jakarta.activation:1.2.1 -> 1.2.2 (Central)
com.sun.istack:istack-commons-runtime:3.0.10 -> 3.0.11 (Central)
com.sun.xml.bind.external:relaxng-datatype:2.3.3-b02 -> 2.3.3 (Central)
com.sun.xml.fastinfoset:FastInfoset:1.2.13 -> 1.2.18 (Central)
io.netty:netty-all:4.1.48.Final -> 4.1.50.Final (Central)
io.opentracing.contrib:opentracing-interceptors:0.0.4 -> 0.0.5 (Central)
io.opentracing.contrib:opentracing-tracerresolver:0.1.5 -> 0.1.8 (Central)
io.reactivex.rxjava2:rxjava:2.2.5 -> 2.2.19 (Central)
io.smallrye:smallrye-health:2.2.0 -> 2.2.1 (Central)
io.smallrye:smallrye-metrics:2.4.0 -> 2.4.2 (Central)
io.undertow.js:undertow-js:1.0.2.Final -> 1.0.3.Final (Central)
joda-time:joda-time:2.9.7 -> 2.9.9 (Central)
net.bytebuddy:byte-buddy:1.9.11 -> 1.9.16 (Central)
org.apache.activemq:activemq-artemis-native:1.0.0 -> 1.0.1 (Central)
org.apache.activemq:artemis-amqp-protocol:2.10.1 -> 2.12.0 (Central)
org.apache.avro:avro:1.7.6 -> 1.7.7 (Central)
org.apache.cxf.xjc-utils:cxf-xjc-runtime:3.3.0 -> 3.3.1 (Central)
org.apache.james:apache-mime4j:0.6 -> 0.6.1 (Central)
org.apache.myfaces.core:myfaces-api:2.3.1 -> 2.3.6 (Central)
org.apache.openjpa:openjpa-kernel:2.4.2 -> 2.4.3 (Central)
org.apache.qpid:proton-j:0.33.2 -> 0.33.4 (Central)
org.apache.santuario:xmlsec:2.1.4 -> 2.1.5 (Central)
org.apache.ws.xmlschema:xmlschema-core:2.2.4 -> 2.2.5 (Central)
org.bouncycastle:bcmail-jdk15on:1.62 -> 1.65 (Central)
org.codehaus.jettison:jettison:1.4.0 -> 1.4.1 (Central)
org.eclipse.microprofile.metrics:microprofile-metrics-api:2.3 -> 2.3.2 (Central)
org.eclipse.microprofile.rest.client:microprofile-rest-client-api:1.4.0 -> 1.4.1 (Central)
org.eclipse.persistence:eclipselink:2.7.3 -> 2.7.7 (Central)
org.hibernate:hibernate-search-backend-jms:5.10.7.Final -> 5.10.9.Final (Central)
org.jboss.activemq.artemis.integration:artemis-wildfly-integration:1.0.2 -> 1.0.2-wildfly-1 (JBossPublic)
org.jboss.arquillian.container:arquillian-container-test-spi:1.4.0.Final -> 1.4.1.Final (Central)
org.jboss.narayana:jbosstxbridge:5.10.1.Final -> 5.10.4.Final (Central)
org.jboss.security:jbossxacml:2.0.8.Final -> 2.0.9.Final (JBossPublic)
org.wildfly.galleon-plugins:wildfly-config-gen:4.2.6.Final -> 4.2.7.Final (Central)
org.wildfly.transaction:wildfly-transaction-client:1.1.11.Final -> 1.1.12.Final (Central)
xalan:serializer:2.7.1.jbossorg-4 -> 2.7.2 (Central)
38 items
Report generated by Maven Dependency Updater
https://github.com/jboss-set/maven-dependency-updater
4 years, 6 months
Possible component upgrades report - Wildfly
by thofman＠redhat.com
Generated at 01:49:34 SGT 2020-05-10
Searched in following repositories:
* Central: https://repo1.maven.org/maven2/
* JBossPublic: https://repository.jboss.org/nexus/content/repositories/public/
Possible upgrades:
com.fasterxml.jackson.core:jackson-annotations:2.10.3 -> 2.10.4 (Central)
com.squareup.okhttp3:okhttp:3.9.0 -> 3.9.1 (Central)
com.sun.activation:jakarta.activation:1.2.1 -> 1.2.2 (Central)
com.sun.istack:istack-commons-runtime:3.0.10 -> 3.0.11 (Central)
com.sun.xml.bind.external:relaxng-datatype:2.3.3-b02 -> 2.3.3 (Central)
com.sun.xml.fastinfoset:FastInfoset:1.2.13 -> 1.2.18 (Central)
io.netty:netty-all:4.1.48.Final -> 4.1.49.Final (Central)
io.opentracing.contrib:opentracing-interceptors:0.0.4 -> 0.0.5 (Central)
io.opentracing.contrib:opentracing-tracerresolver:0.1.5 -> 0.1.8 (Central)
io.reactivex.rxjava2:rxjava:2.2.5 -> 2.2.19 (Central)
io.smallrye:smallrye-health:2.2.0 -> 2.2.1 (Central)
io.smallrye:smallrye-metrics:2.4.0 -> 2.4.1 (Central)
io.undertow.js:undertow-js:1.0.2.Final -> 1.0.3.Final (Central)
joda-time:joda-time:2.9.7 -> 2.9.9 (Central)
net.bytebuddy:byte-buddy:1.9.11 -> 1.9.16 (Central)
org.apache.activemq:activemq-artemis-native:1.0.0 -> 1.0.1 (Central)
org.apache.activemq:artemis-amqp-protocol:2.10.1 -> 2.12.0 (Central)
org.apache.avro:avro:1.7.6 -> 1.7.7 (Central)
org.apache.cxf.xjc-utils:cxf-xjc-runtime:3.3.0 -> 3.3.1 (Central)
org.apache.james:apache-mime4j:0.6 -> 0.6.1 (Central)
org.apache.myfaces.core:myfaces-api:2.3.1 -> 2.3.6 (Central)
org.apache.openjpa:openjpa-kernel:2.4.2 -> 2.4.3 (Central)
org.apache.qpid:proton-j:0.33.2 -> 0.33.4 (Central)
org.apache.santuario:xmlsec:2.1.4 -> 2.1.5 (Central)
org.apache.ws.xmlschema:xmlschema-core:2.2.4 -> 2.2.5 (Central)
org.bouncycastle:bcmail-jdk15on:1.62 -> 1.65 (Central)
org.codehaus.jettison:jettison:1.4.0 -> 1.4.1 (Central)
org.eclipse.microprofile.metrics:microprofile-metrics-api:2.3 -> 2.3.2 (Central)
org.eclipse.microprofile.rest.client:microprofile-rest-client-api:1.4.0 -> 1.4.1 (Central)
org.eclipse.persistence:eclipselink:2.7.3 -> 2.7.7 (Central)
org.hibernate:hibernate-search-backend-jms:5.10.7.Final -> 5.10.9.Final (Central)
org.jboss.activemq.artemis.integration:artemis-wildfly-integration:1.0.2 -> 1.0.2-wildfly-1 (JBossPublic)
org.jboss.arquillian.container:arquillian-container-test-spi:1.4.0.Final -> 1.4.1.Final (Central)
org.jboss.narayana:jbosstxbridge:5.10.1.Final -> 5.10.4.Final (Central)
org.jboss.security:jbossxacml:2.0.8.Final -> 2.0.9.Final (JBossPublic)
org.wildfly.galleon-plugins:wildfly-config-gen:4.2.6.Final -> 4.2.7.Final (Central)
xalan:serializer:2.7.1.jbossorg-4 -> 2.7.2 (Central)
37 items
Report generated by Maven Dependency Updater
https://github.com/jboss-set/maven-dependency-updater
4 years, 6 months
Galleon layers for EJB3
by Brian Stansberry
Hi Cheng and Tomek and anyone else on wildfly-dev,
One of the main things I'm hoping we can do for WildFly 20 is get a
first-cut (perhaps tech preview) implementation of bootable jar support. A
big part of the bootable jar story is the user using Galleon during the
build of their application + server jar to produce a server customized to
their requirements. The key thing that makes that usable is having Galleon
layers for the functionality they want.
EJB is a big part of our functionality and we don't have layers for it yet,
so I'd like to get started on adding some. I've been thinking some about
what that might look like.
A bit of context: a layer is a form of API, in that once we support a
layer, if users use it to get some functionality, in the future they should
be able to continue to use that layer and get that same functionality. So
before introducing a layer we should be sure it does what we want, and also
that it doesn't by mistake do 'extra' things that we couldn't remove in the
future.
Our EJB subsystem provides a wide variety of features, and I can think of a
great number of use cases where users might want just some of them (say
local SLSBs only) and would like a slimmer server without the rest. It
would be great if in the future we could provide a number of layers to help
with that. But for the first cut at this I think we should keep it simple.
(Also, the more layers we have the more testing permutations we need to
deal with, which is doable but takes time.)
If a user is trying to slim their server I think of four key things they
want to do in descending order of importance:
1) Eliminate unnecessary open ports.
2) Eliminate unnecessary exposure
3) Eliminate jars, both to save filesystem footprint and to reduce any
theoretical attack surface.
4) Reduce configuration clutter and unnecessary services.
Given that I suggest we have the following layers:
1) ejb3-lite. This is like what we provide in standalone.xml, but without
the MDB instance pool or the remote connector resource. (A
webservices layer would depend on this.)
2) ejb3. Builds (i.e. depends) on ejb3-lite and adds the discovery
subsystem, the MDB pool and the remote connector resource. This looks what
we provide in standalone-full.xml, except no IIOP integration.
3) ejb3-iiop. Builds (i.e. depends) on *ejb3-lite* and adds the iiop
subsystem plus the integration resource in the EJB3 subsystem. This *could*
depend on *ejb3* instead, but that means EJB is unnecessarily exposed over
the HTTP interface and a lot of dependencies are brought in for messaging
integration.
A user could provision ejb3 + ejb3-iiop and get the equivalent to what's in
standalone-full.xml.
There'd be a couple ancillary layers as well:
4) ejb-local-cache. This provides the infinispan subsystem resources
related to local ejb caching (i.e. the ones in standalone.xml and
standalone-full.xml.) The ejb3-lite layer *optionally* depends on this.
It's an optional dependency because the user when provisioning can
*exclude* this layer and instead provision...
5) ejb-dist-cache. This provides the infinispan subsystem resources related
to distributed ejb caching (i.e. the ones in standalone0ha.xml and
standalone-full-ha.xml.)
This pattern of "exclude an optional local caching layer and add a
distributed variant" is how web session and jpa caching are handled in the
layers for those features.
https://github.com/bstansberry/wildfly/commits/ejb-layers2 illustrates what
the layer-specs could look like. (There's no effort there to adapt the
subsystem to require fewer deps; it's just illustrating the config
generation aspects.)
I think the main work here (besides testing) would be examining what if any
module dependencies in the org.jboss.as.ejb3 module could be made optional.
TBH I don't see big FS footprint improvements coming out of these
permutations. Big EJB dependencies include (in no particular order.)
a) IIOP. But the TM uses IIOP libs so they will be there regardless.
b) Remoting. It would be nice to be able to eliminate the need for
remoting, e.g. for ejb3-lite if the user app isn't a remote ejb client. But
that doesn't seem trivial and if a server is manageable remoting will be
there anyway to support the CLI.
c) JCA stuff. But if there's a datasource it's there anyway.
d) Infinispan. A benefit of a future SLSB-only layer would be this dep
could be eliminated. (But it might be used for web caching etc anyway.)
e) Remote artemis integration. This we do save if ejb3-lite is used.
The general testing strategy we've been doing as we've developed layers is
in testsuite/integration/smoke and basic we provision a server with a
particular set of layers and then add a surefire execution that runs a
subset of the tests that can work against the features in that server. That
hasn't been too painful.
WDYT?
Best regards,
- Brian
4 years, 6 months