From rory.odonnell at oracle.com Wed Mar 20 09:57:17 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 20 Mar 2019 08:57:17 +0000 Subject: [slf4j-dev] Release Announcement: General Availability of Java 12 / JDK 12 Message-ID: <46b53b6e-93c7-dd15-8e94-92fa0270d389@oracle.com>   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) 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 in this build -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply-jira at qos.ch Mon Mar 25 09:20:04 2019 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Mon, 25 Mar 2019 09:20:04 +0100 (CET) Subject: [slf4j-dev] [JIRA] (SLF4J-371) Support the lambda expression in the Logger In-Reply-To: References: Message-ID: [ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19452#comment-19452 ] 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 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) From noreply-jira at qos.ch Mon Mar 25 09:51:03 2019 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Mon, 25 Mar 2019 09:51:03 +0100 (CET) Subject: [slf4j-dev] [JIRA] (SLF4J-371) Support the lambda expression in the Logger In-Reply-To: References: Message-ID: [ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19453#comment-19453 ] 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 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) From rory.odonnell at oracle.com Fri Mar 29 12:13:30 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 29 Mar 2019 11:13:30 +0000 Subject: [slf4j-dev] JDK 13 - Early Access build 14 is available Message-ID: <8d074041-2eec-f2ee-fd9c-82fabd0f6ab5@oracle.com> 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 . * Changes in this build * 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 , 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 at openjdk.java.net *Quality Outreach report for **March 2019* * The report for March 2019 is available here * Thanks to all those contributed ! *Recent Blog:* 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: