Early Access b110 <https://jdk9.java.net/download/> for JDK 9 is
available on java.net, summary of changes are listed here
Among other fixes , the following changes are also included from builds
108 to 110
o removal of the OS X-specific com.apple.concurrent package
o update to the JAX-WS RI integration to latest version
o disabling of Diffie-Hellman keys smaller than 1024 bits
Early Access b110 <https://jdk9.java.net/jigsaw/> (#4664) for JDK 9 with
Project Jigsaw is available on java.net.
We expect this will be the last EA build before we integrate into JDK 9.
This means that this
EA build is essentially what will be jdk-9+111 next week.
As always, please help out by trying out existing code and libraries to
see what works and
doesn't work. We have a detailed list of compatibility issues listed in
JEP 261 .
Also feedback and questions from those that trying the EA build to
code would be appreciated. We also want to know what works and doesn't
work here 
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
What is the recommended approach to back porting model changes. The context
for the question is that we have added a bit of configuration to narayana
and exposed it in the subsystem model as an attribute on an existing
element. The latest subsystem version has more parser versions than the
target version we need to back port to. Since we do not want to back port
each intermediate parser, how do we get the new attribute into the earlier
t: +44 191 243 0870
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
(US), Charles Peters (US)
Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
There is an issue on composing native bits of Artemis during wildfly full-feature-pack build, that the 'libartemis-native.so' is duplicated.
One is at: 'modules/system/layers/base/org/apache/activemq/artemis/main/lib/linux-/libartemis-native-.so', and another is at: 'lib/linux-i686/libartemis-native-.so' in the artemis-native.jar file.
The duplication of the native bits will confuse the user which one is actually used, and which one to patch in case of one-off.
IMHO, we can add support in wildfly-build-tool to copy a jar file with some files excluded, so that we can filter out the 'libartemis-native-.so' in the artemis-native.jar during the wildfly-full-featch-pack build, like:
<copy-artifact artifact="org.apache.activemq:artemis-native" to-location="modules/system/layers/base/org/apache/activemq/artemis/main/" extract="FALSE"> <!-- Sets extract to false with some filters defined. -->
<filter pattern="*" include="true"/>
<filter pattern="lib/*" include="false" />
Do you guys think it makes sense?
JBoss by Red Hat