Discussions

News: Enterprise Object Broker 1.0

  1. Enterprise Object Broker 1.0 (40 messages)

    After a more than a year of development, Enterprise Object Broker (EOB) has reached version 1.0. This Apache Avalon based open-source software offers another n-tier RPC solutions for Java. It is a bean server that mimics .NET style remoting, giving transparent distribution for Java objects via their interfaces.

    The EOB guys obviously aren't huge EJB fans:

    "Welcome to the post-J2EE era. This open source application server cherry picks the best from J2EE (Servlets) and completely ignores the arguble worst (EJB)."

    It is simple to develop for EOB.

     1) Code your model in interfaces and immutable beans (facade-like)
     2) Have just about any sort of normal implementation.
     3) Create a simple manifest & pakage into .ear-like .eob file.
     3) On the client-side lookup the interface via JNDI or bespoke means and use as you wish.

    EOB leverages Apache's AltRMI

    View EOB's Home Page: http://www.enterpriseobjectbroker.org

    Is this reinventing EJB? Is there a place for this type of framework?

    Threaded Messages (40)

  2. Enterprise Object Broker 1.0[ Go to top ]

    First of all: I haven´t used it and I didnt even know what it was exactly before reading this post and subsequently the EOB-site. I usually yawn at most news about different frameworks, but this is something that atleast got my interest.
    At least when it comes to replacing stateless session beans I think this might be a very competitive alternative in the future. The whole concept and coding of new objects is quite elegant and really seems what EJB should have been.

    This is something I will familiarize myself with more and see how it develops.
    Has anyone tried it out? Experiences of it, good and bad?
  3. Enterprise Object Broker 1.0[ Go to top ]

    The interface looks similar to the object remoting that was recently added to the JBoss 4.0 source tree. In the JBoss remoting, you package your object in a .aop file instead of an .eob file, and away you go.

    Apache calls their framework 'post-J2EE'. JBoss calls their's 'beyond J2EE.'

    When this many smart people are implementing next-gen remoting frameworks, it's a good sign that this probably will be part of J2EE someday. Are there any related JSR's?
  4. Enterprise Object Broker 1.0[ Go to top ]

    http://jcp.org/en/jsr/detail?id=160

    JMX Remoting.

    Steve
  5. Enterprise Object Broker 1.0[ Go to top ]

    I don't try it yet, just read the EOB's website, my first impression is it's a great idea, we always have a lot pain when we deal with EJBs, EOB's architecture seems much easier, simplier than EJBs'. That's great.

    But on the other hand, I think EOB still has a long way to go, compare with J2EE, we find:
    1. No transaction support, although we can use resource manager's transaction functionality, but having a global transaction manager API like JTA is very important for enterprise applications.

    2. No asynchronous messaging.
    3. I don't know if EOB can be interoperable with RMI-IIOP. I think this is a important feature, as well.

    4. Just in my opinion, it seems the whole Apache's Avalon-Phoenix server framework is not much easier to understand than EJB...perhaps it's because there is no enough documents for that.
  6. <quote from http://www.enterpriseobjectbroker.org >
    There is no distinction between 'local' and 'remote' objects. The developer does not have to consider whether the bean would be used locally or remotely. AltRMI is used to connect beans locally and remotely.
    </quote>

    EJB were designed with clear separation between remote and local invocation in mind. And I am completely agreed with that: developer MUST consider whether the bean would be used locally or remotely. However, amount of “plumbing” code in EJB seems to be unnecessary high, but with code generators like XDoclet it is not a problem at all.
    I would say that Session and Message Beans are just fine and do not need major rework. Entity Beans are good too, but unfortunately they were understood and used as direct object-relation mapping layer, when they should be one layer above OR mapping.
    IMO: EOB looks like another waste of resources. I would expect CORBA as a successor of EJB, because there is a solid theory behind…
  7. Entity Beans[ Go to top ]

    Entity Beans are good too, but unfortunately they were understood and used as direct object-relation mapping layer, when they should be one layer above OR mapping.


    Can you explain why we need entity beans on top of the O/R mapping layer when we already have stateless session beans?
  8. Entity Beans[ Go to top ]

    Can you explain why we need entity beans on top of the O/R mapping layer when we already have stateless session beans?


    In 99% cases we do NOT need Entity Beans atop of OR mapping layer. 1 percent cases or less might need EJB to ‘simulate’ object behavior for an entity that resides in multiple databases and/or systems. I consider Entity Beans as a way to implement a cache with predictable behavior (activate, passivate, etc.) for some complex business objects.
  9. IMO: EOB looks like another waste of resources. I would expect CORBA as a successor of EJB, because there is a solid theory behind…


    I have to agree that we need enhancements and tweaks to the current J2EE/EJB spec, not designed-from-scratch competing technologies. Your normal Java developers can't handle and shouldn't have to choose from half a dozen sets of API's (open source or not) for just object remoting and/or object persistence. We need to unite around one set of API and let vendors compete on implementation.
  10. We need to unite around one set of API and let vendors compete on implementation.


    Question is, it there such a common API, one-size-fits-all? And wasn't J2EE itself supposed to be that, in the first place? Is it possible to have a single solution for such a complex problem? Maybe this .Net x J2EE war will show us the answer, in the end. My guess is that there's space for different frameworks, each with its own strengths and weakenesses, and different focus.
  11. I must agree.

    Pure RPC is flawed in a sense that developer is not aware whether the object or interface will be used locally or remotely. Using the same interface for accessing objects locally and remotely has been one of the major criticisms of EJBs that introduced clumsy designs and slow performing systems until EJB 2.0 solved this issue with local and remote interfaces. EOB does look like a step backward in this sense.

    Apart from claiming easier use, what does EOB offer that we cannot find currently in EJB?

    Regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
  12. EJB vs EOB[ Go to top ]

    Dont get me wrong from my first post. I totally agree with the people that say that we should have one API, and I do believe and want it to be J2EE and EJB. But maybe the EJB specs could learn abit from the other solutions? In my opinion EJB:s are to complex at the moment, it could do without having to create three different source-files for implementation (or five if you go for both local and remote) for starters.
    We might say that "its not complex", but that is to us, the people who have been doing EJB:s for a few years, try to sell the "uncomplex"-side of things to junior people or non-tech project-managers who are looking at the other side of the road with m$ for example.. Its a tough sell, even though it isnt true, a non-java person might often think that five-source files means five times the development time.
    I´m not mandating any drastic changes, but making things a bit easier for beginners as well making it an easier sell to non-techies wouldnt hurt.
    I´ve seen large organization that have had their critical systems developed with MS SQL and VB just because it was "easy" for management to find VB-programmers (any monkey with a keyboard) and the fact that they thought they would see quicker results with VB or some other micros**t technology..
  13. Java-only clients?[ Go to top ]

    As far as i read it, one needs java on the client side - right?
  14. Responses so far.[ Go to top ]

    "Is this reinventing EJB.."

      Yes it is. Did not Sun part reinvent it though with Local interfaces?

    "similar to the object remoting that was recently added to the JBoss 4.0 source tree. In the JBoss remoting, you package your object in a .aop file instead of an .eob file, and away you go."

      Yes it is. Marc Fleury and I have chatted ion this previously. We'll make aplug in to JBoss soon enough (without Apache's Avalon-Phoenix). JBoss's own efforts are fantastic though.

    "Apache calls their framework 'post-J2EE'... "

    Apache have no such thing. EOB is by some Apache people (and some not) at SourceForge.

    "1. No transaction support, although we can ..."

    Being coded into AltRMI (or at least a framework that facilitates it) presently.


    "2. No asynchronous messaging..."

    RSN. One type coded in AltRMI, to arrive in EOB shortly.

    ".. it seems the whole Apache's Avalon-Phoenix server framework is not much easier.. "

    True. However the Phoenix 'blocks' are not part of the EOB client API. EOB is built using blocks. Subsequent versions of EOB will be additionally runnable without Phoenix. We plan to support Merlin, Plexus, JBoss as well as a mainable version.

    "EJB were designed with clear separation between remote and local invocation in mind.."

    Yup, keep in mind the Facade pattern whilst building distributed apps. Our take is don't hamper your client code's cleanliness by having to catch/extend/throw things just because you happen to be in a transport. We're not alone. .Net does it that way. So does TME's Glue. RemoteException sucks.

    "As far as i read it, one needs java on the client side - right"

    AltRMI is going to embrace XML-RPC and SOAP (via Axis) soon enough. We might even get to transparent transport that does CORBA, or .Net's native remoting.

    "one-size-fits-all? And wasn't J2EE itself supposed to be that, in the first place? Is.. "

    J2EE came along to unify (at lowest common denominator level) a number of tools that came before it. Some like the fabled Voyager (Graham Glass went on to form TME) are much missed.

    Why EOB and not EJB?

    How many people are coding three tier systems now? Do many code inside servlet context instead? More and more do. They solve scaling by using affinity based load balancers and (shock horror) Moore's law. They might, XP style, decide late in the project lifecycle to move to three-tier. Should they have to mug a plain model into an EJB model to do so? Should not we being to think of componenent development as something that can deliver the goods to a number of deployment scenarios. Design your components to run in either servlet context or the bean machine. Regret that the servlet version is having to handle RemoteException though for something that is in same VM. If you've coded a plain interface model with impls, be really chuffed that you can put that, say, spellchecker in any app, swing mainable|applet included.

    RemoteException is evil beyond measure (I allege, and duck from flames).

    - Paul H
  15. Responses so far.[ Go to top ]

    RemoteException is evil beyond measure (I allege, and duck from flames).

    I second the motion.

    Further, what gives every new developer the right to invent their own checked exceptions to head new trees of unimaginitively named useless throwable classes and to litter their APIs with? ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  16. Responses so far.[ Go to top ]

    RemoteException is evil beyond measure

    This way you may declare any checked exception as evil’s creature. RemoteException is as valuable as any checked exception because it makes everybody aware of possible problems. Fear of checked exceptions and an attempt to avoid them resembles ostrich’s head in the sand.

    >> How many people are coding three tier systems now?
    How many people design their systems? How many people write good code? Minority.
    O’K lets target majority and make b**t production even easier than before.
  17. Voyager still exists[ Go to top ]

    J2EE came along to unify (at lowest common denominator level) a number

    > of tools that came before it. Some like the fabled Voyager (Graham Glass
    > went on to form TME) are much missed.

    Voyager still exists. See http://www.recursionsw.com/products/voyager. (For those who haven't heard of it, it's basically an ORB with some advanced features possible due to its being built specifically to take advantage of the Java platform). Advantages (full disclosure, I work for Recursion):

    - Rapid development. With RMI, you have UnicastRemoteObject, Remote, and RemoteException all over your code, plus the joy of 'rmic'. Voyager requires *no* changes to your source code to remote-enable objects, as long as your class implements an interface, and it creates proxy classes automagically at runtime. Application exceptions on the server side are re-thrown on the client side, no need to handle RuntimeRemoteException. Distributed garbage collection. What this all means is you can focus your time and effort on the *business* end of the code, and let Voyager handle the "remoting" end.

    - Easy API. Want to create an object in a remote VM? "Factory.create(class, host)". Look up a remote object? "Namespace.lookup(name)". Move an object? "Mobility.of(foo).moveTo(destination);".

    - Advanced features (object mobility, server proxy persistence ("activation"), flexible pub/sub and multicast API...). Not necessary for most apps, but if you need it... it's there.

    - Scalable. Connection management and thread management. Efficient pub/sub message broadcast. Good overall performance.

    - Standards support. Messaging: RMI, IIOP 1.0, SOAP 1.0; Naming: JNDI, CORBA Naming.

    We also have JMS, Security, and Transaction module add-ons.

    Bottom line: Voyager's not free or Open Source, and it doesn't have the "new hotness" cool factor it once did (apologies to Will Smith). But it's stable and reliable, proven in the field (we have a few quite large deployments). And I haven't seen anything that beats it in terms of rapid development or ease of use. (Although Apache Axis comes darn close, if you are into the whole Web Services / SOAP thing heavily.)

    If you want to know more, respond here or drop me a line (twheeler at recursionsw dot com).

    -Thomas
  18. A note on distributed computing[ Go to top ]

    <paul>
    RemoteException is evil beyond measure (I allege, and duck from flames).
    </paul>

    "La critique est facile, mais l'art est difficile".

    It's easy to criticize, so how about sharing with us how you solve the problems raised in

    http://research.sun.com/techrep/1994/abstract-29.html

    ?

    This seminal paper established pretty clearly in 1994 that simulating transparency of locality is the door open to quantity of bugs and non-scalable applications. In short, if you are making a call, you need to know if

    - it can fail
    - it can take longer than what you would expect from an in-process call

    So I would be very curious to know if your solution involves more than simply hiding "throws RemoteException" so that developers feel a (very false) sense of security...

    --
    Cedric
    http://beust.com/weblog
  19. A note on distributed computing[ Go to top ]

    Cedric: "La critique est facile, mais l'art est difficile"

    Certainment! Je suis ein Berliner!

    An exception is fine, but arbitrarily placing checked exceptions on every method makes them non-exceptions by definition. In effect, it forces every call to a remote object to handle the potential for remote failure internally, because a component cannot be placed behind an existing interface that did not plan for the potential of a RemoteException, just like the component has to handle SqlException if it might use a database. In other words, it promotes poor programming practices.

    A potentially better solution would be to define a handler interface that would allow communication failure to be handled in a more generic manner, and only on the absence of a handler or the handlers unwillingness to handle the failure would an exception be thrown. In that case the exception could be a sub-class of RuntimeException, because that is what it is.

    I don't check for OutOfMemoryError when I do a new() or a new[], so why would I handle a remote exception at the point where I make a remote call?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  20. If network error may occur every time a user calls some remote method, then RemoteException has to be handled explicitly and has to remain a checked exception.

    The fact of the matter is that RemoteException has to be handled at some point within your logic. If you find it troublesome to handle it within the caller method, then propagate it further and handle it at another layer. Making it a runtime exception would tremendously hurt EJB-based projects since developers would have to rely on documentation, as opposed to relying on compiler, in order to find out in which methods/layers a RemoteException is actually handled and in which it isn’t. Relying on documentation for exception handling is not productive since documentation is often out of date and developers may forget to check it.

    Runtime exceptions usually denote an implementation bug or a non-recoverable error that should not happen in production. Since RemoteException is recoverable, developer should be forced to handle or ignore it explicitly.

    Best regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Archtecture for Java and .NET.
  21. In effect, it forces every call to a remote object to handle the potential for remote failure internally,


    No, it does not force to handle. It does force to be aware of possibility of such exception and make others aware of it too by (re)declaring the RemoteException.

    I am wondering: Why so many people hate RemoteException? And in the same time do not complain about necessity to deal with IOExeption on file operations… Probability of IO failure is much smaller than probability of a network problem, and still no complaints.

    I guess that checked vs. unchecked problem could be solved by allowing additional compiler switches, which may enable/disable checks for particular types of exceptions. That may make ostriches happy and virtually eliminate need for frameworks like EOB.
    Personally, I will vote against such compiler keys if somebody would seriously propose them.
  22. A note on distributed computing[ Go to top ]

    <cameron>
     In effect, it forces every call to a remote object to handle the potential for remote failure internally
    </cameron>

    Nope. You can

    - rethrow the exception
    - wrap it and throw a different one ("soften the exception")
    - declare it in your throws clause

    This last solution is obviously preferred when you're note sure what action to take.

    <cameron>
    A potentially better solution would be to define a handler interface that would allow communication failure to be handled in a more generic manner,
    </cameron>

    This is the C++ way, but it's there mostly because C++ doesn't have checked exceptions. The idea is good and could certainly find some good use in Java, which would then combine the best of both worlds.

    However, I still contend that it's not good enough. You cannot have a "generic" handler for all kinds of remote exceptions. You are not going to handle a "can't connect" the same way as "lost connection", which is different from an "object doesn't exist", etc...

    <cameron>
    I don't check for OutOfMemoryError when I do a new() or a new[], so why would I handle a remote exception at the point where I make a remote call?
    </cameron>

    Ha, good question. And I'm sure you already know the answer.

    OutOfMemory is a crosscut concern. It can happen any time, any place, and is usually not recoverable. If it is recoverable, there is only usually one place it can be recovered from: the JVM itself, which is going to make one last emergency attempt to get you some more memory before finally croaking.

    RemoteExceptions are very different. You know exactly when they can happen, and when they do happen, there are still quite a few cases where you can recover from them in a meaningful (e.g. contact a different server or retry the same call a few times before giving up) or informational (log the error, or display a dialog asking the user to retry). Plus, RemoteExceptions are usually not fatal to the application.

    RemoteExceptions keep you honest because the hard part of remoting is when things go wrong (a bit like transactions).

    --
    Cedric
    http://beust.com/weblog
  23. A note on distributed computing[ Go to top ]

    Mon ami,

    Nope. You can
    - rethrow the exception
    - wrap it and throw a different one ("soften the exception")
    - declare it in your throws clause

    So, wrapping it is the same as having it unchecked. That eliminates that choice from the "nope" list, because that was my "yup" list. Follow?

    So we can re-throw it or declare it? Those are the same thing, you realize. One must declare it to re-throw it, eh?

    The other thing one can do is handle it, which means handle it in all locations. Bad idea. It's a cross-cutting concern, n'est pas?

    This is the C++ way, but it's there mostly because C++ doesn't have checked exceptions. The idea is good and could certainly find some good use in Java, which would then combine the best of both worlds.

    C++? We don't need no steenkin ...

    I'm not talking language-level, I'm talking design-level. If I have a remote comms module, I'd like to be able to provide a single impl to handle the "90" part of the 90/10 rule.

    However, I still contend that it's not good enough. You cannot have a "generic" handler for all kinds of remote exceptions. You are not going to handle a "can't connect" the same way as "lost connection", which is different from an "object doesn't exist", etc...

    Hello?!? Is it better to put that code into every place that makes a remote call?

    I've seen about 100 different "real world" J2EE apps, and over half of them had 50 checked exceptions on every f***ing method in the application.

    Wie sagt man auf Deutsche ... nicht gut!!!

    Ha, good question. And I'm sure you already know the answer. OutOfMemory is a crosscut concern. It can happen any time, any place, and is usually not recoverable.

    In an enterprise app, the same applies for remote calls.

    RemoteExceptions are very different. You know exactly when they can happen, and when they do happen, there are still quite a few cases where you can recover from them in a meaningful (e.g. contact a different server or retry the same call a few times before giving up) or informational (log the error, or display a dialog asking the user to retry).

    What ivory tower do you live in? <wink>

    RemoteExceptions are not recoverable. In the "real world", the best you can typically do is provide the end user with a pretty page instead of a stack trace.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  24. checked vs unchecked[ Go to top ]

    <Cedric>
    This is the C++ way, but it's there mostly because C++ doesn't have checked exceptions. The idea is good and could certainly find some good use in Java, which would then combine the best of both worlds.
    </Cedric>

    Stroustrup in D&E has a good discussion on the issue; he stated that ideally it is desirable to have static exception checking by compiler and why it was decided not to have it in C++, recompilation is not such an issue in java as it is in C++ but changing implementation is, each time you call function that throws some other checked exception you need to wrap it in try and catch or change function declaration. Or consider for example java code that needs to close connection or file in catch or finally. Because close() throws checked exception you need to wrap it in try and catch and it is inside finally or catch block, good IDE like eclipse will help but still it does not look pretty.

    I got an impression that checked exceptions are considered bold but mostly failed experiment, all latest API use unchecked exceptions whenever possible. I am not sure if any other language has checked exceptions, even the ones that come after java like C#. I even saw publications that show how to wrap checked exceptions into unchecked ones and re-throw with code templates to reuse.

    Very often exception handling is actually printStackTrace or logging and after some frustration you simply catch mother of all exceptions at least at the prototyping stage. Maybe AOP will help if it became mainstream.

    oleg
  25. checked vs unchecked[ Go to top ]

    <oleg>
    Stroustrup in D&E has a good discussion on the issue; he stated that ideally it is desirable to have static exception checking by compiler and why it was decided not to have it in C++, recompilation is not such an issue in java as it is in C++ but changing implementation is
    </oleg>

    Well, the main reason why C++ doesn't have checked exceptions is simply because of backward compatibility with C. Same reason for C#.

    That being said, D&E is one of the best technology books I have read these past ten years. Highly recommended, even if you're not into C++. You will end up with a better understanding of why C++ is like it is these days and it will certainly give you a new insight on language design.

    It will be interesting to see if AOP -- with its ability to "soften exceptions" -- will change our ideas on checked/unchecked exceptions,

    --
    Cedric
    http://beust.com/weblog
  26. checked vs unchecked[ Go to top ]

    <Cedric >
    Well, the main reason why C++ doesn't have checked exceptions is simply because of backward compatibility with C. Same reason for C#.
    </Cedric >

    No disagreement that D&E is one of the best technology books.

    Backward compatibility with C might have played a role but it is difficult to believe that it was a major one, you wrap it in extern "C" anyhow and C doesn't have type-safe linkage but it didn't stop C++ from it.


    oleg
  27. checked vs unchecked[ Go to top ]

    <Cedric >
    Well, the main reason why C++ doesn't have checked exceptions is simply because of backward compatibility with C. Same reason for C#.
    </Cedric >
    No, the designers of C# made a deliberate choice not to follow Java in offering checked exceptions. Bruce Eckel's article on checked exceptions includes a link to a Microsoft site discussing this. (I don't have the link handy, but follow the link to Bruce's page in the PDF below.) C# is not backward compatible with C++ for many reasons.

    In Chapter 4 of Expert One-on-One J2EE Design and Development" I discuss the checked vs unchecked issue at length. Basically I agree with Cameron. (I often do, actually--I always enjoy reading his posts.) I think that checked exceptions are overused in Java.

    While I think it's good that Java offers checked exceptions, I think that things that are usually fatal, like RemoteException (or SQLException), are best not made checked. Otherwise people just catch (Exception) and make all exception handling worthless. You and I mightn't write such code, but lots of people do :-; If something knows how to retry, it has the choice of catching a runtime exception.

    I think developers need to code sensibly in awareness that remote calls are different from local calls: simply making it harder to make remote calls doesn't help.

    Chapter 4 is available elsewhere on TSS.

    I had a look at EOB a couple of months ago and I think it's a very legitimate project. If an alternative ever gets to critical mass and impacts EJB, I don't see that as a problem, because that could only happen if it offered something of value, which hopefully Sun would have to take note of. I think it's good to see an open source project innovating. (Or at least introducing ideas found in other platforms.)

    Regards,
    Rod
  28. checked vs unchecked[ Go to top ]

    <rod>
    I think developers need to code sensibly in awareness that remote calls are different from local calls: simply making it harder to make remote calls doesn't help.
    </rod>

    Regardless of the checked/unchecked exception discussion, I think this is the most important point of the whole discussion, and I'm glad to see we agree on this, so let me repeat it:

    Developers need to know when a call is remote and when it is local.

    There are various ways to enable this practice (checked remote exceptions being one of them), and none of them is perfect.

    I guess what makes me sad is that EOB is a promising project, if it wasn't for

    - The arrogance.
    - Forgetting lessons learned from the past.

    --
    Cedric
    http://beust.com/weblog
  29. checked vs unchecked[ Go to top ]

    Ced: Developers need to know when a call is remote and when it is local.

    Hmm ... just checked the JDBC docs, and noted that none of the JDBC methods throw a RemoteException. Can't JDBC go over the network? ;-)

    There are cases in which I agree 100% that the developer should know that they are making a call which may be a remote call. There are other cases in which that is pure silliness. Taking ivory tower silliness and forcing it upon your average developer is ... uh ... C++.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  30. Otherwise people just catch (Exception) and make all exception handling worthless. You and I mightn't write such code, but lots of people do :-;

    Well, Rod, this creates an impression that you are trying to push the technology towards accommodating laziness and misuse. I believe this strategy will get us nowhere. Yes, some people do chose to catch Exception and Throwable, but that is misuse and laziness. More to the point, making exceptions as RuntimeExceptions will not solve the problem, since RuntimeException is a subclass of Exception and same kind of laziness will still exist out there.

    If something knows how to retry, it has the choice of catching a runtime exception.

    Well. How does that something know for sure whether this exception got handled in a called method or not? The only way to know is to rely on documentation (this way is advocated by Microsoft when they speak against checked exceptions). How many projects out there do rigorously keep documentation up-to-date? Not many… Lack of checked exceptions will leave many non-fatal exceptions unhandled and will hurt majority of projects out there

    As far as RemoteException, it is recoverable. As Cameron pointed out: In the "real world", the best you can typically do is provide the end user with a pretty page instead of a stack trace. Yes, Cameron, this is one of the most common ways to recover: show an error page and let the end user retry. The whole system is still fully operational at this point, which means that it successfully recovered from RemoteException. That’s why developer has to be forced to handle RemoteExceptions, which would not be the case if it was a runtime exception.

    Hope this helps,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Architecture for Java and .NET
  31. checked vs unchecked[ Go to top ]

    No, I'm not trying to "push technology towards accommodating laziness and misuse" at all. I'm just realistic about the fact that we don't live in an ideal world. The need to catch and rethrow checked exceptions in methods that can't possibly recover causes errors as well as promoting laziness. And makes code much harder to read.

    If your project doesn't keep documentation up to date, it's poorly run. How do you know how methods handle null arguments? What state certain methods must be called in? It sounds like you're a lot keener to promote laziness than I am.

    <quote>
    Lack of checked exceptions will leave many non-fatal exceptions unhandled and will hurt majority of projects out there
    </quote>
    I doubt you're spearking from experience here. I switched to use mostly unchecked exceptions over a year ago, after several years of using checked exceptions almost exclusively. Since then I've seen greater productivity in projects I've worked on and no loss of quality.

    Your example of "recovery" from a RemoteException is incorrect. This is the kind of "recovery" that a servlet container can give you if it catches an uncaught runtime exception and you've configured your web.xml properly. A runtime exception won't take down a server.

    I think checked exceptions are helpful when they have business meaning--e.g. insufficient funds. But in many cases using checked exceptions adds no value and just makes APIs harder to use. Imagine if basic API classes such as java.util.Iterator threw checked exceptions. Theoretically code might be more robust, but it would be a pyhrric victory as there would be so many try/catch blocks that actually finding any logic would be a challenge.

    Regards,
    Rod
  32. checked vs unchecked[ Go to top ]

    If your project doesn't keep documentation up to date, it's poorly run.

    No, that is not true. Please take a look at "Agile Software Development" book by Alistair Cockburn. Author makes an interesting and extremely useful argument that internal documentation has to be kept to the minimal productive level. Over-documenting will most likely hurt the project rather than help it. Companies don’t sell internal documentation, it’s the product as a whole that counts. And, of course, external public APIs and overall product documentation have to be documented well and kept up-to-date. I think that you would find just that if you downloaded our product - xNova™.


    I doubt you're spearking from experience here...


    I am speaking from personal experience when I say that lack of checked exceptions is counterproductive. Again, please take a look at the product that my company ships. We are evenly split between doing Java and C# development. In fact, as I already mentioned, we had to use CLRxLint (.NET checked exception verifier) when doing .NET development that helped us verify that all exceptions thrown by C# libraries got properly handled. So, at this point I am quite certain that both Java and .NET portions of our product are robust.

    I switched to use mostly unchecked exceptions over a year ago, after several years of using checked exceptions almost exclusively. Since then I've seen greater productivity in projects I've worked on and no loss of quality.

    Well, I have seen great productivity in projects that properly used checked exceptions as well. Again, by using runtime exceptions, you are asking developers to rely on documentation and some exceptions can be easily missed.


    Your example of "recovery" from a RemoteException is incorrect. This is the kind of "recovery" that a servlet container can give you if it catches an uncaught runtime exception and you've configured your web.xml properly. A runtime exception won't take down a server.


    My example is correct.

    First of all, if you wish, you can propagate checked RemoteException to the servlet level also and handle it there. In this case it would be better than the solution you propose with runtime exception, since it will be checked by compiler.

    Secondly, unless you catch "Exception" directly in all you projects at Servlet level, how can you give me 100% guarantee that your project properly handles all exceptions thrown by the system. Moreover, catching "Exception" is not the best way to go, since in many cases different exceptions have to be handled differently.

    Thirdly, not all EJB projects are Web based, there are projects that use EJBs with fat clients.

    Hope this helps,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Architecture for Java and .NET
  33. checked vs unchecked[ Go to top ]

    Rod - If your project doesn't keep documentation up to date, it's poorly run.

    Dmitriy - No, that is not true. Please take a look at "Agile Software Development" book by Alistair Cockburn. Author makes an interesting and extremely useful argument that internal documentation has to be kept to the minimal productive level.

    There's documentation and documentation. Javadoc is source-level documentation, and must be kept up to date. I agree that keeping lots of internal documentation (in Word and the like) can be counter-productive, as it can get out of synch with the source. However, this doesn't apply to Javadoc. I also consider rigorous test cases to be a valuable form of documentation. Unit tests should check for situations in which runtime exceptions will be thrown. Whatever documentation set your project agrees on--even if it's only Javadoc--must be kept up to date. And no documentation is not an option.

    <d>
    First of all, if you wish, you can propagate checked RemoteException to the servlet level also and handle it there. In this case it would be better than the solution you propose with runtime exception, since it will be checked by compiler.
    </d>
    Why should the web tier have explicit knowledge of the use of RMI? You can also choose to catch runtime exceptions, for example MyRemoteException, and handle them as you wish. As I said before, you need to be aware if you're making remote calls, although ideally you'll want to hide retry logic in infrastructure classes.

    As Bruce Eckel comments, we shouldn't assume that compile-time checks are always better.

    I'm not saying "never use checked exceptions", just that there's a tradeoff and that exclusive use of checked exceptions hurts productivity, readability and doesn't necessarily improve correctness.

    Rod
  34. checked vs unchecked[ Go to top ]

    <Rod>
    There's documentation and documentation. Javadoc is source-level documentation, and must be kept up to date.
    </Rod>

    I agree that keeping Javadoc up to date for all public scope methods is very important. However, keeping Javadoc up to date for all private and package scope methods only works well when you don’t have pressing deadlines. In "real world" deadlines do matter, so asking developers to javadoc everything (which I believe is what you are suggesting) is not usually feasible neither time nor financially wise. This is yet another reason why compile time checking is much more robust than relying on documentation when it comes to exceptions.

    Rod, I enjoyed reading your book. Exception handling is the area where I can’t seem to agree with you. Personally I think that argument that using checked exception may render code less readable is weak. I believe that code is as readable as you make it (there are plenty of well known techniques to help you write readable code with checked exceptions). And even if you still must press the argument of readability, I will take robustness over readability any day. At the end, customers actually want to use reliable product (not read the code), and robustness has a much higher value.

    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Architecture for Java and .NET
  35. checked vs unchecked[ Go to top ]

    <Rod>
    Chapter 4 is available elsewhere on TSS.
    </Rod>

    Rod,

    Thanks for posting the chapter, great read, I have couple of questions.

    In your guidelines the only reason for using checked exception is a second return value that all callers should handle, and an example is - spending limit exceeded in a processInvoice() method. Two questions:

    1. Checked exception as a return value. Users may want to process invoice in one place including check for different conditions like spending limit, and to force them to process spending limit in exception handler might introduce unnecessary complexity. It is like mixing pull and push models to process one function call
    2. All callers should handle. If you code is successful people will start using it in situations that you did not envision and what looked like a must handling might not be the same in a different situation; for example, there could be a situation when it doesn't matter why invoice was not processed, was it for spending limit or smth. else.

    I happen to belong to the school of thought that believes that exceptions should not be used as a return value and even more exceptions should not be part of the regular business logic. But taking into account that java doesn't have in/out parameters or pass by reference I can see that checked exceptions could be used as a hack but I prefer to use another hack, a holder class like in Axis or just arrays.

    Good compromise might be to have compiler option to enable/disable checked exceptions; or having a tool to report unchecked exceptions that are not handled.

    oleg
  36. checked vs unchecked[ Go to top ]

    Oleg, both these issues involve tradeoffs. Checked exception as an alternative return value is sometimes considered inelegant, but I think this is where checked exceptions really come into their own. The alternative of checking a return value is error prone. I don't agree that this is a hack. Obviously it shouldn't be overused, as forcing users of the API to write a try/catch block is invasive, but it can be helpful to enforce appropriate workflow.

    "All callers should handle": if it didn't matter if an invoice failed processing, this is exactly the situation where the programmer should be forced to catch the exception, log it or otherwise make clear that in an atypical usage pattern she didn't care about that exception.

    Rod
  37. checked vs unchecked[ Go to top ]

    <Rod>
     Obviously it shouldn't be overused, as forcing users of the API to write a try/catch block is invasive, but it can be helpful to enforce appropriate workflow.
    </Rod>

    "to enforce appropriate workflow" I was arguing with because it is the caller who should decide what workflow is appropriate and not the author of the processInvoice() function; however the situation is different if you provide framework that will limit its users to certain workflow. What I was trying to distinguish is the library usage vs. framework, however there might be a gray area when a library is acting like a framework and using checked exceptions as a return value might well be move in this direction.

    <Rod>
     "All callers should handle": if it didn't matter if an invoice failed processing
    </Rod>

    What I actually meant was that there could be a situation when it does not matter why invoice failed processing; there could be several reasons why it failed and what matter is the fact that it failed but not the reason and caller should not be forced to process any particular reason when it is irrelevant Sorry that I did not make myself clear in the previous posting.

    oleg
  38. checked vs unchecked[ Go to top ]

    <oleg>
    To enforce appropriate workflow" I was arguing with because it is the caller who should decide what workflow is appropriate and not the author of the processInvoice() function; however the situation is different if you provide framework that will limit its users to certain workflow. What I was trying to distinguish is the library usage vs. framework, however there might be a gray area when a library is acting like a framework and using checked exceptions as a return value might well be move in this direction.
    </oleg>
    I think we pretty much agree. In such cases the processInvoice() is acting like a framework and determining how the caller must react. When I use this idiom this is exactly what I want to achieve. Of course this is not the case for most method signatures--this is a powerful idiom to enforce certain usage patterns, often concerning an important business operation.

    Regards,
    Rod
  39. checked vs unchecked[ Go to top ]

    I am currently working on a product, xNova™, which provides middleware services (distributed caching, workflow, etc...) for both Java and .NET.

    I can strongly testify that writing robust networking code in C# is much more difficult than in Java because of lack of checked exceptions. When you have a multiple number of unchecked exceptions thrown by all methods at the end it becomes extremely difficult to keep track of which exceptions were handled and which didn’t. Some exceptions never turn up during testing, so you end up going into production with code that is not robust. We had to use a checked exception verifier for .NET which now comes free with our product.

    Checked exceptions are extremely vital when it comes to development productivity.

    Regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Architecture for Java and .NET
  40. checked vs unchecked[ Go to top ]

    <Dmitriy>
    I can strongly testify that writing robust networking code in C# is much more difficult than in Java because of lack of checked exceptions. When you have a multiple number of unchecked exceptions thrown by all methods at the end it becomes extremely difficult to keep track of which exceptions were handled and which didn’t. Some exceptions never turn up during testing, so you end up going into production with code that is not robust. We had to use a checked exception verifier for .NET which now comes free with our product
    </Dmitriy>

    Ideally it is great to have compiler to check for exceptions but my argument was that the current remedy might be worse than the disease. Tools could be very useful to identify exceptions that are not handled. Compiler errors could force developers to "swallow" the exceptions and introduce false sense of security and also a lot of ugly code like in example with close(). Also recovery could be quite complicated and chances are that when you know how to recover you will catch exception regardless of the fact that it is unchecked.

    oleg
  41. InvocationException & Monitors[ Go to top ]

    OK, some more clarifications.

    Outage

    AltRMI (which EOB uses), does communicate outage. It does so via a deravative of RuntimeException. This is ideal for your controller-servlet to catch, and place a service outage page - we're all using Model-2(+) these days right?

    Swing clients are not so cut and dry though.

    Monitoring

    AltRMI provides a monitor framework on server and client sides. Bespoke implementations can participate in connection retries and be informed of outage before it is reported to the caller, and deterministically log various things.

    On checked Exceptions per se

    I like them for business logic. For infrastructure stuff they are overkill.