Java 8 and Camel 3

[Ranx <br...@mediadriver.com>]

I'm not sure what the state of thought about Camel 3 is or where it is in its
development cycle or even if this is the correct place to post this but I've
thought about it some lately. There are a number of reasons I think Java 8
would be great for the next generation of Camel which I won't go into but
the primary one is the use of default methods on interfaces for
initializers.  This would allow the Camel core to be be comprised entirely
of interfaces, annotations, a bootstrap factory and an engine manager. 
Imagine a Splitter for  example:

public interface Splitter {

	public default Splitter init()
	{
		return EngineManager.initialize(Splitter.class.getName());
	}
	public default Splitter init()
	{
		return EngineManager.initialize(Splitter.class.getName());
	}
	
	public default Splitter init(String[] args)
	{
		return EngineManager.initialize(Splitter.class.getName(),args);
	}
...And o
}

When that is called it is unknown as to whether it is Spring, Blueprint,
Guice or SomethingNew engine under the covers.  The Camel components
themselves could then live in their own jar/bundle that the engines use. 
Perhaps all the engines use the same splitter implementation.  Perhaps one
of the engines doesn't work well with the implementation.  It would then be
free to implement its own version of the splitter.  The end user never works
directly with an implementation and as long as the component conformed to
contract it wouldn't matter.

Hiding Internals
Registry mechanics, component implementations, engine specific annotations,
etc. are all hidden away in this manner.  Users never become coupled to
underlying implementations.  In fact, I'd go so far as to say that engines
should return proxies to the interfaces of the components they are
returning.  The end user couldn't even cast to the concrete implementation
if they wanted to.  That would depend on performance, of course, but that
would be highly desirable and effect a complete encapsulation.

Unified Testing
Because all engines would cough up a component of the same interface type a
unified set of behavioral and performance tests could be written that would
test components regardless of the underlying engine.  This opens Camel up to
the possibility of folks creating new engines that could be certified at
different compliance levels.  For example, when the project starts up the
various current incarnations of Spring, Blueprint, etc could be repackaged
and tested against that suite of tests and then accepted into incubator
status.  Another more rigorous set of tests could be created which would
have to be passed in order to be accepted as fully versioned.





--
View this message in context: http://camel.465427.n5.nabble.com/Java-8-and-Camel-3-tp5777547.html
Sent from the Camel Development mailing list archive at Nabble.com.