Removing the logging.properties Configuration File
by James Perkins
Hello All,
I've talked about this many times, but I think it's really the time to
tackle this now. I would like to propose that we remove the boot logging
configuration file and collect log messages until the logging subsystem is
activated.
This should solve several old JIRA's. Here are 5 of them without looking
too hard :)
- https://issues.redhat.com/browse/WFCORE-152
- https://issues.redhat.com/browse/WFCORE-157
- https://issues.redhat.com/browse/WFCORE-474
- https://issues.redhat.com/browse/WFCORE-2516
- https://issues.redhat.com/browse/WFCORE-5275
We also benefit from being able to make WildFly much easier to move between
hosts. I see this as a benefit for both bare-metal and cloud. Currently,
once booted the logging.properties is written with absolute paths which
causes boot issues if the file system is changed.
This would also allow us to upgrade the JBoss Log Manager to the latest
version which includes some nice enhancements. One of which is better
coloring of log messages. We could even log a WildFly logo on boot :) More
seriously though, it will keep WildFy in line with the version that other
projects are using.
Really, overall, there are nothing but benefits in doing this. The only
cons I see are the following;
- Potentiel for OOME if all logging is enabled for all loggers.
- This would be extremely rare I would think and may never even
happen.
- A system property would need to be used to define the lowest logging
level wanted. However, this is better than requiring a logging.properties
to control this IMO.
This change would not remove the ability to use a logging.properties if the
user has chosen to remove the logging subsystem. In those cases, the
logging.properties would still work. However, if the logging subsystem is
also present it would override anything in the logging.properties
configuration.
Any questions, opinions or comments are welcome. If this seems reasonable
it seems like something we should get moving on ASAP.
--
James R. Perkins
JBoss by Red Hat
1 year, 1 month
JDK 21 EA builds 22 & Sequenced Collections Heads-up
by David Delabassee
Welcome to the latest OpenJDK Quality Outreach update!
The schedule for JDK 21 is now known [1] with Rampdown Phase One (RDP1) phase set for June 8th and General Availability (GA) set for September 19th. As we are getting closer to RDP1, we are gradually getting a better view on the JDK 21 content.
At the time of writing, 5 JEPs are already integrated in the JDK 21 mainline - Virtual Threads, Generational ZGC, etc. – see below for more details. This newsletter heads-up is focused on one of those JEPs; i.e., JEP 431 Sequenced Collections, as it might induce some incompatibilities on existing codebases.
Please do tell us if your project works or fails on the latest JDK 21 Early-Access builds. We still have some time to fix issues before JDK 21 reaches General Availability.
[1] https://openjdk.org/projects/jdk/21/
## Heads-Up - JDK 21: Potential Sequenced Collections Incompatibilities
The Sequenced Collection JEP [2] has been integrated into JDK 21, build 20. This JEP introduces several new interfaces into the collections framework’s interface hierarchy, and these interfaces introduce new default methods. When such changes are made, they can cause conflicts that result in source or binary incompatibilities. Any conflicts that occur will be in code that implements new collections or that subclasses existing collection classes. Code that simply uses collections implementations will be largely unaffected.
There are several kinds of conflicts that might arise. The first is a simple method naming conflict, if a method already exists with the same name but with a different return type or access modifier. Another is a clash between different inherited default method implementations arising from covariant overrides. A class might inherit multiple default methods if it implements multiple interfaces from different parts of the collections framework. A third example occurs with type inference. With type inference (e.g., the use of `var`) the compiler will infer a type for that local variable. It’s possible for other code to use explicitly declared types that must match the inferred type. The change to the interface hierarchy might result in a different inferred type, causing an incompatibility.
Make sure to check the following article [3] that provides additional details and strategies to mitigate potential incompatibilities.
[2] https://openjdk.org/jeps/431
[3] https://inside.java/2023/05/12/quality-heads-up/
Additional Sequenced Collections resources are also listed in the 'Topics of Interest' section below.
## JDK 21 Early-Access builds
The latest Early-Access builds 22 are available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [5] and the Javadocs [6] are also available.
[4] https://jdk.java.net/21/
[5] https://jdk.java.net/21/release-notes
[6] https://download.java.net/java/early_access/jdk21/docs/api/
### JEPs integrated to JDK 21, so far:
- 430: String Templates (Preview)
- 431: Sequenced Collections
- 439: Generational ZGC
- 442: Foreign Function & Memory API (3rd Preview)
- 444: Virtual Threads
### JEPs targeted to JDK 21, so far:
- 440: Record Patterns
- 441: Pattern Matching for switch
- 448: Vector API (6th Incubator)
JEPs proposed to target JDK 21:
- 404: Generational Shenandoah (Experimental)
- 443: Unnamed Patterns and Variables (Preview)
- 445: Unnamed Classes and Instance Main Methods (Preview)
- 449: Deprecate the Windows 32-bit x86 Port for Removal
### Changes in recent builds that may be of interest:
Note that this is only a curated list of changes, make sure to check https://github.com/openjdk/jdk/compare/jdk-21+0...jdk-21+22 for additional changes.
JDK 21 Build 22:
- JDK-8307466: java.time.Instant calculation bug in until and between methods
- JDK-8307399: get rid of compatibility ThreadStart/ThreadEnd events for virtual threads
- JDK-8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions
- JDK-8280031: Deprecate GTK2 for removal
- JDK-8307629: FunctionDescriptor::toMethodType should allow sequence layouts (mainline)
- JDK-8302845: Replace finalizer usage in JNDI DNS provider with Cleaner
- JDK-8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions
- JDK-8306881: Update FreeType to 2.13.0
- JDK-8285932: Implementation of JEP 430 String Templates (Preview)
- JDK-8307301: Update HarfBuzz to 7.2.0
- JDK-8159337: Introduce a method in Locale class to return the language tags as per RFC 5646 convention
- JDK-8291555: Implement alternative fast-locking scheme
- JDK-8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern
JDK 21 Build 21:
- JDK-8305092: Improve Thread.sleep(millis, nanos) for sub-millisecond granularity
- JDK-8303784: no-@Target annotations should be applicable to type parameter declarations
- JDK-8303002: Reject packed structs from linker
- JDK-8300784: Specify exactly how padding should be presented to the linker
- JDK-8303524: Check FunctionDescriptor byte order when linking
- JDK-8304265: Implementation of Foreign Function and Memory API (Third Preview)
- JDK-8293117: Add atomic bitset functions
- JDK-8306696: Remove MetaspaceReclaimPolicy=aggressive and obsolete MetaspaceReclaimPolicy
JDK 21 Build 20:
- JDK-8306658: GHA: MSVC installation could be optional since it might already be pre-installed
- JDK-8305590: Remove nothrow exception specifications from operator new
- JDK-8266571: JEP 431 Sequenced Collections
- JDK-8306772: Remove sun.security.x509.CertException, sun.security.x509.CertParseError
- JDK-8306075: Micro-optimize Enum.hashCode
- JDK-8306031: Update IANA Language Subtag Registry to Version 2023-04-13
- JDK-8298048: Combine CDS archive heap into a single block
- JDK-8305994: Guarantee eventual async monitor deflation
JDK 21 Build 19:
- JDK-8296248: Update CLDR to Version 43.0
- JDK-8257967: JFR: Events for loaded agents
- JDK-8305811: (bf) Improve performance of CharBuffer::append(CharSequence[,int,int])
- JDK-8304450: [vectorapi] Refactor VectorShuffle implementation
JDK 21 Build 18:
- JDK-8302819: Remove JAR Index
- JDK-8267140: Support closing the HttpClient by making it auto-closable
- JDK-8205129: Remove java.lang.Compiler
- JDK-8305310: Calculate PublicKey from PrivateKey
- JDK-8304919: Implementation of Virtual Threads (JEP 444)
- JDK-8182621: JSSE should reject empty TLS plaintexts
- JDK-8304745: Lazily initialize byte[] in java.io.BufferedInputStream
JDK 21 Build 17:
- JDK-8305107: Emoji related binary properties in RegEx
- JDK-8304982: Emit warning for removal of `COMPAT` provider
- JDK-8303260: (fc) FileChannel::transferFrom should support position > size()
- JDK-8304846: Provide a shared utility to dump generated classes defined via Lookup API
- JDK-8303229: JFR: Preserve disk repository after exit
- JDK-8305113: (tz) Update Timezone Data to 2023c
- JDK-8294266: Add a way to pre-touch java thread stacks
- JDK-8301106: Allow archived Java strings to be moved by GC
- JDK-8305157: The java.util.Arrays class should be declared final
- JDK-8304743: Compile_lock and SystemDictionary updates
- JDK-8304945: StringBuilder and StringBuffer should implement Appendable explicitly
- JDK-8302323: Add repeat methods to StringBuilder/StringBuffer
JDK 21 Build 16:
- JDK-8303392: Runtime.exec and ProcessBuilder.start should use System logger
- JDK-8300977: Retire java.io.ExpiringCache
- JDK-8296656: java.lang.NoClassDefFoundError exception on running fully legitimate code
- JDK-8027682: javac wrongly accepts semicolons in package and import decls
- JDK-8231349: Move intrinsic stubs generation to compiler runtime initialization code
- JDK-8288730: Add type parameter to Lookup::accessClass and Lookup::ensureInitialized
- JDK-8304759: Add BitMap iterators
- JDK-8304691: Remove jlink --post-process-path option
- JDK-8304301: Remove the global option SuperWordMaxVectorSize
- JDK-8298725: Add BitMap support for reverse iteration
- JDK-8302191: Performance degradation for float/double modulo on Linux
## JavaFX 21 Early-Access Builds
These are early-access builds of the JavaFX 21 Runtime, built from openjdk/jfx [7]. They enabled JavaFX application developers to build and test their applications with JavaFX 21 on JDK 21.
The latest builds 17 (2023/5/15) are available [8]. They are provided under the GNU General Public License, version 2, with the Classpath Exception. Please send the feedback to the openjfx-dev mailing list [9].
[7] https://github.com/openjdk/jfx
[8] https://jdk.java.net/javafx21/
[9] https://mail.openjdk.org/pipermail/openjfx-dev/
## Topics of Interest:
New candidate: JEP 451: Prepare to Disallow the Dynamic Loading of Agents
https://openjdk.org/jeps/451
Save Memory with Compact Headers
https://inside.java/2023/05/11/newscast-48/
Interpolating Strings like a King in Java 21
https://inside.java/2023/04/27/newscast-47/
“Sequenced Collections” podcast with Stuart Marks
https://inside.java/2023/04/25/podcast-031/
Z Garbage Collector: The Next Generation
https://inside.java/2023/04/23/levelup-zgc/
Getting Rid Of Unused Variables
https://inside.java/2023/04/13/newscast-46/
Evolving the Security of the Java Platform
https://inside.java/2023/04/11/levelup-security/
Java Language Futures, Spring 2023 Edition
https://inside.java/2023/04/06/levelup-amber/
Java 21's New (Sequenced) Collections
https://inside.java/2023/03/30/newscast/
JFR: Java's Observability & Monitoring Framework
https://inside.java/2023/05/14/stackwalker-02/
Additionals Level Up - Java Developer Day videos
https://www.youtube.com/playlist?list=PLX8CzqL3ArzX_RZNjtyETshl876jfE2bo
## April 2023 Critical Patch Update Released
As part of the April 2023 CPU, Oracle released OpenJDK 20.0.1, JDK 20.0.1, JDK 17.0.7 LTS, JDK 11.0.19 LTS, JDK 8u371, as well as JDK 8u371-perf.
~
Thanks for participating in the OpenJDK Quality Outreach program. If you find any issue on JDK 21 EA builds, please send it my way!
--David
1 year, 2 months
