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

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 30 Nov '18

30 Nov '18

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Peter-Josef Meisch commented on SLF4J-428: ------------------------------------------ I don't have a problem. When I created this issue and made the change in january 2018, the java compiler threw it up as an error. Now in java 11 it seems to be no problem anymore. > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta2, 1.8.0-beta3 > > Attachments: jpms-testcase.zip > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 30 Nov '18

30 Nov '18

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Gili commented on SLF4J-428: ---------------------------- Wait, having re-read [https://stackoverflow.com/a/36322692/14731] I don't see why you guys are having a problem. Highlighting the relevant bits: {quote}These character sequences are tokenized as keywords *solely where they appear as terminals* in the ModuleDeclaration and ModuleDirective productions (§7.7). {quote} Per my understanding, you don't need to use *to* as a terminal. It is in the middle of your ModuleDeclaration. Further, I created a sample project under Java 11 and I can't get a compiler error using "to" no matter what I do. I will try attaching it to this issue for your review. > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta2, 1.8.0-beta3 > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 12 build 22 is now available at : - jdk.java.net/12/
by Rory O'Donnell 30 Nov '18

30 Nov '18

Hi Ceki, *NOTE:- *The JDK 12 schedule <http://openjdk.java.net/projects/jdk/12/> rampdown phase 1 of the release is coming up in a few weeks on Dec. 13, 2018. ** *JDK 12 Early Access build 22 **is now available **at : - jdk.java.net/12/* * Release Note updates since last email * * o Build 21 - Deprecating the default keytool -keyalg value (JDK-8212003) o Build 21 - Change to X25519 and X448 encoded private key format (JDK-8213363) o Build 20 - New command-line flag for more extensive error reporting in crash logs (JDK-8211845) o Build 20 -Initial Value of user.timezone System Property Changed (JDK-8185496) * JEPs proposed for JDK 12 : o JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector(Experimental) <http://openjdk.java.net/jeps/189> o JEP 334: JVM Constants API <http://openjdk.java.net/jeps/334> o JEP 344: Abortable Mixed Collections for G1 <http://openjdk.java.net/jeps/344> o JEP 346: Promptly Return Unused Committed Memory from G1 <http://openjdk.java.net/jeps/346> * JEPs targeted to JDK 12, so far o JEP 230: Microbenchmark Suite <https://openjdk.java.net/jeps/230> o JEP 325: Switch Expressions (Preview) <http://openjdk.java.net/jeps/325> o JEP 326: Raw String Literals (Preview) <http://openjdk.java.net/jeps/326> o JEP 340: One AArch64 Port, Not Two <http://openjdk.java.net/jeps/340> o JEP 341: Default CDS Archives <http://openjdk.java.net/jeps/341> Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 30 Nov '18

30 Nov '18

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Gili commented on SLF4J-428: ---------------------------- I stand corrected. I found it (under the main section of keywords) at [https://docs.oracle.com/javase/specs/jls/se11/html/jls-3.html#jls-3.9] ... it is listed as a "restricted" word. Sorry for the false alarm. > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta2, 1.8.0-beta3 > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 30 Nov '18

30 Nov '18

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü reopened SLF4J-428: ------------------------------ to is a reserved keyword > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta2, 1.8.0-beta3 > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 30 Nov '18

30 Nov '18

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Peter-Josef Meisch commented on SLF4J-428: ------------------------------------------ _to_ was in Java 9 a restricted keyword; see [http://cr.openjdk.java.net/~mr/jigsaw/spec/java-se-9-jls-diffs.pdf,] section 3.9, or in short Mark Reinhold's answer in SO: [https://stackoverflow.com/questions/36322223/new-keywords-in-java-9|https:/….] and using it in a module name produced an error when Java 9 came out. > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta2 > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 29 Nov '18

29 Nov '18

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Gili commented on SLF4J-428: ---------------------------- Guys, Where do you see that `to` is a reserved word in Java 9? I looked everywhere, including the Java 11 language specification and as far as I can tell there is no such limitation. Further, I have no problem exporting module names containing `to` in `module-info.java`. Perhaps this change should be reversed? > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta2 > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-442) Integrate with java.lang.System.Logger/LoggerFinder (JEP 264)
by QOS.CH (JIRA) 18 Nov '18

18 Nov '18

[ https://jira.qos.ch/browse/SLF4J-442?page=com.atlassian.jira.plugin.system.… ] Nicolai Parlog commented on SLF4J-442: -------------------------------------- PS: I unsubscribed from the mailing list, but I still watch this issue, so if you reply here, I should get a notification. > Integrate with java.lang.System.Logger/LoggerFinder (JEP 264) > ------------------------------------------------------------- > > Key: SLF4J-442 > URL: https://jira.qos.ch/browse/SLF4J-442 > Project: SLF4J > Issue Type: New Feature > Environment: Java 9+ > Reporter: Nicolai Parlog > Assignee: Ceki Gülcü > Fix For: 2.0, 1.8.0-beta3 > > > [JEP 264: Platform Logging API and Service|http://openjdk.java.net/jeps/264] introduced a mechanism to Java 9 that allows third-party logging frameworks to handle JDK log messages (like those Swing produces; _not_ JVM messages). SLF4J should integrate with it. > There is already [a proof of concept|https://github.com/nicolaiparlog/slf4j/commit/e0c7780bdae254535a6e9…] -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-442) Integrate with java.lang.System.Logger/LoggerFinder (JEP 264)
by QOS.CH (JIRA) 18 Nov '18

18 Nov '18

[ https://jira.qos.ch/browse/SLF4J-442?page=com.atlassian.jira.plugin.system.… ] Nicolai Parlog commented on SLF4J-442: -------------------------------------- Hi Ceki, this has been open for a while. Should I prepare a pull request akin to the proof of concept? > Integrate with java.lang.System.Logger/LoggerFinder (JEP 264) > ------------------------------------------------------------- > > Key: SLF4J-442 > URL: https://jira.qos.ch/browse/SLF4J-442 > Project: SLF4J > Issue Type: New Feature > Environment: Java 9+ > Reporter: Nicolai Parlog > Assignee: Ceki Gülcü > Fix For: 2.0, 1.8.0-beta3 > > > [JEP 264: Platform Logging API and Service|http://openjdk.java.net/jeps/264] introduced a mechanism to Java 9 that allows third-party logging frameworks to handle JDK log messages (like those Swing produces; _not_ JVM messages). SLF4J should integrate with it. > There is already [a proof of concept|https://github.com/nicolaiparlog/slf4j/commit/e0c7780bdae254535a6e9…] -- 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) 16 Nov '18

16 Nov '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Matthias Kurz commented on SLF4J-371: ------------------------------------- {quote}Planned for the end of 2018. {quote} Ceki, what's the status? Only six more weeks left in 2018 ;) > 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