- slf4j-dev - mailman3.qos.ch

OpenJDK 17 Early Access build 16 is now available
by Rory O'Donnell 02 Apr '21

02 Apr '21

Hi Ceki, *OpenJDK 17 Early Access build 16 is now available at **http://jdk.java.net/17* <http://jdk.java.net/17> * 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> * Schedule (proposed) o 2021/06/10 Rampdown Phase One o 2021/07/15 Rampdown Phase Two o 2021/08/05 Initial Release Candidate o 2021/08/19 Final Release Candidate o 2021/09/14 General Availability * Features:*Heads-up on an important Candidate JEP * o *Candidate - JEP 403: **Strongly Encapsulate JDK Internals <https://openjdk.java.net/jeps/403>* o successor to JEP 396: Strongly Encapsulate JDK Internals by Default <https://openjdk.java.net/jeps/396> o strongly encapsulate all internal elements of the JDK by default o exception for Critical Internal APIs such as /sun.misc.Unsafe/ * JEPs targeted to JDK 17, so far: o JEP 356: Enhanced Pseudo-Random Number Generators <https://openjdk.java.net/jeps/356> o JEP 382: New macOS Rendering Pipeline <https://openjdk.java.net/jeps/382> o JEP 391: macOS/AArch64 Port <https://openjdk.java.net/jeps/391> o JEP 398: Deprecate the Applet API for Removal <https://openjdk.java.net/jeps/398> * Release Notes are available at http://jdk.java.net/17/release-notes <http://jdk.java.net/17/release-notes> * Changes in recent builds that maybe of interest: o Build 16 + JDK-8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) # Reported by Apache Ant o Build 15 + JDK-8263575: Conflict between JDK rpms and OL8 Modularity prevents dnf install/updates o Build 14 + JDK-8262277: URLClassLoader.getResource throws undocumented IllegalArgumentException + JDK-8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a sign character *Project Loom Early-Access Build: **Build 17-loom+5-191* <http://jdk.java.net/loom/>*(2021/3/19)* * These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * These builds are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. * 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>. *Quality Report for March 2021 was published here [1]*. * Thanks to everyone who contributed by creating features or enhancements, logging bugs, or downloading and testing the early-access builds. *Worth reading - **The Arrival of Java 16! <https://inside.java/2021/03/16/the-arrival-of-java16/>* * JDK 16 Migration guide - https://docs.oracle.com/en/java/javase/16/migrate/getting-started.html * #AllTestsGreenOnJDK16 - If your tests are green on JDK 16 please respond to this *tweet <https://twitter.com/Sharat_Chander/status/1368978627816136707>*. * Oracle Developer Live event - Individual sessions: 1. *Java 16: Consistency and Innovation* (Aurelio Garcia-Ribeyro): https://youtu.be/1acKCBbd6f4 <https://youtu.be/1acKCBbd6f4> 2. *Java Language Futures: Spring 2021* (Gavin Bierman): https://youtu.be/K9SVV0XNIP8 <https://youtu.be/K9SVV0XNIP8> 3. *Ask the Java Architects* (Mark Reinhold, Brian Goetz, Mikael Vidstedt, Ron Pressler): https://youtu.be/CVE4bWvuD3o <https://youtu.be/CVE4bWvuD3o> 4. *Learn Java 16 with IntelliJ IDEA *(Trisha Gee[JetBrains])*: *https://youtu.be/1hyWJTjxeGM <https://youtu.be/1hyWJTjxeGM>** 5. *How Records Can Improve Serialization* (Julia Boes, Chris Hegarty): https://youtu.be/44D8M6ZxuLU <https://youtu.be/44D8M6ZxuLU> 6. *Vector API: SIMD Programming in Java* (Paul Sandoz, Sandhya Viswanathan[Intel]): https://youtu.be/VYo3p4R66N8 <https://youtu.be/VYo3p4R66N8> 7. *Your Guide to OpenJDK Development* (Jesper Wilhelmsson): https://youtu.be/bHcKTYy_Nec <https://youtu.be/bHcKTYy_Nec> 8. *Project Skara: Migrating OpenJDK to Git and GitHub* (Erik Duveblad, Robin Westberg): https://youtu.be/-pBgplk7fVk <https://youtu.be/-pBgplk7fVk> 9. *Monitoring and Troubleshooting Tools in the JDK* (Poonam Parhar): https://youtu.be/mcfubUmbZhQ <https://youtu.be/mcfubUmbZhQ> 10. *Fast and Efficient Microservices for Java with GraalVM* (Alina Yurenko): https://youtu.be/_eRD6qJqtNw <https://youtu.be/_eRD6qJqtNw> 11. *Accelerating Productivity with Micronaut and Java Records* (Graeme Rocher): https://youtu.be/RoNeoXQBs9w <https://youtu.be/RoNeoXQBs9w> 12. *Scalable Microservices for Java using Helidon and Coherence CE* (Dmitry Aleksandrov, Aleks Seović): https://youtu.be/WTL0Zbjzveo <https://youtu.be/WTL0Zbjzveo> 13. *Cross-Platform User Interfaces, Developed with Java & OpenJFX Project* (Johan Vos [Gluon]): https://youtu.be/7eytbaBMm5o <https://youtu.be/7eytbaBMm5o> Rgds,Rory [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+March… <https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+March…> -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] Updates for SLF4J-512: module-info.java missing on all libs
by QOS.CH (JIRA) 31 Mar '21

31 Mar '21

SLF4J / SLF4J-512 [Open] module-info.java missing on all libs ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-512 ============================== Issue created ------------------------------ Franco Gastón Pellegrini created this issue on 31/Mar/21 6:28 PM Summary: module-info.java missing on all libs Issue Type: Improvement Affects Versions: 1.7.30, 2.0.0-alpha2 Assignee: SLF4J developers list Components: Implementations Created: 31/Mar/21 6:28 PM Environment: all versions Priority: Blocker Reporter: Franco Gastón Pellegrini Severity: blocker Description: Cannot use JDK jlink because all the libs lack of module-info.class/java files, intriduced since JDK 9 ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-334: SLF4J extensions relying on the LoggerWrapper class fail to log the exception on a parameterized query
by QOS.CH (JIRA) 30 Mar '21

30 Mar '21

SLF4J / SLF4J-334 [Open] SLF4J extensions relying on the LoggerWrapper class fail to log the exception on a parameterized query ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-334 ============================== 1 comment ------------------------------ Charles T'KINT DE ROODENBEKE on 30/Mar/21 10:13 AM A little bit late but the PR is still ongoing and the issue is still present it seems. On a side note, this issue does not exist with logger.debug: {code:java} Exception e = new Exception("foo", new Exception("bar")); logger.debug("Param: {}", "test", e) {code} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-511: DefaultLogEventBuilder causes incorrect location information to be logged
by QOS.CH (JIRA) 22 Mar '21

22 Mar '21

SLF4J / SLF4J-511 [Open] DefaultLogEventBuilder causes incorrect location information to be logged ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-511 ============================== Issue created ------------------------------ Ralph Goers created this issue on 22/Mar/21 7:08 AM Summary: DefaultLogEventBuilder causes incorrect location information to be logged Issue Type: Bug Affects Versions: 2.0.0-alpha1 Assignee: SLF4J developers list Components: Core API Created: 22/Mar/21 7:08 AM Environment: See [LOG4J2-2975|https://issues.apache.org/jira/browse/LOG4J2-2975] DefaultLogEventBuilder does {code:java} private void innerLog(LoggingEvent logggingEvent) { if (logger instanceof LoggingEventAware) { ((LoggingEventAware) logger).log(logggingEvent); } else { logViaPublicLoggerAPI(logggingEvent); } } {code} In both alternatives DefaultLogEventBuilder is going to show up as the caller of the logging API since there is no provision made to allow the implementation to determine the caller of the log method in DefaultEventBuilder. As such, for all practical purposes this class is useless. This issue does not affect Logback since it is using the NOPLoggingEventBuilder so the fluent API doesn't work in Logback at all. If it were using DefaultLogEventBuilder it would suffer from the same problem. The workaround is that any implementation that wants to support SLF4J's fluent API must implement its own LogEventBuilder. Priority: Major Reporter: Ralph Goers ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-510: Release 2.x already
by QOS.CH (JIRA) 22 Mar '21

22 Mar '21

SLF4J / SLF4J-510 [Open] Release 2.x already ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-510 ============================== 1 comment ------------------------------ Ralph Goers on 22/Mar/21 7:10 AM SLF4J-511 and Logback really need to be fixed to make the fluent API work properly before a release. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-510: Release 2.x already
by QOS.CH (JIRA) 22 Mar '21

22 Mar '21

SLF4J / SLF4J-510 [Open] Release 2.x already ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-510 ============================== Issue created ------------------------------ Jeremy Landis created this issue on 22/Mar/21 4:45 AM Summary: Release 2.x already Issue Type: Improvement Assignee: SLF4J developers list Created: 22/Mar/21 4:45 AM Priority: Major Reporter: Jeremy Landis Description: It has been year+, community wise, this library looks entirely dead. Many are confused on what version to use. 2.x and by extension logback 1.3 are incredibly stable. However, a huge use case simply will never use the beta/alpha releases (ie spring boot) resulting in best usage of 2.x only to drop back to 1.x. So please just release as is. Its been nearly 2 years already with visibly next to no activity at all. Effort to release as is is slim to none and would at least show this library is still active. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

Release Announcement: General Availability of Java 16 / JDK 16
by Rory O'Donnell 16 Mar '21

16 Mar '21

Hi Ceki, *Release Announcement: General Availability of Java 16 / JDK 16 * ** * JDK 16, the reference implementation of Java 16, is now Generally Available. [1] * GPL-licensed OpenJDK builds from Oracle are available here: http://jdk.java.net/16/ <http://jdk.java.net/16/> * JDK 16 Release notes <https://www.oracle.com/java/technologies/javase/16-relnotes.html> *JDK 16 includes the following features [2]:* * JEP 338:Vector API (Incubator) <https://openjdk.java.net/jeps/338> * JEP 347:Enable C++14 Language Features <https://openjdk.java.net/jeps/347> * JEP 357:Migrate from Mercurial to Git <https://openjdk.java.net/jeps/357> * JEP 369:Migrate to GitHub <https://openjdk.java.net/jeps/369> * JEP 376:ZGC: Concurrent Thread-Stack Processing <https://openjdk.java.net/jeps/376> * JEP 380:Unix-Domain Socket Channels <https://openjdk.java.net/jeps/380> * JEP 386:Alpine Linux Port <https://openjdk.java.net/jeps/386> * JEP 387:Elastic Metaspace <https://openjdk.java.net/jeps/387> * JEP 388:Windows/AArch64 Port <https://openjdk.java.net/jeps/388> * JEP 389:Foreign Linker API (Incubator) <https://openjdk.java.net/jeps/389> * JEP 390:Warnings for Value-Based Classes <https://openjdk.java.net/jeps/390> * JEP 392:Packaging Tool <https://openjdk.java.net/jeps/392> * JEP 393:Foreign-Memory Access API (Third Incubator) <https://openjdk.java.net/jeps/393> * JEP 394:Pattern Matching for instanceof <https://openjdk.java.net/jeps/394> * JEP 395:Records <https://openjdk.java.net/jeps/395> * JEP 396:Strongly Encapsulate JDK Internals by Default <https://openjdk.java.net/jeps/396> * JEP 397:Sealed Classes (Second Preview) <https://openjdk.java.net/jeps/397> Thanks to everyone who contributed to JDK 16, whether by creating features or enhancements, logging bugs, or downloading and testing the early-access builds. *OpenJDK 17 Early Access build 13 is now available at http://jdk.java.net/17 <http://jdk.java.net/17/> * ** * 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>. * JEPs targeted to JDK 17, so far: o JEP 356: Enhanced Pseudo-Random Number Generators <https://openjdk.java.net/jeps/356> * Release Notes are available at http://jdk.java.net/17/release-notes <http://jdk.java.net/17/release-notes> * Significant changes since the last availability email: o JDK-8259709: Disable SHA-1 XML Signatures (b13) o JDK-6323374: (coll) Optimize Collections.unmodifiable* and synchronized*(b13) o JDK-8139348: Deprecate 3DES and RC4 in Kerberos (b12) o JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl (b11) o JDK-8235139: Deprecate the socket impl factory mechanism(b10) o JDK-8225081: Remove Telia Company CA certificate expiring in April 2021(b9) *Project Lanai Early-Access Builds * * EA 10 Build 17-lanai+3-133 (2021/3/2) is available - http://jdk.java.net/lanai/ * 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>. *Project Loom Early-Access Builds* * Build 17-loom+4-174 (2021/3/12) is available - http://jdk.java.net/loom/ * 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>. *Project Panama Early-Access Builds * * Build 17-panama+2-51 (2021/2/12) is available - http://jdk.java.net/panama/ * 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>. Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005188.html [2] https://openjdk.java.net/projects/jdk/16/ <https://openjdk.java.net/projects/jdk/16/>

1 0

[JIRA] Updates for SLF4J-371: Support the lambda expression in the Logger
by QOS.CH (JIRA) 01 Mar '21

01 Mar '21

SLF4J / SLF4J-371 [Resolved] Support the lambda expression in the Logger ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-371 ============================== 1 comment ------------------------------ Alexander Kiselyov on 01/Mar/21 7:49 PM Hi @[~ceki], could you please clarify, was this feature finally considered an slf4j-fluent-exclusive, and no changes to the Logger interface will be made? ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-509: Append log records to the end of the log file
by QOS.CH (JIRA) 15 Feb '21

15 Feb '21

SLF4J / SLF4J-509 [Open] Append log records to the end of the log file ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-509 ============================== Issue created ------------------------------ Dmitriy Fedoriv created this issue on 15/Feb/21 6:11 AM Summary: Append log records to the end of the log file Issue Type: Improvement Assignee: SLF4J developers list Components: slf4j-simple Created: 15/Feb/21 6:11 AM Labels: FileAppender appender Priority: Minor Reporter: Dmitriy Fedoriv Description: It would be great to have the ability to aggregate all log records in a single log file. As a short term solution, we could expose a new option to control FileOutputStream append, as a long term - design simple log retention functionality. `org.slf4j.simpleLogger.logFileAppend` When true, records will be appended to the end of the file. When set to false, the file will be cleared before new records are written. Defaults to `false` for backward compatibility. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-508: Control log level output in the simple logger pattern layout
by QOS.CH (JIRA) 15 Feb '21

15 Feb '21

SLF4J / SLF4J-508 [Open] Control log level output in the simple logger pattern layout ============================== Here's what changed in this issue in the last few minutes. This issue has been created There is 1 comment. This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-508 ============================== Issue created ------------------------------ Dmitriy Fedoriv created this issue on 15/Feb/21 3:20 AM Summary: Control log level output in the simple logger pattern layout Issue Type: Improvement Assignee: SLF4J developers list Components: slf4j-simple Created: 15/Feb/21 3:20 AM Labels: layouts pattern Priority: Minor Reporter: Dmitriy Fedoriv Description: Dear QoS team, The justification for the improvement is to provide a smooth and backward-compatible switch between Java standard output and Slf4J SimpleLogger without any changes in output message pattern. The vast majority of static code analyzers consider printing directly to standard output as a bad practice, proposing to use a dedicated logger as a solution (e.g. https://rules.sonarsource.com/java/RSPEC-106) In some cases, the output format of a message could be restricted and not subject to change. That leaves the message format pattern as "<message><line_separator>" for the dedicated logger. At more "advanced" logging frameworks this can be controlled by setting different pattern layouts but in the slf4j-simple module, it's handled by simplelogger.properties configuration or system properties. The module already has specific properties to control the output of the date-time, thread name, and logger name, but missing one more to skip log level output such as "org.slf4j.simpleLogger.showLogLevel=true". ============================== 1 comment ------------------------------ Dmitriy Fedoriv on 15/Feb/21 3:26 AM Here is the link to related PR - https://github.com/qos-ch/slf4j/pull/256 ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0