- slf4j-dev - mailman3.qos.ch

Fwd: investigation on the diffusion of innovation along with java releases
by Fernando Petrulio 12 Aug '19

12 Aug '19

Dear Developers, we are members of the ZEST research group (Zurich Empirical Software Engineering Team) based at the University of Zurich and the Delft University of Technology. We are conducting an investigation on the diffusion of innovations and we focus on the adoption of new language features. Our research is focused on how API producers adapt their interfaces to introduce support for Java 8’s lambdas. During the course of our investigation, we manually inspected SLF4J’s source code and documentation to understand whether Java’s lambdas have widespread adoption. We would like to have your feedback on our findings. Our study focuses primarily on Functional Interfaces and Lambda Expressions as these new features were introduced by the Java language and adopted the Java JDK API, as they reduce implementation complexity, improve readability, offer performance benefits and improve security contextualization. Our analysis showed that though SLF4J 2.0 did not explicitly introduce support for functional interfaces (e.g. by using the @FunctionalInterface annotation). We noticed that the API does provide compatibility with Java 8+ features, including lambda expressions (since the API’s build platform is now on JDK 1.8). We would like to better understand as to why no major change was necessitated to facilitate the usage of lambda expressions with the API. In most cases, developers choose to move to new releases to satisfy particular dependency requirements, to take advantage of new Java features (like streams and functional interfaces in the case of Java 8), or just to standardize their implementation to align the API with the Java JDK API. Can you provide us with more information about this? How did you and your team tackle the choice to change the version of Java supported? Which factors did you take into account when doing this? Are there any documented sources (e.g. Jira tickets, or issue tracker issues) about that discussion you can provide us with? Why were no explicit changes made to the interface to support lambda expressions? Are there any future plans in place to make larger changes to the API such that lambda expressions would be supported? We thank you for taking the time to answer our questions. If you would like to be posted about the results of this study, please let us know! Kind Regards, Fernando Petrulio. -- Fernando Petrulio Ph.D. Student - University of Zurich UZH Department of Informatics fpetrulio(a)ifi.uzh.ch

3 5

[JIRA] (SLF4J-467) Download link is broken
by QOS.CH (JIRA) 12 Aug '19

12 Aug '19

Gili created SLF4J-467: -------------------------- Summary: Download link is broken Key: SLF4J-467 URL: https://jira.qos.ch/browse/SLF4J-467 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 2.0.0-alpha0 Reporter: Gili Assignee: SLF4J developers list [https://www.slf4j.org/download.html] references 2.0.0-alpha1 but the download links are broken and in fact Maven only contains alpha 0. Please update these links to alpha 0. -- 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) 12 Aug '19

12 Aug '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-371: ---------------------------------- [~deanhiller] Please create a bug report regarding incorrect caller information. A test case would be most welcome. > 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: Ceki Gülcü > Fix For: 2.0.0-alpha1 > > > 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-466) EventRecordingLogger does not properly support the Throwable as last parameter
by QOS.CH (JIRA) 12 Aug '19

12 Aug '19

Wessel van Norel created SLF4J-466: -------------------------------------- Summary: EventRecordingLogger does not properly support the Throwable as last parameter Key: SLF4J-466 URL: https://jira.qos.ch/browse/SLF4J-466 Project: SLF4J Issue Type: Bug Components: Implementations Affects Versions: 1.7.x, 1.6.x Reporter: Wessel van Norel Assignee: SLF4J developers list Priority: Minor [As per FAQ if the last parameter is a Throwable it should be accepted as the thing you want the stacktrace off.|https://www.slf4j.org/faq.html#paramException] In the current EventRecordingLogger implementation, in case you pass two or more objects to the logger the (optional) last Throwable is seen as just an argument and not the actual Throwable. This issue also affects 1.8.x and 2.0.x. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-420) Make a release with Automatic-Module-Name
by QOS.CH (JIRA) 10 Aug '19

10 Aug '19

[ https://jira.qos.ch/browse/SLF4J-420?page=com.atlassian.jira.plugin.system.… ] Stephen Colebourne commented on SLF4J-420: ------------------------------------------ Lovely! And thanks for adding Automatic-Module-Name - it will allow a whole raft of other projects to move forward with modularization. > Make a release with Automatic-Module-Name > ----------------------------------------- > > Key: SLF4J-420 > URL: https://jira.qos.ch/browse/SLF4J-420 > Project: SLF4J > Issue Type: Task > Reporter: Gael Lalire > Assignee: Ceki Gülcü > Priority: Trivial > Fix For: 1.7.27 > > > You can make a release with Automatic-Module-Name with 1.7 version so it can load logback and have the package name you choose in 1.8 beta. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 13 is now in the Release Candidate Phase
by Rory O'Donnell 10 Aug '19

10 Aug '19

Hi Ceki, *JDK 13 is now in the Release Candidate Phase - if you are aware of any issues, please let us know. * Per the JDK 13 schedule [1], we are now in the Release Candidate phase. The stabilization repository, jdk/jdk13, is open for P1 bug fixes per the JDK Release Process (JEP 3) [2]. All changes require approval via the Fix-Request Process [3]. For more details, see Mark Reinhold's email to jdk-dev mailing list [4] * Milestone Schedule: o Initial RC Build 33 - Aug 9, 2019 o GAC - Aug 22, 2019 o GAR - Sept 5, 2019 o GA - Sept 17, 2019 *OpenJDK 13 build 33 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>. * Schedule, status & features o http://openjdk.java.net/projects/jdk/13/ * Release Notes o http://jdk.java.net/13/release-notes * Bug fixes reported by Open Source Projects : o JDK-8228764 - fixed in b32 -reported by Apache Tomcat **OpenJDK 14 *EA build 9 is now available at **http://jdk.java.net/14** * * 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>. * Release Notes o http://jdk.java.net/14/release-notes * JEPs targeted to JDK 14 o JEP 352 <http://openjdk.java.net/jeps/352> - Non-Volatile Mapped Byte Buffers * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B8%22%3A%3A…> * Bug fixes reported by Open Source Projects : o JDK-8227170 - fixed in b8 -reported by Apache Ant o JDK-8228485 - fixed in b8 -reported by JaCoCo o JDK-8222791 - fixed in b7 -reported by Apache Lucene *Project Panama Early-Access Builds* * Build jdk-14-panama+1-15 (2019/8/8) is available at 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>. Regards, Rory [1] https://openjdk.java.net/projects/jdk/13/#Schedule [2] https://openjdk.java.net/jeps/3 [3] https://openjdk.java.net/jeps/3#Fix-Request-Process [4] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003250.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-465) Document SLF4J JPMS module names
by QOS.CH (JIRA) 10 Aug '19

10 Aug '19

Ceki Gülcü created SLF4J-465: -------------------------------- Summary: Document SLF4J JPMS module names Key: SLF4J-465 URL: https://jira.qos.ch/browse/SLF4J-465 Project: SLF4J Issue Type: Task Reporter: Ceki Gülcü Assignee: SLF4J developers list Priority: Minor Fix For: 2.0.0-alpha1 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] 9752c8: specify jdk8 in travis
by Ceki Gulcu 10 Aug '19

10 Aug '19

Branch: refs/heads/1.7-maintenance Home: https://github.com/qos-ch/slf4j Commit: 9752c892fdf4d9d13ea020ac95fca2284ccbf68e https://github.com/qos-ch/slf4j/commit/9752c892fdf4d9d13ea020ac95fca2284ccb… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-08-10 (Sat, 10 Aug 2019) Changed paths: M .travis.yml Log Message: ----------- specify jdk8 in travis

1 0

[qos-ch/slf4j] 206449: 1.7.28 notes
by Ceki Gulcu 10 Aug '19

10 Aug '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 206449b67433696c3ab85a1d9f990468b7839dd7 https://github.com/qos-ch/slf4j/commit/206449b67433696c3ab85a1d9f990468b783… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-08-10 (Sat, 10 Aug 2019) Changed paths: M pom.xml M slf4j-site/src/site/pages/news.html Log Message: ----------- 1.7.28 notes

1 0

[JIRA] (SLF4J-420) Make a release with Automatic-Module-Name
by QOS.CH (JIRA) 10 Aug '19

10 Aug '19

[ https://jira.qos.ch/browse/SLF4J-420?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-420: ---------------------------------- [~jodastephen] Automatic module name changed in [commit 2a137469| https://github.com/qos-ch/slf4j/commit/2a1374691f394b85b] Release 1.7.28 should hit Maven Central momentarily. Thank you very much for following up on this issue by the way. > Make a release with Automatic-Module-Name > ----------------------------------------- > > Key: SLF4J-420 > URL: https://jira.qos.ch/browse/SLF4J-420 > Project: SLF4J > Issue Type: Task > Reporter: Gael Lalire > Assignee: Ceki Gülcü > Priority: Trivial > Fix For: 1.7.27 > > > You can make a release with Automatic-Module-Name with 1.7 version so it can load logback and have the package name you choose in 1.8 beta. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0