Hello,
Jbit seems quite promising.
Really nice work from gnodet as always.
-1 for this one.
Even though java has new features, most features are basically in terms of
expressions enhancements which enables most expressive coding. ( there are
various jsr s but this is how i personally and simply
Fwiw, I've been investigating translating jdk 14 bytecode into jdk 8
compatible bytecode.
There are various changes in the JDK:
* new methods: the tool can point to different implementations for the
newly added methods
* var keyword / switch expressions : this require no change in the
bytecode
We need a consensus. So discussion is fine. I proposed a formal vote as it is a
great way to have a clear evaluation of the consensus.
As we are potentially talking about code modification, vote is possible (lazy
consensus):
https://www.apache.org/foundation/voting.html
We could agree on the beginning of 2021/end of 2020 for dropping JDK 8, I
don't think a formal vote is needed for this.
Il giorno mer 1 lug 2020 alle ore 09:48 Omar Al-Safi ha
scritto:
> Yeah that is great! +1
>
> Thanks JB!
>
> On Wed, Jul 1, 2020 at 9:46 AM Jean-Baptiste Onofre
> wrote:
>
>
Yeah that is great! +1
Thanks JB!
On Wed, Jul 1, 2020 at 9:46 AM Jean-Baptiste Onofre wrote:
> Agree. I would start a formal vote to propose dropping Java8 in Jan 2021,
> it would be clear for everyone.
>
> Regards
> JB
>
> > Le 1 juil. 2020 à 09:44, Omar Al-Safi a écrit :
> >
> > True,
Agree. I would start a formal vote to propose dropping Java8 in Jan 2021, it
would be clear for everyone.
Regards
JB
> Le 1 juil. 2020 à 09:44, Omar Al-Safi a écrit :
>
> True, Quarkus is more of a concern and from the discussion so far in the
> Quarkus mailing list, change could happen for
True, Quarkus is more of a concern and from the discussion so far in the
Quarkus mailing list, change could happen for them as well, therefore we
can delay dropping Java 8 only for a specific time frame to allow some
buffer.
But we have to agree now that we want to *drop* Java 8 and move to either
Personally I see only Quarkus decision as a concern, we can review the
timeline for dropping the Java 8 support.
I do believe that is almost impossible to have a codebase working on Java
8, 11 and 14 and the more time we wait to drop java 8 much more it will be
the work needed to support Java 14
I think I have misread the term "LTS" in the previous discussions. In my
mind, long term support is a bit more than 12 months... I don't think it's
a good idea to only support our LTS release for a year and drop the
previous JDK at the same time. One or the other is fine, but both... Given
the
My point is more about the "form". I’m not against, but it seems we have
concerns from several people now. So, even if it has been discussed, maybe we
didn’t do a vote or having formal vote.
Anyway, if you think it’s good enough from a community perspective, I’m fine
with that, and again agree
It has been already discussed and it's been reported in blog post and
everywhere. It has been said early enough for sure.
--
Andrea Cosentino
--
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: ancosen1...@yahoo.com
Twitter:
I think we are all agree about that. But it should be discussed and announce
early enough.
Today, I don’t think we really leverage JDK 9+ stuff.
Regards
JB
> Le 30 juin 2020 à 13:49, Omar Al-Safi a écrit :
>
> My question would be, until when we will need to keep Java 8? I mean sure,
> given
I'd say that we'll have the same discussion for Java 14, hopefully not for
keeping Java 8 but maybe for Java 11 so I think what we need to define is
the policy, rather than the specific version.
---
Luca Burgazzoli
On Tue, Jun 30, 2020 at 4:56 PM Guillaume Nodet wrote:
> Oh, I wasn't even
Oh, I wasn't even considering it if it can't be done in a single automated
maven run.
I haven't checked with latest maven plugins, but I was more thinking about
the cost of managing multiple versions of the same source file and how IDE
can support those.
See
Also I see some discussion in the Quarkus mailing list that shares the idea
that at some point we have to upgrade and not to restrict ourselves with
the constraint of supporting older releases. Change has to happen at some
point.
Therefore, if Quarkus is the only obstacle, then I think the best we
I don't know if it's feasible, we are already demanding a lot of work to
the release manager and I guess going through the multi release jar
approach will be much more troublesome.
Il giorno mar 30 giu 2020 alle ore 14:14 Guillaume Nodet
ha scritto:
> We could try using the multi-release jar
We could try using the multi-release jar feature in order to leverage new
JDK 11 or JDK 14 features without completely dropping JDK 8, but that's
definitely more work. I haven't seen many projects using it yet, so not
sure how that's manageable from a development perspective.
Le mar. 30 juin
My question would be, until when we will need to keep Java 8? I mean sure,
given the current circumstances, it might make sense to delay dropping Java
8 only for some time, but honestly would be nice if we can embrace the new
change and massive efforts that are being brought into Java to have
I think that unless someone "big" in the OSS makes a move, most libraries
will stay with Java 8 till they are forced so I guess someone should be
brave and make the move.
---
Luca Burgazzoli
On Tue, Jun 30, 2020 at 12:57 PM Peter Palaga wrote:
> On 30/06/2020 09:29, Jean-Baptiste Onofre
I don't think that migrating to a new version also means that we need to
embrace every new feature automatically but that we can use them when it
makes sense but staying with an older version means that we can't use them
in any case.
---
Luca Burgazzoli
On Mon, Jun 29, 2020 at 10:23 PM
On 30/06/2020 09:29, Jean-Baptiste Onofre wrote:
Agree, I think we should be very careful about communication.
It’s the same about EOL branch/release. Actually EOL doesn’t really exist at
Apache: anyone can fix/change an old branch and cut a release on it.
So, I fully understand the purpose,
Agree, I think we should be very careful about communication.
It’s the same about EOL branch/release. Actually EOL doesn’t really exist at
Apache: anyone can fix/change an old branch and cut a release on it.
So, I fully understand the purpose, but I think we should be more "flexible"
and
Note that we changed a bunch of lambda expressions back to anonymous
classes a few months ago, so trying to get to the latest is not always the
best choice.
I'm not sure we need to drop Java 8 now. We can defer that decision until
we have more incentive I think.,
Le lun. 29 juin 2020 à 18:01,
On 29/06/2020 11:59, Peter Palaga wrote:
On 29/06/2020 07:29, Claus Ibsen wrote:
Hi
On Sun, Jun 28, 2020 at 4:28 PM Peter Palaga wrote:
Hi Claus,
we have announced a similar move for Camel Quarkus some time ago. We did
that based on a similar Quarkus announcement [1]. But when I was about
On 29/06/2020 07:29, Claus Ibsen wrote:
Hi
On Sun, Jun 28, 2020 at 4:28 PM Peter Palaga wrote:
Hi Claus,
we have announced a similar move for Camel Quarkus some time ago. We did
that based on a similar Quarkus announcement [1]. But when I was about
to perform the necessary changes, it
> On Sun, Jun 28, 2020 at 4:28 PM Peter Palaga wrote:
> > Requiring Java 11+ API on the Camel side would put Camel Quarkus in a
> > bit uncomfortable position: unlike all other extensions offered via
> > code.quarkus.io, our extensions would not work on Java 8 in JVM mode.
Maybe that's even good
Hi
On Sun, Jun 28, 2020 at 4:28 PM Peter Palaga wrote:
>
> Hi Claus,
>
> we have announced a similar move for Camel Quarkus some time ago. We did
> that based on a similar Quarkus announcement [1]. But when I was about
> to perform the necessary changes, it turned out that Quarkus got some
>
Hi Claus,
we have announced a similar move for Camel Quarkus some time ago. We did
that based on a similar Quarkus announcement [1]. But when I was about
to perform the necessary changes, it turned out that Quarkus got some
pushback from the users and thus they abandoned the plan without
ah yeah ending june 2021 of course
fre. 26. jun. 2020 kl. 18.14 skrev Alex Dettinger :
> Thanks for sharing Claus :)
> Is the support ending at june 2021 ? Or maybe I miss something ?
>
> On Fri, Jun 26, 2020 at 10:23 AM Claus Ibsen
> wrote:
>
> > Hi
> >
> > Just a heads up that from Camel 3.5
Thanks for sharing Claus :)
Is the support ending at june 2021 ? Or maybe I miss something ?
On Fri, Jun 26, 2020 at 10:23 AM Claus Ibsen wrote:
> Hi
>
> Just a heads up that from Camel 3.5 onwards we will drop Java 8 support.
>
> So this means that minimum Java version is now Java 11.
> We are
Hi
Just a heads up that from Camel 3.5 onwards we will drop Java 8 support.
So this means that minimum Java version is now Java 11.
We are also working on adding support for Java 14, but it may take a
few releases, but its planned for the next LTS 3.7 release to have
both Java 11 and 14 as
31 matches
Mail list logo
