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

Release Announcement: General Availability of JDK 9
by Rory O'Donnell 21 Sep '17

21 Sep '17

Hi Ceki, Three items to share with you today * *JDK 9 General Availability * o GPL'd binaries from Oracle are available here: + http://jdk.java.net/9 o See Mark Reinhold's email for more details on the Release [1] + delivery of Project Jigsaw [2] * Are you JDK 9 Ready ? o The Quality Outreach wiki has been updated to include a JDK 9 Ready column. o If you would like us to identify your project as JDK 9 ready , please let me know and I will add it to the wiki. * Quality Outreach Report for September 2017**is available o many thanks for your continued support and welcome to the new projects! Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/announce/2017-September/000230.html [2] https://mreinhold.org/blog/jigsaw-complete -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-303) org.apache.log4j.Category need remove appender method
by QOS.CH (JIRA) 18 Sep '17

18 Sep '17

[ https://jira.qos.ch/browse/SLF4J-303?page=com.atlassian.jira.plugin.system.… ] Philippe commented on SLF4J-303: -------------------------------- Voted. We're having issues with an application which we migrated to logback but sadly use a paid library which use removeAllAppenders > org.apache.log4j.Category need remove appender method > ----------------------------------------------------- > > Key: SLF4J-303 > URL: https://jira.qos.ch/browse/SLF4J-303 > Project: SLF4J > Issue Type: Improvement > Components: log4j-over-slf4j > Affects Versions: 1.7.x > Environment: Operating System: Windows XP > Platform: PC > Reporter: weibo > Assignee: SLF4J developers list > > for dependency jar may contain below code: > logger.removeAllAppenders() > so please add all method of log4j.Category. > thanks -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Moving Java Forward Faster
by Rory O'Donnell 07 Sep '17

07 Sep '17

Hi Ceki, Oracle is proposing a rapid release model for Java SE going-forward. The high points are highlighted below, details of the changes can be found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2]. Under the proposed release model, after JDK 9, we will adopt a strict, time-based model with a new major release every six months, update releases every quarter, and a long-term support release every three years. The new JDK Project will run a bit differently than the past "JDK $N" Projects: - The main development line will always be open but fixes, enhancements, and features will be merged only when they're nearly finished. The main line will be Feature Complete [3] at all times. - We'll continue to use the JEP Process [4] for new features and other significant changes. The bar to target a JEP to a specific release will, however, be higher since the work must be Feature Complete in order to go in. Owners of large or risky features will be strongly encouraged to split such features up into smaller and safer parts, to integrate earlier in the release cycle, and to publish separate lines of early-access builds prior to integration. The JDK Updates Project will run in much the same way as the past "JDK $N" Updates Projects, though update releases will be strictly limited to fixes of security issues, regressions, and bugs in newer features. Related to this proposal, we intend to make a few changes in what we do: - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to make it easier for developers to deploy Java applications to cloud environments. We'll initially publish OpenJDK builds for Linux/x64, followed later by builds for macOS/x64 and Windows/x64. - We'll continue to ship proprietary "Oracle JDK" builds, which include "commercial features" [6] such as Java Flight Recorder and Mission Control [7], under a click-through binary-code license [8]. Oracle will continue to offer paid support for these builds. - After JDK 9 we'll open-source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds and the Oracle JDK. This will take some time, but the ultimate goal is to make OpenJDK and Oracle JDK builds completely interchangeable. - Finally, for the long term we'll work with other OpenJDK contributors to establish an open build-and-test infrastructure. This will make it easier to publish early-access builds for features in development, and eventually make it possible for the OpenJDK Community itself to publish authoritative builds of the JDK. Questions , comments, feedback to OpenJDK discuss mailing list [2] Rgds,Rory [1]https://mreinhold.org/blog/forward-faster [2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html [3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete [4]http://openjdk.java.net/jeps/0 [5]http://openjdk.java.net/legal/gplv2+ce.html [6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html [7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/ind… [8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html

1 0

[JIRA] (SLF4J-300) Alternative Android implementation
by QOS.CH (JIRA) 01 Sep '17

01 Sep '17

[ https://jira.qos.ch/browse/SLF4J-300?page=com.atlassian.jira.plugin.system.… ] Lee Griffiths commented on SLF4J-300: ------------------------------------- Note, the description is out of date: # The link has changed to [https://github.com/nomis/slf4j-android] # issue #204 referenced is SLF4J-195 > Alternative Android implementation > ---------------------------------- > > Key: SLF4J-300 > URL: https://jira.qos.ch/browse/SLF4J-300 > Project: SLF4J > Issue Type: Improvement > Components: slf4j-android > Affects Versions: 1.7.x > Environment: Operating System: All > Platform: All > Reporter: Simon Arlott > Assignee: SLF4J developers list > > I've got an alternative implementation of slf4j-android that you may be interested in: https://github.com/lp0/slf4j-android > It has various features and configurability (which makes it more of a logging framework than a simple adaptation layer) as the Android logging is quite basic. > It avoids the issue in #204 and caches calls to the native isLoggable() method. > Minimal configuration to specify a default logging tag is usually required to conform to existing Android conventions (using a minimal number of logger names). -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0