May 2020 - slf4j-dev - mailman3.qos.ch

OpenJDK 15 EA build 24 is now available
by Rory O'Donnell 22 May '20

22 May '20

Hi Ceki, 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

1 0

[JIRA] (SLF4J-492) multiple_bindings warning impossible to disable on Windows using wildcard classpath
by QOS.CH (JIRA) 14 May '20

14 May '20

Phil Walker created SLF4J-492: --------------------------------- Summary: multiple_bindings warning impossible to disable on Windows using wildcard classpath Key: SLF4J-492 URL: https://jira.qos.ch/browse/SLF4J-492 Project: SLF4J Issue Type: Bug Components: slf4j-simple Affects Versions: 1.7.30 Environment: Windows 10 java 1.8.0_251 scala 2.13.2 Reporter: Phil Walker Assignee: SLF4J developers list Classpath consists primarily of jars below a directory, via '-classpath 'c:\opt\uejlib2.13*' Warning issued by slf4j: SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/opt/uejlib2.13/slf4j-nop-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/c:/opt/uejlib2.13/slf4j-nop-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See [http://www.slf4j.org/codes.html#multiple_bindings] for an explanation. SLF4J: Actual binding is of type [org.slf4j.helpers.NOPLoggerFactory] The two jar paths differ only with respect to one of them having a drive letter ("C:") and the other not. Because of the way the jar was specified (via a directory wildcard -classpath), there would not appear to be any way to fix this on the client side. If the two paths are compared via "java.io.File.getCanonicalPath", the apparent duplication is removed, making SLF4J less demanding of client code. By the way, our project only pulls SLF4J in by way of a transitive dependency, and this spurious warning is quite problematic for us. Thanks for your consideration! -- This message was sent by Atlassian Jira (v8.8.0#808000)

1 0

[JIRA] (SLF4J-491) Deprecate or remove slf4j-log4j12
by QOS.CH (JIRA) 07 May '20

07 May '20

Joachim Durchholz created SLF4J-491: --------------------------------------- Summary: Deprecate or remove slf4j-log4j12 Key: SLF4J-491 URL: https://jira.qos.ch/browse/SLF4J-491 Project: SLF4J Issue Type: Task Components: Implementations Reporter: Joachim Durchholz Assignee: SLF4J developers list [http://logging.apache.org/log4j/1.2/index.html] states that log4j 1.2 has an unresolved security hole (unvalidated deserialization, remotely exploitable without authorization). _Java 9 having a different version string format broke log4j's version string parsing, introducing bugs into its MDC implementation, but that's much less important._ Options for the documentation: # Add a warning to the SLF4J manual that slf4j-log4j12 should not be used anymore. # Remove mentions of slf4j-log4j12 entirely. Options for the code: Since slf4j-log4j12 cannot be removed from Maven repositories, a new version that warns about the issue should be released: # Make it output an ERROR, stating "log4j 1.2 has an unfixed security hole; your application can be hacked by anybody with network access (CVE-2019-17571). Migrate to another logging backend as soon as possible." # As above, but make it abort startup. (That's probably too much, there could be edge cases where an organization cannot migrate and cannot downgrade back to a previous, working slkf4j-log4j12.) -- This message was sent by Atlassian Jira (v8.8.0#808000)

1 0

[JIRA] (SLF4J-490) Better combination for logging and exceptions
by QOS.CH (JIRA) 06 May '20

06 May '20

Norbert Kiesel created SLF4J-490: ------------------------------------ Summary: Better combination for logging and exceptions Key: SLF4J-490 URL: https://jira.qos.ch/browse/SLF4J-490 Project: SLF4J Issue Type: Improvement Components: Core API Affects Versions: 1.7.29 Reporter: Norbert Kiesel Assignee: SLF4J developers list Hi, we have quite a few places in our code where we do: {code:java} logger.error("Param {} must be in [{}-{}]", name, low, high); throw new ValidationException("Param " + name + " must be in [" + low + "-" + high + "]"); {code} This is obviously ugly. Other options would be to use {code:java} String msg = String.format("Param %s must be in [%s-%s]", name, low, high); logger.error(msg); throw new ValidationException(msg);{code} or {code:java} String msg = MessageFormatter.format("Param {} must be in [{}-{}]", new Object[] {name, low, high}).getMessage(); logger.error(msg); throw new ValidationException(msg); {code} Both are not ideal. Can't we have a `Logger.format` method which returns a `FormattingTuple` w/o the explicit array creation and allow `Logger.error` etc. to be called with a `FormattingTuple`? Then I could write {code:java} FormattingTuple entry = logger.format("Param {} must be in [{}-{}]", name, low, high); logger.error(entry); throw new ValidationException(entry.getMessage());{code} For my own exception classes I could then even offer a constructor that takes a FormattingTuple and internally use the message and the throwable (if it is not null). Bonus: pick a nicer name than `FormattingTuple` like `LogEntry`. -- This message was sent by Atlassian Jira (v8.8.0#808000)

1 0

OpenJDK 15 EA build 21 is now available
by Rory O'Donnell 01 May '20

01 May '20

Hi Ceki, OpenJDK 15 EA build 21 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 Integrated in JDK 15 + JEP 371: <http://openjdk.java.net/jeps/371> Hidden Classes + JEP 372 <https://openjdk.java.net/jeps/372>: Remove the Nashorn JavaScript Engine + JEP 377 <https://openjdk.java.net/jeps/377>: ZGC: A Scalable Low-Latency Garbage Collector + JEP 378 <https://openjdk.java.net/jeps/378>: Text Blocks o JEPs targeted to JDK 15 + JEP 379 <https://openjdk.java.net/jeps/379>: Shenandoah: A Low-Pause-Time Garbage Collector * Changes in recent builds that maybe of interest: o build 21 + JDK-8242848 <https://bugs.openjdk.java.net/browse/JDK-8242848>: Improve performance of InflaterOutputStream.write() + JDK-8243574 <https://bugs.openjdk.java.net/browse/JDK-8243574>: java.lang.invoke.InvokerBytecodeGenerator.ClassData should be package-private # Reported by JaCoCo o build 20 + JDK-8237890 <https://bugs.openjdk.java.net/browse/JDK-8237890>: DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set [1] + JDK-8228991 <https://bugs.openjdk.java.net/browse/JDK-8228991>: Obsolete -XX:UseAdaptiveGCBoundary [1] + JDK-8242141 <https://bugs.openjdk.java.net/browse/JDK-8242141>: New System Properties to configure the TLS signature schemes [1] + JDK-8172404 <https://bugs.openjdk.java.net/browse/JDK-8172404>: Tools should warn if weak algorithms are used before restricting them + JDK-8238195 <https://bugs.openjdk.java.net/browse/JDK-8238195>: Lookup::defineClass should link the class to match the specification + JDK-8238358 <https://bugs.openjdk.java.net/browse/JDK-8238358>: Implementation of JEP 371: Hidden Classes + JDK-8241749 <https://bugs.openjdk.java.net/browse/JDK-8241749>: Remove the Nashorn JavaScript Engine + JDK-8242260 <https://bugs.openjdk.java.net/browse/JDK-8242260>: Add forRemoval=true to already deprecated ContentSigner + JDK- <https://bugs.openjdk.java.net/browse/JDK-8242008>8242008 <https://bugs.openjdk.java.net/browse/JDK-8242008>: SSLSession inconsistencies # Reported by Netty o build 19 + JDK-8239594 <https://bugs.openjdk.java.net/browse/JDK-8239594>: The java.net.HttpClient does not override the protocols specified in the SSLContext default parameters [1] + JDK-8172680 <https://bugs.openjdk.java.net/browse/JDK-8172680>: SunJCE provider now supports SHA-3 based Hmac algorithms + JDK-8237474 <https://bugs.openjdk.java.net/browse/JDK-8237474>: Default SSLEngine should create in server role + JDK-8240877 <https://bugs.openjdk.java.net/browse/JDK-8240877>: NPE at javax.swing.text.html.FormView.appendBuffer with null option values # reported by JOSM Project Loom Early-Access Builds - Build 15-loom+5-125 (2020/4/17) * 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/>. * 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>. * 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>. Rgds,Rory [1] http://jdk.java.net/15/release-notes -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0