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

JDK 15 is now in Rampdown Phase Two
by Rory O'Donnell 17 Jul '20

17 Jul '20

Hi Ceki, ** *Per the JDK 15 schedule, we are in Rampdown Phase Two* *[1]* Per the JDK Release Process [2] we now turn our focus to *P1 and P2 bugs*, which can be fixed with approval [3]. Late enhancements are still possible, with approval [4], but the bar is now extraordinarily high. **Please advise if you have any open high priority issues.* * * Schedule for JDK 15 o 2*020/07/16 Rampdown Phase Two* o 2020/08/06 Initial Release Candidate o 2020/08/20 Final Release Candidate o 2020/09/15 General Availability * Features included in JDK 15: o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) <http://openjdk.java.net/jeps/339> o JEP 360: Sealed Classes (Preview) <http://openjdk.java.net/jeps/360> o JEP 371: Hidden Classes <http://openjdk.java.net/jeps/371> o JEP 372: Remove the Nashorn JavaScript Engine <http://openjdk.java.net/jeps/372> o JEP 373: Reimplement the Legacy DatagramSocket API <https://openjdk.java.net/jeps/373> o JEP 374: Disable and Deprecate Biased Locking <http://openjdk.java.net/jeps/374> o JEP 375: Pattern Matching for instanceof (Second Preview) <https://openjdk.java.net/jeps/375> o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector <http://openjdk.java.net/jeps/377> o JEP 378: Text Blocks <http://openjdk.java.net/jeps/378> o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector <https://openjdk.java.net/jeps/379> o JEP 381: Remove the Solaris and SPARC Ports <https://openjdk.java.net/jeps/381> o JEP 383: Foreign-Memory Access API (Second Incubator) <https://openjdk.java.net/jeps/383> o JEP 384: Records (Second Preview) <https://openjdk.java.net/jeps/384> o JEP 385: Deprecate RMI Activation for Removal <https://openjdk.java.net/jeps/385> *JDK 15 **Early Access build 32 **is available**at : - jdk.java.net/15/* These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception. * Release notes o http://jdk.java.net/15/release-notes * Recent fixes that might be of interest o Build 32 + 8231800: Better listing of arrays + 8234836: Improve serialization handling o Build 31 + JDK-8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider o Build 29 + JDK-8233014: Enable ShowCodeDetailsInExceptionMessages by default *JDK 16 Early Access build 6 ****is available**at : - jdk.java.net/16/* These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception. * JEP Candidate o JEP 388: Windows/AArch64 Port <https://openjdk.java.net/jeps/388> * JEPs proposed to target o JEP 347: Enable C++14 Language Features <https://openjdk.java.net/jeps/347> * JEPs targeted to JDK 16, so far: o JEP 369: Migrate to GitHub <https://openjdk.java.net/jeps/369> o JEP 357: Migrate from Mercurial to Git <https://openjdk.java.net/jeps/357> ** * Recent fixes that might be of interest o Build 32 + 8231800: Better listing of arrays + 8234836: Improve serialization handling o Build 5 + JDK-8218021: Have jarsigner preserve posix permission attributes + JDK-8245302: Upgrade LogRecord to support long thread ids and remove its usage of ThreadLocal + JDK-8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider *Cryptoroadmap updated * * https://www.java.com/en/jre-jdk-cryptoroadmap.html *The "Best of the JDK" feature face-off tournament: Result!*_* *_ * *JDK Mission Control *is the winner based on the Twitter poll <https://twitter.com/java/status/1281595323685703683?s=20>. *The Quality Outreach Report for *June 2020**is available via the Quality Wiki page*: **June 2020 <https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+June+…> * *__* Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004536.html [2] https://openjdk.java.net/jeps/3 [3] https://openjdk.java.net/jeps/3#Fix-Request-Process [4] https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] Updates for SLF4J-495: Binary compatibility between release and alpha version
by QOS.CH (JIRA) 16 Jul '20

16 Jul '20

SLF4J / SLF4J-495 [Open] Binary compatibility between release and alpha version ============================== 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-495 ============================== 1 comment ------------------------------ Alexander Krimm on 16/Jul/20 11:35 PM Thank you for your quick response which matches the behavior we observed. This [manual section on binary compatibiliy|http://example.com] led me to believe that such a configuration should work: bq. However, from the client's perspective all versions of slf4j-api are compatible. *Client code compiled with slf4j-api-N.jar will run perfectly fine with slf4j-api-M.jar for any N and M.* You only need to ensure that the version of your binding matches that of the slf4j-api.jar. You do not have to worry about the version of slf4j-api.jar used by a given dependency in your project. You can always use any version of slf4j-api.jar, and as long as the version of slf4j-api.jar and its binding match, you should be fine. This is also repeated in the [FAQ|http://slf4j.org/faq.html#compatibility] bq. From the clients perspective, the SLF4J API is backward compatible for all versions. This means than you can upgrade from SLF4J version 1.0 to any later version without problems. *Code compiled with slf4j-api-versionN.jar will work with slf4j-api-versionM.jar for any versionN and any versionM*. To date, binary compatibility in slf4j-api has never been broken. For application development this is not a big deal but as a library developer, using the alpha API seems to force all of your users to also use the alpha API and corresponding bindings, which may or may not be acceptable for them, while the manual/faq suggest that there is little impact in upgrading. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-495: Binary compatibility between release and alpha version
by QOS.CH (JIRA) 16 Jul '20

16 Jul '20

SLF4J / SLF4J-495 [Open] Binary compatibility between release and alpha version ============================== 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-495 ============================== 1 comment ------------------------------ Kengo TODA on 16/Jul/20 4:59 AM When you build with slf4j-api 2.0.0, the slf4j-api in your runtime dependency should be 1.8.x or above. The binding (log4j-slf4j-impl in this case) also needs to be updated to which is built for 1.8.x. I suggest you to check [http://slf4j.org/news.html] {quote}SLF4J version 2.0.0 requires Java 8. It builds upon the 1.8.x series and adds a backward-compatible fluent logging api. By backward-compatible, we mean that existing logging frameworks do not have to be changed for the user to benefit from the fluent logging API. {quote} and the FAQ at [http://slf4j.org/faq.html#changesInVersion18] {quote}Note that the 2.0.x series builds upon the 1.8.x series, as such the remarks below are applicable to SLF4J 2.x as well. {quote} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-495: Binary compatibility between release and alpha version
by QOS.CH (JIRA) 15 Jul '20

15 Jul '20

SLF4J / SLF4J-495 [Open] Binary compatibility between release and alpha version ============================== 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-495 ============================== Issue created ------------------------------ Alexander Krimm created this issue on 15/Jul/20 3:24 PM Summary: Binary compatibility between release and alpha version Issue Type: Bug Affects Versions: 2.0.0-alpha0, 2.0.0-alpha1 Assignee: SLF4J developers list Components: Core API Created: 15/Jul/20 3:24 PM Environment: Linux 64bit, openjdk 11.0.4 SLF4J: 2.0.0-alpha0 (compile-time), 1.7.30 (run-time) Logging Provider: log4j-slf4j-impl 1.13.3 Labels: configuration documentation Priority: Major Reporter: Alexander Krimm Description: As I understand [http://slf4j.org/manual.html#compatibility] it should be possible to compile a library against slf4j-api 2.0.0-alpha0 and at runtime have slf4j-api-1.7.30.jar and a corresponding implementation e.g. log4j-slf4j-impl-1.13.3.jar on the classpath. However, when using the fluent api, this setup throws whenever a (fluent) Logging statement is hit: {code} java.lang.NoSuchMethodError: 'org.slf4j.spi.LoggingEventBuilder org.slf4j.Logger.atInfo()' {code} Is binary compatibility restricted to the same major version number, are alpha versions excluded? Effectively this seems to force all projects which have dependencies using the Fluent Logging API to also use the alpha logging API. I really like the the new API, so I hope there's some way to set this up correctly. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-450: Allow binding to be explicitly specified
by QOS.CH (JIRA) 14 Jul '20

14 Jul '20

SLF4J / SLF4J-450 [Open] Allow binding to be explicitly specified ============================== 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-450 ============================== 1 comment ------------------------------ Kengo TODA on 14/Jul/20 4:24 AM I'm proposing a PR to implement this enhancement at [https://github.com/qos-ch/slf4j/pull/241] I've taken a microbenchmark, you can find its result at [Gist|https://gist.github.com/KengoTODA/3812d68112ee873b83120d44f7714a7d] Based on the result, I think this change is valuable even when we have only one binding on the CLASSPATH. But it's just a microbenchmark so I'm not so sure that it's trustable or not. If you have time to try my change, please pull and build that branch. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-452: MessageFormatter does not escape backslash correctly
by QOS.CH (JIRA) 14 Jul '20

14 Jul '20

SLF4J / SLF4J-452 [Open] MessageFormatter does not escape backslash correctly ============================== 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-452 ============================== 1 comment ------------------------------ Kengo TODA on 14/Jul/20 2:06 AM Proposing a PR at [https://github.com/qos-ch/slf4j/pull/240] to fix this issue. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0