- slf4j-dev - mailman3.qos.ch

Preventing Possible NullPointerException
by Shubham Raj 06 Apr '19

06 Apr '19

I did a case study on slf4j using Checker Framework <https://checkerframework.org/>. The Case Study revealed some possible NullPointerException that can be caused in future. Should I make a pull request for the rectification for the same.

1 0

JDK 13 - Early Access build 14 is available
by Rory O'Donnell 29 Mar '19

29 Mar '19

Hi Ceki, *OpenJDK builds *- JDK 13 - Early Access build 14 is available at http://jdk.java.net/13/ * 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>. * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B13%22%3A%3…> * Release notes [1] * JDK 13 Schedule proposal accepted [2] o 2019/06/13 Rampdown Phase One o 2019/07/18 Rampdown Phase Two o 2019/08/08 Initial Release Candidate o 2019/08/22 Final Release Candidate o 2019/09/17 General Availability *jpackage EA * * This is an early access build of JEP 343: Packaging Tool <https://openjdk.java.net/jeps/343>, aimed at testing a prototype implementation of jpackage, which is a new tool for packaging self-contained Java applications along with a Java Runtime Environment. * Build 30 is now available http://jdk.java.net/jpackage/ * Please send feedback via e-mail to core-libs-dev(a)openjdk.java.net <mailto:core-libs-dev@openjdk.java.net> *Quality Outreach report for **March 2019* * The report for March 2019 is available here <https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March…> * Thanks to all those contributed ! *Recent Blog:* A new (Japanese) era for Java! <https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java> Rgds,Rory [1] http://jdk.java.net/13/release-notes [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002736.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 25 Mar '19

25 Mar '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Federico Fissore commented on SLF4J-371: ---------------------------------------- An initial effort to support lambdas in slf4j 2.0 has been discussed in the mailing list and resulted in this PR [https://github.com/qos-ch/slf4j/pull/203] If you wish to use the same api with the _current_ version of slf4j, you want to take a look at https://github.com/ffissore/slf4j-fluent > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: SLF4J developers list > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 25 Mar '19

25 Mar '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Alex commented on SLF4J-371: ---------------------------- Any update on this issue? > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: SLF4J developers list > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Release Announcement: General Availability of Java 12 / JDK 12
by Rory O'Donnell 20 Mar '19

20 Mar '19

Hi Ceki, *1) Release Announcement: General Availability of Java 12 / JDK 12 [1] * * JDK 12, the reference implementation of Java 12, is now Generally Available. * GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/12 This release includes the following eight features: * JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental) * JEP 230: Microbenchmark Suite * JEP 334: JVM Constants API * JEP 340: One AArch64 Port, Not Two * JEP 341: Default CDS Archives * JEP 344: Abortable Mixed Collections for G1 * JEP 346: Promptly Return Unused Committed Memory from G1 * JEP 325: Switch Expressions (Preview) <https://openjdk.java.net/jeps/325> Thanks to everyone who contributed JDK 12, whether by creating features or enhancements, logging bugs, or downloading and testing the early-access builds. *2) JDK 13 EA build 12, under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/13**.* * Proposed - Schedule for JDK 13 [2] o 2019/06/13 Rampdown Phase One o 2019/07/18 Rampdown Phase Two o 2019/08/08 Initial Release Candidate o 2019/08/22 Final Release Candidate o 2019/09/17 General Availability * Recent Bug fixes of Interest o Build 9: + 8214719: Deprecate -Xverify:none option + 8216360: Deprecate -XX:CompilationPolicyChoice o Build 10: + 8218995: Deprecate the -XX:FailOverToOldVerifier option o Build 12 : 8160247: Mark deprecated javax.security.cert APIs with forRemoval=true + 8220050: Deprecate -XX:-ThreadLocalHandshakes + Apache Lucene Reported - 8219448: split-if update_uses accesses stale idom data * Changes in this build [3] Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002718.html [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002716.html [3] Changes <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B11%22%3A%3…> in this build -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-457) OSGi support in SLF4J 1.8
by QOS.CH (JIRA) 21 Feb '19

21 Feb '19

Björn Kautler created SLF4J-457: ----------------------------------- Summary: OSGi support in SLF4J 1.8 Key: SLF4J-457 URL: https://jira.qos.ch/browse/SLF4J-457 Project: SLF4J Issue Type: Improvement Components: Core API Affects Versions: 1.8.0-beta4 Environment: Reporter: Björn Kautler Assignee: SLF4J developers list Please support the native OSGi service loader mechanism for finding and registering implementations. As this needs some work, an intermediary quick-fix would be to depend on the service loader mediator. For this a PR exists at https://github.com/qos-ch/slf4j/pull/198. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-445) Skip SubstituteLogger from caller data (slf4j-jdk14)
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-445?page=com.atlassian.jira.plugin.system.… ] Guillaume Grossetie commented on SLF4J-445: ------------------------------------------- Awesome thanks @ceki > Skip SubstituteLogger from caller data (slf4j-jdk14) > ---------------------------------------------------- > > Key: SLF4J-445 > URL: https://jira.qos.ch/browse/SLF4J-445 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.7.25 > Environment: Slf4j-jdk14 binding > Reporter: Alexander Yevsyukov > Assignee: Ceki Gülcü > Labels: consoleoutput, substitution > Fix For: 1.8.0-beta5 > > > When using \{\{SubstituteLogger}} with \{\{JDK14LoggerAdapter}} (obtained regularly via \{\{LoggerFactory}}) the output always gives \{\{SubstituteLogger}} as the caller. A programmer would be interested in the class/method of his code. > The issue is that \{\{JDK14LoggerAdapter.fillCallerData()}} does not take into account that \{\{SubstituteLogger}} can be the direct caller, and it is needed to go one level deeper. > This issue is similar to [one reported to LogBack|https://jira.qos.ch/browse/LOGBACK-1100]. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-445) Skip SubstituteLogger from caller data (slf4j-jdk14)
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-445?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-445. ------------------------------ Resolution: Fixed Fixed in [commit 9928d|https://github.com/qos-ch/slf4j/commit/9928d80daf022e] > Skip SubstituteLogger from caller data (slf4j-jdk14) > ---------------------------------------------------- > > Key: SLF4J-445 > URL: https://jira.qos.ch/browse/SLF4J-445 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.7.25 > Environment: Slf4j-jdk14 binding > Reporter: Alexander Yevsyukov > Assignee: Ceki Gülcü > Labels: consoleoutput, substitution > Fix For: 1.8.0-beta5 > > > When using \{\{SubstituteLogger}} with \{\{JDK14LoggerAdapter}} (obtained regularly via \{\{LoggerFactory}}) the output always gives \{\{SubstituteLogger}} as the caller. A programmer would be interested in the class/method of his code. > The issue is that \{\{JDK14LoggerAdapter.fillCallerData()}} does not take into account that \{\{SubstituteLogger}} can be the direct caller, and it is needed to go one level deeper. > This issue is similar to [one reported to LogBack|https://jira.qos.ch/browse/LOGBACK-1100]. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-449) Unexpected execution environment J2SE-1.6
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-449?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-449. ------------------------------ Resolution: Fixed Fixed in [commit 458525e2e194e8|https://github.com/qos-ch/slf4j/commit/458525e2e194e8] > Unexpected execution environment J2SE-1.6 > ----------------------------------------- > > Key: SLF4J-449 > URL: https://jira.qos.ch/browse/SLF4J-449 > Project: SLF4J > Issue Type: Bug > Components: Core API, Implementations > Affects Versions: 1.8.0-beta2 > Environment: OSGi Execution Environments and specifically, Eclipse Tycho and OSGi plugins and bundles. > Reporter: Larissa Smirnova > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta5 > > > The Bundle-RequiredExecutionEnvironment in the slf4j-api and slf4j-integration are set to J2SE-1.6. The Standard Eclipse OSGi Execution Environment for Java 6 is JavaSE-1.6 and not J2SE-1.6. Due to this error, builds using the Eclipse OSGi Execution Environment value will have an error of an unrecognized Execution Environment. One example is using Eclipse Tycho to build Eclipse plugins and OSGi bundles. > The issue has appeared after commit ab389a9b82abe35034a3026c7eb0d4b9a07b4ae7 updated Bundle-RequiredExecutionEnvironment value from J2SE-1.5 to J2SE-1.6. > The Standard Execution Environments are listed at: [https://wiki.eclipse.org/Execution_Environments#Standard_Execution_Environm…] > As part of this defect submission, a fix with the changes to correct this issue has been created in my GitHub fork and is available to be reviewed and to be included in the next release of the slf4j projects. The GitHub fork URL is: [https://github.com/larsmir/slf4j] The specific commit, 928ab902187ebdc78b2262214bd2cb4c36c18a9a, that makes the changes is located at: [https://github.com/larsmir/slf4j/commit/928ab902187ebdc78b2262214bd2cb4c36c…] > Thank you. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-439) OSGi dependency on CAL10N not optional
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-439?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-439. ------------------------------ Resolution: Fixed Fixed in [commit 603ae2cb226|https://github.com/qos-ch/slf4j/commit/603ae2cb226] > OSGi dependency on CAL10N not optional > -------------------------------------- > > Key: SLF4J-439 > URL: https://jira.qos.ch/browse/SLF4J-439 > Project: SLF4J > Issue Type: Bug > Components: slf4j-ext > Affects Versions: 1.7.25 > Reporter: Mike Mansell > Assignee: Ceki Gülcü > Priority: Minor > Fix For: 1.8.0-beta5 > > > SLF4J-369 makes the CAL10N library optional from a Maven dependency point-of-view. However, it does not make it optional from an OSGi dependency point-of-view. The MANIFEST.MF should have a corresponding optional entry added: > {code:java} > ch.qos.cal10n;version=0.8.1;resolution:=optional{code} > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0