Page History

Camel 3.0 Ideas

Camel is now almost 6 years old and its second revision camel-2.x is more than 4.5 years old already. Camel is extremely mature, used in production by a large number of organizations from small to large and even governments. We feel like we really hit the initial target of simplifying integration. Camel's middleware abstraction api and the eip based routing brought a lot of positive feedback from users.

...

JDK support

(+1: claus, cmueller, mattrpav)
(-1: hadrian)

We should drop support for JDK6, and require JDK7 as minimim version. eg build and compile the release with JDK7.
We should aim to be compatible with JDK8.
(hz) Why? Isn't OpenJDK 6 still supported by RedHat and very much in use? Even Oracle's Java 6 is still in use. Maybe some bundles would require JDK7+, buy why not keep things like the api for instance still supported with Java 6? A strong argument may sway my opinion, but for now, I fail to see the reason.

(mattrpav) Consider JDK8 as the base. By the time Camel 3 is stable and ready for wide-spread use, the transitive deps will have caught up. A number of suggestions below target JDK8 features, and all would require an "add-on" approach to maintain JDK7 backward compat. 

JDK8 Java DSL

It would be good to have a camel-java8-dsl component that offers a JDK8 DSL which uses all the nice new stuff from JDK8 with higher order functions, closures, et all.
Though this may comes later in Camel 3.x when JDK8 is GA.
At least stuff like Predicate, Expression, AggregationStrategy etc. are "functional interfaces" (containing only one method) and Java 8 applications can implement them using lambdas. That's only a start, but it doesn't require a specific DSL.

...

• camel-bam
• camel-msv
• org.apache.camel.view from came-core

• dot maven generator

• ... (there could be other stuff to remove)

...

We could consider adding DSL syntax sugar for scheduling routes. For example currently you have to use Quartz or a ScheduledPollingConsumer which has the delay option. We could add DSL which has something like:

schedule().every(5).minute().pollFrom("xxx").to("yyyy")

...

We should consider tighten up the onException DSL a bit, for example to make it more clear that if you have processing steps in there, they only occur after the message has been exhausted. So maybe we need to have a onExhausted to make this clear

onException(IOException.class).maximumRedeliveries(3)
  .onExhausted().handled(true).to("log:ignoreMe");

...

Also currently you can do this:

onException(IOException.class).maximumRedeliveries(3)
  .handled(true);

...