Deprecate Apache CXF Aegis databinding in the future
by Jim Ma
CXF Aegis databinding is possibly deprecated and removed in the future CXF
release.
I am not sure if there are WFLY users who are still using this feature now.
If you have any comments and concerns about this change, please let us know.
Thanks,
Jim
2 years, 1 month
WFLY-19020: behavior change in persistence unit handling of application client
by Wolfgang Knauf
Hi all,
this question is about a change in the way that a JakartaEE application
client is launched: https://issues.redhat.com/browse/WFLY-19020
Before the change, an application client might receive a
ClassNotFoundException because of a missing hibernate class. My
workaround for this was to add jboss-deployment-structure.xml and
include the module "org.hibernate".
This behavior was changed in 31.0.1 after my bugreport: it seems the
application client deploys "persistence.xml" from the EJB jar somehow,
and my sample now works.
But this change also causes the application client to create/drop the
tables each time it is launched if persistence.xml defines
"hibernate.hbm2ddl.auto=create-drop". This did not happen with WildFly
31.0.0 and before.
It can be avoided if the data source in "appclient.xml" points to a H2
memory database instead of the real database defined in "standalone.xml".
I did not verify whether old WildFly versions required the datasource to
be defined in "appclient.xml", but I have the feeling that it was necessary.
Currently, this is only an unnecessary step. But if the datasource
defined in "appclient.xml" would point to the "real" datasource defined
in "standalone.xml", the tables would be created each time the client
starts. Fortunately, I could not make it work to define a MariaDB
connection in "appclient.xml" because it could not resolve the driver,
but with some effort this could be possible.
What do you think about this change? To me, it sounds unnecessary to
create/drop tables from EJB "persistence.xml" when an app client is
started. Is it required if the app client itself would use client side JPA?
Best regards
Wolfgang
2 years, 1 month
JDK 23 Feature Freeze / New Loom EA builds
by David Delabassee
Welcome to the latest OpenJDK Quality Outreach update!
JDK 23, scheduled for General Availability on September 17, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is frozen (see the final list of JEPs integrated into JDK 23 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 23 enters the Release Candidates phase in early August [2]. We count on you to test your projects and help us make JDK 23 another solid release!
This time, we are covering several heads-up related to JDK 23 : Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation processing policy change. Also, make sure to check the new Loom early-access builds which have an improved Java monitors implementation to work better with virtual threads.
[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html
[2] https://openjdk.org/projects/jdk/23/
## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
As mentioned in a previous communication [3], there’s a plan to ultimately remove the sun.misc.Unsafe memory-access methods as the platform offers safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal) [4] outlines in more detail this plan including the initial step which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access methods are now marked as deprecated for removal. This will cause, in JDK 23, compile-time deprecation warnings for code that refers to these methods, alerting library developers to their forthcoming removal. A new command-line option also enables application developers and users to receive runtime warnings when those methods are used.
Developers relying on those sun.misc.Unsafe APIs for access memory are strongly encouraged to start, if they haven't done so yet, the migration from the sun.misc.Unsafe APIs to supported replacements. For more details, make sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal).
[3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html
[4] https://openjdk.org/jeps/471
## Heads-Up - JDK 23: Changes Default Annotation Processing Policy
Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing.
### New `-proc` Value
To that end, the pre-existing option `-proc:$policy` was extended, where `$policy` can now have the following values:
- `none`: compilation _without_ annotation processing, this policy exists since JDK 6
- `only`: annotation processing _without_ compilation, this policy exists since JDK 6
- `full`: annotation processing followed by compilation, this policy is the default in JDK ≤22 but the value itself is new (see next section for versions that support it)
Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither `-processor`, `--processor-path`, now `--processor-module-path` is used, `-proc:only` or `-proc:full` has to be provided. In other words, absent other command line options, `-proc:none` is the default on JDK 23.
### Migration to `-proc:full`
Several measures were undertaken to help projects prepare for the switch to `-proc:full`:
- As of the April 2024 JDK security updates, support for `-proc:full` has been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK distributions. Additionally, Oracle's 8u release (8u411) also supports `-proc:full`.
- Starting in JDK 21, javac prints an informative message if implicit usage of annotation processing under the default policy is detected.
With `-proc:full` backported, it is possible to configure a build that will work the same before and after the change in javac's default policy.
Additional details can be found in the original proposal [5].
[5] https://mail.openjdk.org/pipermail/jdk-dev/2024-May/009028.html
## Heads-up - Loom: New EA builds with improved Java monitors implementation to work better with virtual threads
Project Loom published new early-access builds [6]. These builds have an improved object monitor implementation that should prevent virtual threads from pinning their carrier thread in the following situations:
- when blocking on entering a synchronized method/statement because the object's associated monitor is held by another thread,
- when parking (e.g. when doing socket I/O) while in a synchronized method,
- when calling `Object.wait` while in a synchronized method.
The changes for `Object.wait`/timed-`wait` is the main change since the previous Loom EA build.
The Loom team is looking for help to test the changes, i.e., trying out these builds with code that is known to use virtual threads and with libraries that are "very synchronized". The primary goal is to gauge both reliability and performance. Right now, the focus is on being functional and reliable. Please note that the performance for some cases isn't yet fully on par with blocking on j.u.concurrent locks and condition objects.
As before, JFR events can be used to identify remaining cases of pinning, parking or blocking in a class initializer for example. The system property `jdk.tracePinnedThreads`, which used to print stack traces when threads are pinned, no longer outputs anything.
Please send feedback via email to the Loom mailing list [7] (subscription required).
[6] https://jdk.java.net/loom/
[7] http://mail.openjdk.org/mailman/listinfo/loom-dev
## JDK 23 Early-Access Builds
JDK 23 early-access builds 26 are now available [8] with the Release Notes here [9] and the javadocs here[10]. Those builds are provided under the GNU GPL v2, with the Classpath Exception.
### JEPs integrated into JDK 23:
- JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview)
- JEP 466: Class-File API (2nd Preview)
- JEP 467: Markdown Documentation Comments
- JEP 469: Vector API (8th Incubator)
- JEP 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
- JEP 473: Stream Gatherers (2nd Preview)
- JEP 474: ZGC: Generational Mode by Default
- JEP 476: Module Import Declarations (Preview)
- JEP 477: Implicitly Declared Classes and Instance Main Methods (3rd Preview)
- JEP 480: Structured Concurrency (3rd Preview)
- JEP 481: Scoped Values (3rd Preview)
- JEP 482: Flexible Constructor Bodies (2nd Preview)
### Changes in recent JDK 23 builds that may be of interest:
- JDK-8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
- JDK-8051959: Add thread and timestamp options to java.security.debug system property
- JDK-8321428: Deprecate for removal the package java.beans.beancontext
- JDK-8319990: Update CLDR to Version 45.0
- JDK-8331975: Enable case-insensitive check in ccache and keytab entry lookup
- JDK-8328083: degrade virtual thread support for GetObjectMonitorUsage
- JDK-8326666: Remove the Java Management Extension (JMX) Subject Delegation feature
- JDK-8295111: dpkg appears to have problems resolving symbolically linked native libraries
- JDK-8330077: Allow max number of events to be buffered to be configurable to avoid OVERFLOW_EVENT
- JDK-8332476: j.u.r.RandomGeneratorFactor.create(long|byte[]) should throw rather than silently fallback to no-arg create()
- JDK-8329113: Deprecate -XX:+UseNotificationThread
- JDK-8331202: Support for Duration until another Instant
- JDK-8316138: Add GlobalSign 2 TLS root certificates
- JDK-8330276: Console methods with explicit Locale
- JDK-8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module
- JDK-6968351: httpserver clashes with delayed TCP ACKs for low Content-Length
- JDK-8331021: Deprecate and then obsolete the DontYieldALot flag
- JDK-8330607: Deprecate -XX:+UseEmptySlotsInSupers
- JDK-8320522: Remove code related to `RegisterFinalizersAtInit`
- JDK-8329636: Deprecate -XX:+PreserveAllAnnotations
- JDK-8322234: Remove obsolete desktop integration from Linux installers
- JDK-8328649: Disallow enclosing instances for local classes in constructor prologues
- JDK-8330734: JFR: Re-engineer mirror class mechanism
- JDK-8300148: Consider using a StoreStore barrier instead of Release barrier on ctor exit
- JDK-8329997: Add provisions for checking memory segment alignment constraints
- JDK-8305457: Implement java.io.IO
- JDK-8321314: Reinstate disabling the compiler's default active annotation processing
- JDK-6942632: Hotspot should be able to use more than 64 logical processors on Windows
- JDK-8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull
- JDK-8206447: InflaterInputStream.skip receives long but it's limited to Integer.MAX_VALUE
Note: A more exhaustive list of changes can be found here [11].
[8] https://jdk.java.net/23/
[9] https://jdk.java.net/23/release-notes
[10] https://download.java.net/java/early_access/jdk23/docs/api/
[11] https://github.com/openjdk/jdk/compare/jdk-23+17...jdk-23+26
## New Jextract Early-Access Builds
New Jextract early-access builds have been made available [12]. These builds are based on JDK 22 and bring multiple enhancements. For additional details, make sure to check [13]. Moreover, a new jextract guide [14] has been published.
[12] https://jdk.java.net/jextract/
[13] https://mail.openjdk.org/pipermail/jextract-dev/2024-May/001699.html
[14] https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md
## JavaFX Early-Access Builds
These are early access builds of the JavaFX 23 Runtime built from openjdk/jfx [15]. These builds enable JavaFX application developers to build and test their applications with JavaFX 23 on JDK 23. Although these builds are designed to work with JDK 23EA, they are also known to work with JDK 21 and later versions.
The latest early access builds of JavaFX 23 are available here [16], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 23 API Javadocs [17] are also available.
[15] https://github.com/openjdk/jfx
[16] https://jdk.java.net/javafx23/
[17] https://download.java.net/java/early_access/javafx23/docs/api/overview-su...
## Topics of Interest
- All Java 23 Features - Inside Java Newscast
https://inside.java/2024/06/06/newscast-70/
- Module Imports in Java 23 - Inside Java Newscast
https://inside.java/2024/05/16/newscast-69/
- Java 23: JavaDoc Hits the Markdown on Comments - Inside Java Newscast
https://inside.java/2024/05/01/newscast-68/
- Java 23: Restoring the Balance with Primitive Patterns - Inside Java Newscast
https://inside.java/2024/04/04/newscast-66/
- Java in 2024 - Constant evolution, delivered.
https://inside.java/2024/06/01/java-in-2024-keynote/
- Introduction to JDK Mission Control
https://inside.java/2024/05/18/jmc-intro/
- What's New in JMC 9? - Sip of Java
https://inside.java/2024/04/21/sip096/
- Programmer's Guide to JDK Flight Recorder
https://inside.java/2024/04/12/programmer-guide-to-jfr/
- A Decade of JDK Updates in OpenJDK
https://inside.java/2024/04/09/a-decade-of-jdk-updates/
- Data-Oriented Programming - Version 1.1
https://inside.java/2024/05/23/dop-v1-1-introduction/
~
As usual, let us know if you find any issues while testing your project(s) with the latest JDK early-access builds.
Thank you!
--David
2 years, 1 month
