Hi

On Sun, Jan 17, 2021 at 10:28 AM ski n <raymondmees...@gmail.com> wrote:
>
> Hi all,
>
> In 2020 there was a clear roadmap towards 3.7.0. This roadmap focussed on
> modularization and performance, especially useful in microservices and
> cloud functions.
>
> Now I wonder what the roadmap of 2021 will be and what the future of Camel
> brings.
>

There is not like that with a new calendar year that the Camel project shifts
 focus and comes up with a new set of goals, than the previous year.

It's a continued evolution with a steady release stream.


> I made 12 questions on the Camel ecosystem to think about this topic:
>
>
> 1) Management DSL
>
> Camel has always had the Java DSL. One of the last additions of this DSL is
> the EndpointDSL. Not everything can be done with the DSL yet. Will there
> also a Management DSL where you can configure and manage context and route?
>

Not everything has to be a DSL. They require extra effort to maintain, document,
and then there is "one more way of doing X" problem.


> 2) Ease of use
>
> One of the strongest points of Camel is its ease of use. Are there ideas to
> make it even more high level, towards citizens integrators?
>

Camel is aimed at developers and it's not within the scope of being a
higher level integration product / system
for non-developers such as citizen users, sys admins etc.

That said such products can be built on top of Camel such as Syndesis
/ Fuse Online,
and other products (some are listed in the Camel users stories).



> 3) Performance
>
> 3.x focussed on the memory footprint and performance of core Camel. Will
> this focus shift towards components. For example
> the 10 most used componets (file, ftp, sjms, kafka for example). Maybe
> based on Maven statistics.
>

Performance and low footprint will keep being a priority, as it's
getting increasingly required by modern cloud computing and workloads,
where you "pay by use", and don't have big datacenters with 98% idle
CPUs sitting doing nothing.

And yes beyond the core itself then some widely used components is a
goal as well.
We have an effort to improve their startup by moving logic to
init/build phase etc.
That is general for all the components.


> 4) GraalVM
>
> Will GraalVM native images with ahead of time compilation will be supported.
>

This is already supported and all work related to this is in the realm
of the camel-quarkus project.

This has had a huge impact on core also, as we have done alot of
effort to make core reflection free,
and fast startup, and minimal footprint, and modular to make dead code
elimination much more effective.

And on top of that Quarkus in JVM mode does a lot of built time
optimizations that dramatic reduce JVM foorprint
so you have a double win, and dont have to be 100% graal to get there.



> 5) Java 17
>
> In september 2021 the new LTS for Java comes out. Will the team especially
> target this release or will it first support Java 15?
>

Yes Camel will support Java 17 but possible not right away when Java 17 is GA.
But we do CI builds on the latest Java version such as 15.

But only the LTS versions of Java are officially going to be supported.

> 6) DSL Export
>
> With DumpToXML it's possible to export a route in XML format. Will there
> also a DumpToDSL?
>

No that is not a goal.

> 7) jOOr I
>
> Will Csimple eventually replace simple?
>

No not in the short run. csimple is not 100% replecable by simple, as
it requires more type information when doing OGNL method calls.
simple does dynamic runtime discovery with reflection, where as
csimple is compiled and therefore need type ahead information.

Also simple is widely in use.

But for users that want low foorprint then csimple is hopefully going
to be great. Its still new and we will continue improve it over the
next number of releases.
There is not yet support for nested functions (hard to implement, and
requires a parser rewrite).



> 8) jOOr II
>
> The jOOR language allows using Java code in a Camel expression. From an end
> user perspective, why don't just use .java() like .groovy()?
>

Because Java gives false impression that its 100% Java and you can do
whatever you can do in Java.
There are some limitations, and potential classloading issues.

But for small java code / snippets / scripts then its great.

But the name java would give the wrong impression at this moment.

> 9) jOOr III
>
> Is it/will it be also possible to run a complete Camel route written as
> Java DSL through jOOr? (loading from a file with contains the Java DSL for
> example)
>

See prev, that is not the intention. Its best to do coding first and
have it compiled with your application,
and not at runtime, where compilation errors can happen. Its also
harder to debug, and whatnot.



> 10) ServiceMix is end-of-life. Will it get a replacement project (Syndesis
> for example)? Will Syndesis be part of the Camel ecosystem like CamelK or
> KafkaConnector?
>

No. Syndesis has its own community.
Also I previously talked about Camel is intended for developers, and
not a higher level product for citizen users.


> 11) CamelK and Syndesis?
>
> Will it be possible to run CamelK code within Syndesis? Seems like a great
> combination?
>

Yes CamelK is going to play a major role, and be the preferred choice
for any integration on the cloud (aka kubernetes).


> 12) CamelK
>
> Will it be possible to call CamelK programmatically from Java (instead of
> use client written in Go)?
>

CamelK in go is the kubernetes operator and the CLI.
What ends up running as Camel routes is standard Camel in Java
(camel-quarkus as the runtime).

CamelK uses standard Kubenetes APIs (eg CRDs). So you can from Java
call the k8s API server and manipulate CRDs
to have the CamelK operator react upon those changes.

But the runtime of Camel K that runs your Camel routes are 100%
standard Camel on Java.

> Final note:
>
> Well these are just question on a sunday morning :)These 12 questions are
> not meant as user questions that need to be answered, but more as
> discussion points for the user community for the future of Camel. Hope to
> read the thoughts from devs and other users on making Camel even faster and
> easier to work with. BTW thanks very much for all the achievements and hard
> word on Camel in the strange year 2020.
>
> Kind regards,
>
> Raymond



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Reply via email to