gt;> I had thought we updated to java 8 for 2.13.0, but I may be mistaken.
>>
>
> You could very well be right but I do not see it here:
> https://logging.apache.org/log4j/2.x/changes-report.html#a2.13.0
>
> G
>
>
>>
>> -ck
>>
>> On Fri, Apr
On Fri, Apr 17, 2020 at 8:53 AM Carter Kozak wrote:
> I had thought we updated to java 8 for 2.13.0, but I may be mistaken.
>
You could very well be right but I do not see it here:
https://logging.apache.org/log4j/2.x/changes-report.html#a2.13.0
G
>
> -ck
>
> On Fri, Apr
I had thought we updated to java 8 for 2.13.0, but I may be mistaken.
-ck
On Fri, Apr 17, 2020, at 08:49, Gary Gregory wrote:
> Now that 2.x is on Java 8 (aka "The Ocho
> <https://www.youtube.com/watch?v=8414uArsBOs>"), I think the next release
> label should be 2.14 instead of 2.13.2.
>
> Gary
>
Now that 2.x is on Java 8 (aka "The Ocho
<https://www.youtube.com/watch?v=8414uArsBOs>"), I think the next release
label should be 2.14 instead of 2.13.2.
Gary
un, 2 Jun 2019 at 13:59, Ralph Goers wrote:
>
> I don’t understand. Future 2.x releases will still be compatible with Java 7.
> Maven just has to be run using Java 8. Due to toolchains all the compiles
> will still be done using the Java 7 compiler.
>
> > On Jun 2, 2019, at
I don’t understand. Future 2.x releases will still be compatible with Java 7.
Maven just has to be run using Java 8. Due to toolchains all the compiles will
still be done using the Java 7 compiler.
> On Jun 2, 2019, at 10:55 AM, Matt Sicker wrote:
>
> Is there a last workin
Is there a last working version compatible with java 7 that we can use for
our 2.x releases?
On Sat, Jun 1, 2019 at 21:59, Ralph Goers
wrote:
> In testing on Windows I suddenly discovered that the support I added for
> Spring Cloud Config now requires that the build run using Java 8. T
In testing on Windows I suddenly discovered that the support I added for Spring
Cloud Config now requires that the build run using Java 8. This is because the
Maven spring-boot-plugin requires Java 8. Since the build uses toolchains
extensively I don’t think this will create any problems as all
Hello everybody,
I am Fabio Palomba, a researcher at the University of Zurich (Switzerland).
Together with my team, we are currently looking into architectural changes that
APIs have made to accomodate the usage of Java 8 lambda features. We isolated
Spring, Guava, Mockito, JUnit, Hibernate
> On Nov 5, 2018, at 2:33, Gary Gregory wrote:
>
> Some notes.
>
> Java 8 provides a java.time package. It would be nice to reuse it instead
> of keeping our own Java 7-based code.
>
> We provide a MutableInstant class akin to the final immutable thread-safe
&
v 4, 2018, at 10:33 AM, Gary Gregory wrote:
>
> Some notes.
>
> Java 8 provides a java.time package. It would be nice to reuse it instead
> of keeping our own Java 7-based code.
>
> We provide a MutableInstant class akin to the final immutable thread-safe
> java.time.Insta
Some notes.
Java 8 provides a java.time package. It would be nice to reuse it instead
of keeping our own Java 7-based code.
We provide a MutableInstant class akin to the final immutable thread-safe
java.time.Instant class.
Our class is not interchangeable with java.time.Instant but it could be
658a0) we start to move classes and rename
>>>>>> packages - this would better fit in a 3.0 release where users would
>>>> expect
>>>>>> some breaking changes in core.
>>>>>>>
>>>>>>>> On Tue, Jan 30, 2018 at 2:37
>> expect
>>>>> some breaking changes in core.
>>>>>>
>>>>>>> On Tue, Jan 30, 2018 at 2:37 AM, Matt Sicker
>>> wrote:
>>>>>>> An SPI for log4j-core is one thing (also plugin factory cleanup). I'
oesn't require a special
>>>> plugin
>>>>>> to merge them together when shading jars (would be better to just be
>>>> cat'd
>>>>>> together like a META-INF/services/ file). Removal of deprecated APIs
>>>> would
>>&
gether when shading jars (would be better to just be
> >> cat'd
> >>>> together like a META-INF/services/ file). Removal of deprecated APIs
> >> would
> >>>> also be great.
> >>>>
> >>>> A 3.0 release also provide
ge them together when shading jars (would be better to just be
>> cat'd
>>>> together like a META-INF/services/ file). Removal of deprecated APIs
>> would
>>>> also be great.
>>>>
>>>> A 3.0 release also provides the ability to break AP
when shading jars (would be better to just be
> cat'd
> >> together like a META-INF/services/ file). Removal of deprecated APIs
> would
> >> also be great.
> >>
> >> A 3.0 release also provides the ability to break APIs entirely if there
> are
> >>
design decisions we found while incorporating GC-free logging
>> and other nifty performance improvements. Utilising Java 8, we also have
>> the ability to support fully non-blocking asynchronous APIs using
>> CompleteableFuture which is rather interesting to me as well (particular
st be cat'd
> together like a META-INF/services/ file). Removal of deprecated APIs would
> also be great.
>
> A 3.0 release also provides the ability to break APIs entirely if there are
> any awkward design decisions we found while incorporating GC-free logging
> and other nif
deprecated APIs would
also be great.
A 3.0 release also provides the ability to break APIs entirely if there are
any awkward design decisions we found while incorporating GC-free logging
and other nifty performance improvements. Utilising Java 8, we also have
the ability to support fully non-blocking as
I am neutral about moving to Java 8 soon.
We have just recently started to make a lot of package rename changes that
really belong in 3.0 and not in 2.11...
We should consider doing a 2.11 release from a commit before we started to
rename packages.
Then doing the modules split-off and clarifying
On Mon, Jan 29, 2018 at 10:27 AM, Gary Gregory
wrote:
> On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker wrote:
>
>> I'd be +1 for Java 8, but making a 3.0 release is a different story. For
>> that, I'd like to see a lot more than just the Java version increase.
>
On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker wrote:
> I'd be +1 for Java 8, but making a 3.0 release is a different story. For
> that, I'd like to see a lot more than just the Java version increase.
>
I think that a 3.0 would mark:
- A major change: Java 7 to Java 8
- The in
I'd be +1 for Java 8, but making a 3.0 release is a different story. For
that, I'd like to see a lot more than just the Java version increase.
On 29 January 2018 at 11:07, Gary Gregory wrote:
> +1 to Java 8 now and call the next release 3.0.
>
> Gary
>
> On Mon, Jan 29
+1 to Java 8 now and call the next release 3.0.
Gary
On Mon, Jan 29, 2018 at 10:03 AM, Ralph Goers
wrote:
> Ceki has started a poll to upgrade Logback to Java 8 -
> https://doodle.com/poll/s7n3wk59694pmnbs <https://doodle.com/poll/
> s7n3wk59694pmnbs>. The last poll I saw was
Ceki has started a poll to upgrade Logback to Java 8 -
https://doodle.com/poll/s7n3wk59694pmnbs
<https://doodle.com/poll/s7n3wk59694pmnbs>. The last poll I saw was in May of
last year that had Java 7 at about 30%.
https://plumbr.io/blog/java/java-version-and-vendor-data-analyzed-2017-e
argue that the translation from
> epochSeconds to epochMillis is duplication from java.time.Instant but it’s
> also not rocket science.
>
> We currently have limited formatting capabilities. We don’t offer
> nanosecond precision with any possible date/time format.
> With J
java.time.Instant but it’s also not rocket
science.
We currently have limited formatting capabilities. We don’t offer nanosecond
precision with any possible date/time format.
With Java 8 we could offer the power of DateTimeFormatter with nanosecond
precision. However, this powerful formatting
Hi Remko:
Curious: How much bending over backward are we doing with this new time
code by _not_ using Java 8?
Gary
Hi All,
FYI, I created a Java 8 epic in JIRA:
https://issues.apache.org/jira/browse/LOG4J2-2080
Gary
Github user garydgregory commented on the issue:
https://github.com/apache/logging-log4j2/pull/105
Fixed in Git master and tracked with
https://issues.apache.org/jira/browse/LOG4J2-2029
---
If your project is set up for it, you can reply to this email and have your
reply appear on Gi
Github user jvz commented on the issue:
https://github.com/apache/logging-log4j2/pull/105
No real plan to upgrade to Java 8 for at least another year or so I
believe. Too many people still depending on 7 as a baseline. It would be neat
if there were some creative way to support
Github user fabriziocucci commented on the issue:
https://github.com/apache/logging-log4j2/pull/105
Done!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, o
ert all Java 8 stuff and keep the entry API changes as you
suggested.
Out of curiosity, is there any plan to ditch Java 7 support?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enab
Github user garydgregory commented on the issue:
https://github.com/apache/logging-log4j2/pull/105
Our base requirement is still Java 7. So we cannot just yet take this whole
patch unless we split the examples into Java 7 and Java 8. I would like to take
the changes for the entry
GitHub user fabriziocucci opened a pull request:
https://github.com/apache/logging-log4j2/pull/105
Modernized (Java 8 style) markers examples
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/fabriziocucci/logging-log4j2 patch-1
.com/Lgq98MjF
> Scala API does not work with IBM Java 8 and Scala 2.12
> --
>
> Key: LOG4J2-1983
> URL: https://issues.apache.org/jira/browse/LOG4J2-1983
> Project: Log4j 2
>
Matt Sicker created LOG4J2-1983:
---
Summary: Scala API does not work with IBM Java 8 and Scala 2.12
Key: LOG4J2-1983
URL: https://issues.apache.org/jira/browse/LOG4J2-1983
Project: Log4j 2
Issue
[
https://issues.apache.org/jira/browse/LOG4J2-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal closed LOG4J2-1587.
--
> Build process should work on Jav
works on Java 8.
> Build process should work on Java 8
> ---
>
> Key: LOG4J2-1587
> URL: https://issues.apache.org/jira/browse/LOG4J2-1587
> Project: Log4j 2
> Issue Type: Improvement
>Affe
[
https://issues.apache.org/jira/browse/LOG4J2-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal reassigned LOG4J2-1587:
--
Assignee: Mikael Ståldal
> Build process should work on Jav
42 matches
Mail list logo
