September 2018 - slf4j-dev - mailman3.qos.ch

Release Announcement: General Availability of JDK 11
by Rory O'Donnell 26 Sep '18

26 Sep '18

Hi Ceki, *1) Release Announcement: General Availability of JDK 11 * * JDK 11, the reference implementation of Java 11 and the first long-term support release produced under the six-month rapid-cadence release model [1][2], is now Generally Available. * GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/11 This release includes seventeen features: * 181: Nest-Based Access Control <http://openjdk.java.net/jeps/181> * 309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309> * 315: Improve Aarch64 Intrinsics <http://openjdk.java.net/jeps/315> * 318: Epsilon: A No-Op Garbage Collector <http://openjdk.java.net/jeps/318> * 320: Remove the Java EE and CORBA Modules <http://openjdk.java.net/jeps/320> * 321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321> * 323: Local-Variable Syntax for Lambda Parameters <http://openjdk.java.net/jeps/323> * 324: Key Agreement with Curve25519 and Curve448 <http://openjdk.java.net/jeps/324> * 327: Unicode 10 <http://openjdk.java.net/jeps/327> * 328: Flight Recorder <http://openjdk.java.net/jeps/328> * 329: ChaCha20 and Poly1305 Cryptographic Algorithms <http://openjdk.java.net/jeps/329> * 330: Launch Single-File Source-Code Programs <http://openjdk.java.net/jeps/330> * 331: Low-Overhead Heap Profiling <http://openjdk.java.net/jeps/331> * 332: Transport Layer Security (TLS) 1.3 <http://openjdk.java.net/jeps/332> * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) <http://openjdk.java.net/jeps/333> * 335: Deprecate the Nashorn JavaScript Engine <http://openjdk.java.net/jeps/335> * 336: Deprecate the Pack200 Tools and API <http://openjdk.java.net/jeps/336> 2) Quality Outreach Report for September 2018 is available* * * Quality Outreach report September 2018 *Thanks to everyone who contributed to JDK 11 by downloading and testing the early-access builds. In particular the following developers who logged **18 issues in the JDK Bug System.* * Netty * Eclipse Jetty * Apache Lucene * JUnit5 * Apache Tomcat * Apache Ant * Apache POI * AssertJ * Eclipse Collections * Byte Buddy * RxJava 3) JDK 12 EA build 12, under both the GPL and Oracle EA licenses, are now available at http://jdk.java.net/11 . * Schedule , Status & Features o http://openjdk.java.net/projects/jdk/12/ * Release Notes: o http://jdk.java.net/12/release-notes ** Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

1 0

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

25 Sep '18

Alexander Yevsyukov created SLF4J-445: ----------------------------------------- Summary: 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: SLF4J developers list 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-420) Make a release with Automatic-Module-Name
by QOS.CH (JIRA) 13 Sep '18

13 Sep '18

[ https://jira.qos.ch/browse/SLF4J-420?page=com.atlassian.jira.plugin.system.… ] Varun Nandi commented on SLF4J-420: ----------------------------------- Hi, Any updates? Can you atleast let us know when you are planning to GA a version that is compatible with Java 9 module system. Our GA is blocked by this issue. If we depend on 1.7.26, the module name is derived from the jar. Then if you change the module name in 1.8, all our customers will be broken. I see following 2 options: 1) Release a GA version of 1.8.x with Java module info 2) Release a patch version on top of 1.7.26 with "Automatic-Module-Name" in the manifest See this article for better understanding of the issue: [https://dzone.com/articles/automatic-module-name-calling-all-java-library-m…] Thank you > 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.26 > > > 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

[JIRA] (SLF4J-444) Allow explicitly selecting a binding
by QOS.CH (JIRA) 07 Sep '18

07 Sep '18

Christopher Smith created SLF4J-444: --------------------------------------- Summary: Allow explicitly selecting a binding Key: SLF4J-444 URL: https://jira.qos.ch/browse/SLF4J-444 Project: SLF4J Issue Type: Improvement Affects Versions: 1.7.25 Reporter: Christopher Smith Assignee: SLF4J developers list The binding autoconfiguration in SLF4J is very handy, but it comes with a severe limitation in testing: Neither Eclipse nor IntelliJ can handle a test-scope exclude (e.g., Surefire's {{classpathDependencyExclude}}), and so for an end project (such as a Spring Boot application), it's impossible to run tests that use slf4j-test in the IDE. It would be very helpful for testing purposes if there were a way to specify (probably in a {{META-INF}} file) the preferred logger to use in the case of finding multiple bindings on the classpath. Then dropping an instruction in {{src/test/resources}} would allow tests to run with the test logger without tangling classpath issues into the run. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-443) Log4JLogger from commons-logging is absent in jcl-over-slf4j
by QOS.CH (JIRA) 07 Sep '18

07 Sep '18

Vitalii Diravka created SLF4J-443: ------------------------------------- Summary: Log4JLogger from commons-logging is absent in jcl-over-slf4j Key: SLF4J-443 URL: https://jira.qos.ch/browse/SLF4J-443 Project: SLF4J Issue Type: Improvement Components: jcl-over-slf4j Affects Versions: 1.8.0-beta2, 1.7.25 Environment: All Reporter: Vitalii Diravka Assignee: SLF4J developers list In the process of updating hadoop libraries in Apache Drill project I faced the following issue: java.lang.NoClassDefFoundError: org/apache/commons/logging/impl/Log4JLogger. hadoop-hdfs uses commons-logging library, but Drill uses jcl-over-slf4j and bans commons-logging. https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs… Looks like the presence of Log4JLogger class in org.apache.commons.logging.impl of jcl-over-slf4j could resolve the issue. https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j/src/main/java/or… -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 12 & JMC 7.0.0 Early Access builds are available
by Rory O'Donnell 07 Sep '18

07 Sep '18

Hi Ceki, *JDK 11 build 28 is our first JDK 11 Release Candidate [1] * * JDK 11 build 28 is available at : - jdk.java.net/11/ *JDK 12 Early Access build 10 is available at : - jdk.java.net/12/* * Release Notes for JDK 12 [2] * *JEPs integrated to JDK 12:* o 325: Switch Expressions (Preview [3]) * *JEPs proposed to target JDK 12:* o 326: Raw String Literals (Preview [3]) *FOSS bug fixes in recent builds.* * Apache Ant - JDK-8209965<https://bugs.openjdk.java.net/browse/JDK-8209965>(b09) *Other important fixes in JDK 12* * Disabled all DES TLS Cipher Suites (JDK-8208350 <https://bugs.openjdk.java.net/browse/JDK-8208350>) o DES-based TLS cipher suites are considered obsolete and should no longer be used *JMC 7.0.0 Early Access build 04 is available at :- **http://jdk.java.net/jmc/* * Overview - summary [4] * These early-access, open-source builds are provided under the Universal Permissive License, version 1.0<https://opensource.org/licenses/UPL>. * Feedback via the http://bugreport.java.com/ o Be sure to include jmc application Build id from "Help" - "About JDK Mission Control". Rgds, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001844.html [2] http://jdk.java.net/12/release-notes [3] http://openjdk.java.net/jeps/12<http://jdk.java.net/12/release-notes> [4] https://download.java.net/java/early_access/jmc7/core/common/docs/api/overv… -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

ConsoleLogger proposal: No more excuses for System.out.println()
by Tactonom Calendar 01 Sep '18

01 Sep '18

Please consider the following fork of SimpleLogger that is aimed to minimize the effort of using loggers for ad-hoc debugging instead of using System.out.println(). Source code and documentation are available at: https://github.com/alexander233/ConsoleLogger A jar file can be downloaded from http://www.inventivio.com/softblocks/slf4j-console-1.8.0-beta.jar ConsoleLogger adds the following features to increase ease of use: - Output is optimized to minimize clutter when logging to the console (short log messages, levels are single-character ('d' instead of 'DEBUG'), fixed-column width approach for logger name, level, and time (optional) ensures that the actual content of the log messages starts at the same character position in every line; warn and error are sent to error console, other levels are sent to system console). - Users don't need to worry about directory hell when configuring log files (for many developers this is a real source of confusion when switching to a logging framework). Instead, logger configuration is stored seamlessly via Java Preferences. A minimal GUI is embedded in the Jar file; users can double-click the jar file and specify the loggers (of course, configuration via properties files and from the command line is supported, too). - Logger configuration is quick and concise. Neither the GUI nor the properties files require long-prefixes such as 'org.slf4j.consolelogger.' to which the fully qualified class name of the logger needds to be appended. Loggers can often be specified by writing only the short class name into a line (=> the package name will be 'inherited' from prior line; in the same way, the level can be omitted (if not specified it is also taken from earlier lines). This makes the logger configuration much more easy to read and quicker to write. - String expansion of variables passed into a log message is improved to work around shortcomings of Java's toString() method. Double values are only printed with 6 decimals instead of the overly long, hard to read 17 decimals that the JRE often provides (0.052632 instead of 0.05263157894736842). Old Java Date values are much better formatted ("2017-09-29" instead of "Fri Sep 29 00:00:00 CEST 2017"). Similar improvements for a few other classes (Point, Rectangle, Color, etc.). Overall, I believe that these features should lower the barriers towards using the powerful Slf4j logging framework significantly and eliminate any reason left for ad-hoc debugging the old way with System.out.println(). Note: Windows users may get 2 misleading Preferences-related warning messages in their console at startup. This is a known JRE bug that has been fixed in JRE 9 and a simple workaround exists (see the end of the ReadMe on Github). Best regards, Alexander

1 0