New features are:

• Renamed getters and setters of DefaultRequestResponseBus for consistency. This is not compilation compatible with 1.0.0, but the changes are trivial.
  
  
• MultiThreadedListenerObjectExecutionStrategy no longer spawns a Thread if there is only 1 ListenerObject to be executed.
  
  
• AbstractClassBasedListenerObjectCreationStrategy and its subclasses now support excluding classes from scanning when entire packages are scanned.
  
  
• ObjectBasedListenerObjectCreationStrategy and its subclasses now support notification upon listener creation.
  
  
• CachedListenerObjectRetrievalStrategy was added, for improved performance when retrieving ListenerObjects.
  
  
• Improved documentation and javadoc.

Over the next months, RRiBbit 2.0.0 will be developed, which will add remoting over RMI. This will provide an extremely simple way of communicating with another server, by enabling you to call Listeners that run on other machines, saving you from having to use cumbersome text-based methods such as SOAP or JSON. RRiBbit Remoting will later be extended with support for JMS and possibly other protocols.

After checking your website for a good 5 minutes (what journalists would call a 'thorough investigation' :), it seems the main points here are:

- declaring developing to interfaces as bad practice

- using string constants and annotations to dispatch method calls

While I do see the power of this, especially for larger projects the benefits are doubtful. Take debugging and tracing: Don't underestimate the power of an Eclipse 'Open Call Hierarchy'.

This is such an immensely useful functionality that undermining it with dynamic dispatches is a huge, huge sacrifice. It will force your developers on an expensive hunt for 'who is calling me'.

Hello Jochen!

Thanks for your comment! I agree with you completely and that's why a RRiBbit eclipse plugin is very much on the agenda. It will make the "call hierarchy" visible for RRiBbit calls, so that the main problem of RRiBbit will be addressed.

Jochen Bedersdorfer is right, I can't see any point to this "framework" for any production application. Besides being nowhere near standard, it seems to promote bad practise like firing method calls from string references :-/ Can anyone tell us if we're missing something?

In Java development, we use Strings to identify a lot of things. In GWT and Wicket, 2 of the most popular front end frameworks, hardcoded Strings are used to match components from the Java code to components from the HTML. And in the JPA specification, hardcoded Strings are used to identify named queries. In both cases, errors will only be found after Java compilation.

The Spring Framework was no industry standard either when it was invented, nor was dependency injection. Now everyone uses it. Every new approach starts out as an idea and is never an industry standard right away. And with every new approach, most people will be against it :-)

Also, a typical characteristic of eventbus based programming is that you don't care who "catches" the events. The same applies to RRiBbit. Note that you don't have to use RRiBbit for every single method invocation. You can for example, use regular method calls for inner-module calls and RRiBbit calls for cross-module calls, to keep the modules fully independent.

yes you are missing the point, and no I have not even visited their web-site yet so I'm just guessing, but look what I am doing just sending some strings to somewhere else and there might be an answer or there might not be... it might be usefull or not, proably depends on where I send it to and what I send...  now that is a smart paradigm but at the same time not vastly different from any other RMI, web-service, REST, JMS or other type of protocol, maybe just a little bit different, a bit more dynamic and maybe simpler and more elegant. But then when you are into Spring and Hibernate you are probably into doing simple things overly complicated...

this is very insightful opinion about RRiBbit 1.1.0

vintage celebs