Design a simple service-oriented J2EE application framework

Home

News: Design a simple service-oriented J2EE application framework

  1. Fangjian Wu thinks that we couple too tightly between our web tier, and our service tier. He thinks the same about DAO to JDBC coupling. His article goes into detail on how to loosen up this coupling, using existing open source technologies such as Struts, Spring, Hibernate, and Axis.
    Often, a J2EE Web application framework—Struts, for example—doesn't address the Web-tier object references between Action/servlet and other layers, such as a plain old Java object (POJO) business manager, Enterprise JavaBeans (EJB), Web services, and a data access object (DAO), or between a DAO and JDBC (Java Database Connectivity) stored procedures. Thus, Java developers end up with messy code in the Web tier Action/servlet. This article describes in detail the steps for developing a custom framework that addresses those issues.
    Read the full article: Design a simple service-oriented J2EE application framework

    Threaded Messages (98)

  2. The article is a good theoretical discussion and such is because it does not cover any business apsects of the examplory framework.

    I think in a current business-centric world, it is more imperative to be able to find right solutions for various business situations and requirements, it is imperative at this day and age to have business-savvy frameworks written to fulfill the need of clients and not a need of developers as a lot of the frameworks are now. (Easy to code, easy to maintain; but are the solutions build on such frameworks are easy to use?)

    I am yet to see Hibernate, Spring and others homogenously used in an implementation of a large-scale enterprise solution. We need to have our frameworks driven towards business to build trust in an open-source community in a fact that we can deliver solutions comparable if not better than commercial alternatives.

    I wish I had more time away from other day-to-day mundane tasks to invest more time in business-driven framework. (Hey, I've started one, but it is far away from completion and referring to one earlier posts here - it's code sucks :-) )

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  3. The article is a good theoretical discussion and such is because it does not cover any business apsects of the examplory framework.
    I agree with Yegorov. Its service oriented in terms of architectural layers where both service endpoints are architectural layers,themselves,and not any end user.Its does not solve any business aspects.

    I found the article well written.

    Regards
    Surajeet
  4. Seriously I can't see how this stuff adds any value. Did anyone read this before linking to it ? All this cludgy stuff reminds me of the last days of
    perl's credibility.
  5. Seriously I can't see how this stuff adds any value. Did anyone read this before linking to it ? All this cludgy stuff reminds me of the last days of perl's credibility.
    Although it's hard to dislike something named after a martial artist, i have to agree with you. If nothing else, i'm always skeptical of techniques that reduce "coupling" by eliminating type checking.

    There seems to be a real mania for creating frameworks these days. Somebody needs to create a "Ten Commandments for Framework" developers that includes things like, 1) A Framework must solve a real problem, 2) A Framework must solve a significant problem, 3) A Framework must have a consistent architecture, 4) A Framework must make a developer's life easier, 5) A Framework must not make a maintainer's life harder, 6) A Framework must be thoroughly documented, 7) A Framework must not deviate from the programming paradigm of the language for which it's intended, 8) A Framework should be independent of other frameworks, 9) A Framework should be at least slightly novel, 10) A Framework should not mix concerns (e.g., no database code in a UI framework).
  6. Sadly JavaWorld is not what it use to be.

    That aside when I see people who build frameworks like this in the name of reduced coupling a flag goes up. Throwing away type saftey is not something that should be so easliy done. I would hate to be the developer who has to debug this thing.

    As for reduction of code repetition in the DAO layer I find Springs solution nice and elegant.

    David
  7. I would add 11.) A Framework should have enough of a user base so that it will be easy to bring in somebody else to maintain applications built with it. That is why Struts is not going away anytime soon.
  8. Spring's DAO abstraction, and the template approach, covers more than just JDBC, so it's suprising that the author didn't discuss it, as he recommends using Spring as part of his stack. It seems pretty close to what the author wants, it's mature and addresses translation of exceptions into a consistent hierarchy, which is essential for the goal of decoupling.

    As well as JDBC/Hibernate/JDO/ibATIS/OJB, Spring supports JNDI (one of the examples) out of the box. We recently had an LDAP contribution, btw, and I know of at least one user who has written a module for Documentum, although he hasn't contributed it.

    Besides that, my main gripe with the article is that there are lots of catch(Exception) and catch(Throwable) blocks.

    Rgds
    Rod
  9. Hi Rod:

    I am interested in knowing more what it means to translate exceptions into a consistent hierarchy and how it helps in decoupling. Please do let me know.

    Thanks,
    Venkat
  10. See the DAO chapter in the Spring Reference Manual. The basic idea is that there isn't much point having DAO interfaces that aim to be data access technology-neutral if they propagate exceptions such as SQLException or necessitate catch and wrap in your application code, which can quickly become very verbose.

    The bonus is that the Spring exception hierarchy is much more meaningful than JDBC's SQLException, for example. In the case of JDBC, Spring's translation layer knows how to map vendor codes onto subclasses, so you don't need to write non-portable code to examine vendor codes etc.

    Thus a business object could catch say DataIntegrityViolationException and not depend on JDBC, Hibernate or iBATIS. But all of those could be used to implement the interface and the translation would be done by the framework.

    Rgds
    Rod
  11. The basic idea is that there isn't much point having DAO interfaces that aim to be data access technology-neutral if they propagate exceptions such as SQLException or necessitate catch and wrap in your application code, which can quickly become very verbose.
    I try to stay balanced in my use of checked and unchecked exceptions. I use unchecked exceptions only for errors that represent pure bugs in my applications. Properly designed checked exception hierarchy is much more robust and useful and does not become very verbose. In all fairness, how much do you save in lines of code when you have to add a throws clause to a method?
    The bonus is that the Spring exception hierarchy is much more meaningful than JDBC's SQLException, for example. In the case of JDBC, Spring's translation layer knows how to map vendor codes onto subclasses, so you don't need to write non-portable code to examine vendor codes etc.
    Proper error code mapping is a good feature, but to ensure robustness JDBC exception hierarchy must be based on checked exceptions.

    I guarantee that due to "All-Exceptions-Must-Be-Runtime" policy in Spring, any application based on Spring has no clue as to which exception is handled at which tier or even in which method. As a matter of fact, I am certain that users of Spring Framework unknowingly leave many exceptions unhandled. For example, how in the world would your logic know that the aforementioned DataIntegrityViolationException was not handled at some point before? Or how would you know that your method may be actually throwing this DataIntegrityViolationException?

    However, if DataIntegrityViolationException was checked then you could easily propagate it with 'throws' clause and be absolutely certain as to where it may be handled.

    Regards,
    --Dmitriy.
  12. I guarantee that due to "All-Exceptions-Must-Be-Runtime" policy in Spring, any application based on Spring has no clue as to which exception is handled at which tier or even in which method. As a matter of fact, I am certain that users of Spring Framework unknowingly leave many exceptions unhandled.
    Here we go again :-)

    I find it interesting that only Spring is the subject of your zeal for checked exceptions. In fact, JDBC not only has a particularly poor exception model (SQLException for pretty much everything, which in my experience emphatically does not help robustness), but it's one of what is probably a minority of data access APIs to use checked exceptions. TopLink and JDO both use unchecked exceptions, for example. Gavin King is on record as saying that he wished Hibernate had chosen unchecked exceptions, and Hibernate 3 switches from checked to unchecked exceptions.

    With all these potential targets, apparently it seems that only Spring is going to be responsible for the end of the world through its use of unchecked exceptions... Shouldn't you also tell Oracle that no one can build robust applications on TopLink, or hasten to tell Gavin the error of his ways with respect to Hibernate 3?
  13. I find it interesting that only Spring is the subject of your zeal for checked exceptions.
    Absolutely not. The only reason that I criticize Spring for use of unchecked exceptions is because Spring takes every chance to boast its decision of unchecked exceptions and tries to proliferate such practice among other developers. Unchecked exceptions are almost a center piece of Spring marketing. Other products actually advertise their features – not their exception handling designs.
    TopLink and JDO both use unchecked exceptions, for example. Gavin King is on record as saying that he wished Hibernate had chosen unchecked exceptions, and Hibernate 3 switches from checked to unchecked exceptions.


    TopLink and JDO had no choice. They might have chosen checked exceptions if it was possible for them. TopLink is an end result of code migrated from SmallTalk which does not have checked exceptions. JDO supports byte code augmentation and technically could not have used checked exceptions.

    Gavin King was also on the record saying that he does not plan to change Hibernate’s exception strategy to unchecked exceptions. It is unfortunate that he will actually do it, but I believe that his decision is directly influenced by Spring and the like, and that is why I take every opportunity to dispel the myth of robust unchecked exceptions that you so vividly advertise.

    <blocquote>
    Shouldn't you also tell Oracle that no one can build robust applications on TopLink, or hasten to tell Gavin the error of his ways with respect to Hibernate 3
    </blocquote>

    Please concentrate on your own framework and stop justifying your flawed decision of using unchecked exceptions by other decisions that were made in totally different contexts and for totally different purposes.

    Regards,
    --Dmitriy.
  14. JDO supports byte code augmentation and technically could not have used checked exceptions.
    True for methods that have been enhanced on PersistenceCapable objects. But not true for many JDO API methods like querying.
    Gavin King was also on the record saying that he does not plan to change Hibernate’s exception strategy to unchecked exceptions. It is unfortunate that he will actually do it, but I believe that his decision is directly influenced by Spring and the like
    I believe that Gavin was concerned about backward compatibility at the time. Those concerns no longer apply with Hibernate 3. As for "I believe that his decision is directly influenced by Spring and the like" I can guarantee that Gavin is not under my influence.
  15. Please concentrate on your own framework and stop justifying your flawed decision of using unchecked exceptions by other decisions that were made in totally different contexts and for totally different purposes.Regards,--Dmitriy.
    Please concentrate on your own commercial application framework, and stop spreading FUD about design decisions in open source products that were made in totally different contexts and for totally different purposes.

    Regards,
    Juergen


    P.S.:

    You still prefer to not mention that your own product competes with Spring - to some degree, at least. I'm aware that you want to make people believe that you do not compete with Spring in the first place, but looking closer, you *do* compete in some respects, even if maybe targeting a different audience.

    And no, the typical TSS reader is probably not aware of this - but it certainly helps to understand your fierce public aggression against Spring. (That said, I do believe that you personally believe in what you say too.) Feel free to spread propaganda about your product now, like you did last time.
  16. Juergen,
    You still prefer to not mention that your own product competes with Spring - to some degree, at least. I'm aware that you want to make people believe that you do not compete with Spring in the first place, but looking closer, you *do* compete in some respects, even if maybe targeting a different audience.

    And no, the typical TSS reader is probably not aware of this - but it certainly helps to understand your fierce public aggression against Spring. (That said, I do believe that you personally believe in what you say too.) Feel free to spread propaganda about your product now, like you did last time.
    This thread was about Spring and so I was very reluctant to plug something from our product. And I still won’t give you that wicked pleasure that you are so asking for :-)

    You analysis is right and I don’t think I ever said that we don’t compete at all. We do, in some respects, as you said. Furthermore, as far as fundamental ideas behind our products we were much before first Rod’s paper was even published. But you are right in that we target somewhat different group of people.

    Since Spring is an open-source product I and others have a freedom for a more deeper evaluation of it. I found the basic ideas behind it are sound (see above) but implementation (the coding) is mediocre at best and many design decisions are downright flawed. Exception handling is just probably the biggest problem for me (combined with constant pushing of it). Aside from that, I found project organization & packaging is rather broken and hasty (usual problem for open source stuff), (over)usage of inheritance is lighthearted, code quality dismal and conceptual integrity of the project that is lacking.

    But I am picking up on error handing as the one flaw that has probably the biggest long-term damage to the projects that get trapped into it.

    Let me elaborate on the core of the problem because I believe many readers don’t see it while you and I operate on assumption that is well understood.

    When the developer is confronted with a method (in Java or C#) he or she can decide what runtime exception(s) is being thrown by relying only on:
    - Documentation, or
    - Full transitive closure of method-call graph starting from this method.

    Both approaches have fundamental problems:
    - There is no practical way to know if the documentation is up to date. Any developer that has dealt with legacy integration, software maintenance or any other type of refactoring project will attest that it is a safe assumption that most of the code-level comments and documentation are either out of date, incomplete or inaccurate.
    Checked exceptions allow compile-time verification of all exceptions thrown by the method.
    - If one calls method foo() it is not sufficient to check the documentation or source code for foo() only. The developer has to check the documentation or source code of all the methods called by foo(), and then he or she has to check the documentation or source code of all the methods called by the methods called by foo(). In other words one has to check the documentation or source code of the entire call graph. In all but the smallest projects this is practically impossible. Not to mention that you rather must have a source code to do that unless you “trust” documentation.
    Checked exceptions allow compile-time verification of the entire call graph regardless of documentation or source code availability.

    So, runtime-only exception design has very practical flaws that in a closer look have little to do with layering, design or misuse. These flaws, however, will have a profound impact on the system when it goes in production and start core dumps.

    Regards,
    Nikita.
  17. Since Spring is an open-source product I and others have a freedom for a more deeper evaluation of it. I found the basic ideas behind it are sound (see above) but implementation (the coding) is mediocre at best and many design decisions are downright flawed. Exception handling is just probably the biggest problem for me (combined with constant pushing of it). Aside from that, I found project organization & packaging is rather broken and hasty (usual problem for open source stuff), (over)usage of inheritance is lighthearted, code quality dismal and conceptual integrity of the project that is lacking.
    This is hardly worth dignifying with a response: your breathtaking arrogance in this thread speaks for itself.

    We are proud of Spring's code quality. We have a strong test suite. Your assertions that the code quality is "dismal" and "conceptual integrity" is lacking are hardly credible in the context of your increasingly extreme statements in this thread. We encourage people to look at Spring's code for themselves. Such scrutiny is not, of course, possible with closed source products.

    Seriously, don't you think this is all getting out of hand? You have one view on checked exceptions, we have another. You write software that uses checked exceptions. I'm not going to make any predictions that if people use this that will be the end of the world. OTOH you seem to find it impossible to accept that others may see things differently to yourselves and make different choices.
  18. Rod, calm down.
    All my analysis stands and I can state it again and again. Anybody can attest to your system and come to their own conclusion. I have stated mine.

    I am tired of you constantly diverting discussion into personal touchy feelings, “arrogance”, and “don’t hurt us, please” attitude. I live in San Francisco and I see that attitude frequently, if you know what I am saying :-) It is a standard trick but the one that does not advance the discussion in any way.

    Look couple of posts up and try to reason with me, if you like, regarding the core problem with runtime exceptions.

    Nikita.
  19. Since Spring is an open-source product I and others have a freedom for a more deeper evaluation of it. I found the basic ideas behind it are sound (see above) but implementation (the coding) is mediocre at best and many design decisions are downright flawed. Exception handling is just probably the biggest problem for me (combined with constant pushing of it). Aside from that, I found project organization & packaging is rather broken and hasty (usual problem for open source stuff), (over)usage of inheritance is lighthearted, code quality dismal and conceptual integrity of the project that is lacking. But I am picking up on error handing as the one flaw that has probably the biggest long-term damage to the projects that get trapped into it. Let me elaborate on the core of the problem because I believe many readers don’t see it while you and I operate on assumption that is well understood. ...
    Indeed, Spring is an open-source product, and I encourage everybody to take a look at the source, the testsuite, the excellent support provided on the forums, the project itself (such as the packaging you deride), and any other aspects of the project, and see how ridiculous and unfounded your statements are, regardless of your motives (at which I can certainly guess). I may add that this sort of examination is not something one can easily do for other, closed-source products. I also encourage people to talk to other people using Spring to get a first hand-account of how Spring's exception handling strategy has worked out for them, instead of taking your statements as gospel.

    I find this entire thread incredibly distressing. You and Dmitry have said the exact same thing (with regards to exception handling) on a number of other threads (I think the word hijacked is entirely appropriate), and I encourage readers to look at some of these past threads and see that nothing new is being said here. Why can't you live with the idea that regardless of what you think about checked vs. unchecked exceptions, a lot of other people with equally valid opinions based on many years of experience don't agree with you. Get on with your life. Personally, I am an experienced J2EE coder and architect, and have seen many many cases of both checked and unchecked exceptions being abused. Along with a lot of other people, I have personally come to the conclusion that except for recoverable errors unchecked exceptions make sense most of the time. But I don't stay up at night worrying about the fact that you don't agree with me, or try to push this point in thread after thread.

    Regards,
    Colin Sampaleanu

    (a member of the Spring team if it's not obvious).
  20. I found the basic ideas behind it are sound (see above) but implementation (the coding) is mediocre at best and many design decisions are downright flawed. Exception handling is just probably the biggest problem for me (combined with constant pushing of it). Aside from that, I found project organization & packaging is rather broken and hasty (usual problem for open source stuff), (over)usage of inheritance is lighthearted, code quality dismal and conceptual integrity of the project that is lacking.
    Now that's an analysis. Using words like "mediocre at best", "downright flawed" and "code quality dismal" is as open insult, even if you think that you did find concrete issues. I do believe in Spring's code quality, do my best to maintain the highest quality possible, and consider this as a personal insult.

    Switch your position for a moment: What if someone came to you and used such words about your code? (Of course, that won't be an outsider - you're closed source.) Mind you, it's not about the content - it's about the style. Would you feel insulted? Would you consider that person worth talking to any further?
    I am tired of you constantly diverting discussion into personal touchy feelings, “arrogance”, and “don’t hurt us, please” attitude. I live in San Francisco and I see that attitude frequently, if you know what I am saying :-) It is a standard trick but the one that does not advance the discussion in any way.


    Nice try. It's rather a standard trick to first insult competitors at the most personal level possible, then let them react to it, finally claim that they're diverting the discussion. You've used that pattern repeatedly on TSS, and you don't seem to get tired of it.

    Actually, this is so ridiculous that I have to laugh and cry at the same time. You're throwing insults around with a choice of words that can han hardly be considered reasoned and well-founded arguments, and then you're accusing us of personal touchy feelings? Oh my goodness.

    I'm throwing an unchecked exception now to let this thread die. This time, I hope that the thread is coded in Dmitriy's style, that is, that noone recovers it in a catch or finally clause.

    Juergen
  21. All right, Juergen,
    All this whining really got me and so I re-created CVS project, loaded up Spring and poked around. In two minutes, I found 5-6 public classes (why are they all public?) with public methods lacking any Javadoc comments at all. For example, ControlFlow.java. Many exception classes as well... ScheduledTimerTask.java, etc.

    Now, I understand these things are not do-or-die type of mistakes but in my organization anyone checking code like that would be visited by me personally… We check all comments for punctuation and grammar errors, and having Javadoc is absolutely required.

    I am also very keen on a consistent naming pattern for code elements including variables, methods, classes, and interfaces. All code reviews that we are performing almost daily deal in part with those issues. All that and other aspects lead to a match tighter conceptual integrity that I cannot see in Spring code (on a brief look).

    All classes seem public. Where is the conceptual line between implementation and interfaces? What is intended for the end-use and what is internal implementation? It seems that everything is blob-ed together with everything else.

    We used assertion in most places to enforce contractual agreement between caller and callee even before assertions were introduced in Java. I don’t see it at all in Spring. Small potatoes that greatly improve code robustness

    Inconsistent, almost chaotic formatting of text in logging pretty much throughout the project. Ever thought that someone may want to grep on your log?

    Methods like this raise more then an eyebrow. :-)
    isNativeConnectionNecessaryForNativePreparedStatements()
    throwExceptionOnWarningIfNotIgnoringWarnings()

    All that is just about basic coding practice. List can go on...

    Best,
    Nikita.
  22. All right, Juergen, All this whining really got me and so I re-created CVS project, loaded up Spring and poked around. In two minutes, I found 5-6 public classes (why are they all public?) with public methods lacking any Javadoc comments at all. For example, ControlFlow.java. Many exception classes as well... ScheduledTimerTask.java, etc.
    ...
    Another post proving that saying something is so doesn't actually make it so. Here's ScheduledTimerTask, in both JavaDoc and source form:
    http://www.springframework.org/docs/api/org/springframework/scheduling/timer/ScheduledTimerTask.html
    http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springframework/scheduling/timer/ScheduledTimerTask.java?view=markup

    As anybody can plainly see, all methods have JavaDoc comments. If you look at ControlFlow.java, you'll see that it has exactly 2 methods in it, one of which has a JavaDoc comment, and one which doesn't. Quite criminal I admit, this rampant lack of JavaDocs in the whole sourcebase. For the irony impaired, I'm kidding; the funny thing is that we consistenly get comments about the amount and good quality of the JavaDocs for Spring, and we have a consistent record of trying to document code, and improve this documentation as needed or suggested. Are these examples of the the best JavaDocs in Spring? No. Are they the worst? Probably not; I'm sure you could find worse. The JavaDocs are not perfect, but consistently they're good, they're important to us, and they are there and visible, along with the source, compared to your hypothetical perfect closed-source variants. Anybody is free to look around and get their own idea.
      http://www.springframework.org/docs/api/index.html

    W/regards to code quality, you talk about doing code inspections. While almost any codebase can go to a higher quality threshold, I can not believe that anybody who has inspected any serious amount of code ("out there") has much to complain about the Spring codebase. As part of my job for many years I also did due diligence and code inspections on a regular basis, worked with a large number of companies, and can say objectively that the Spring codebase is heads-and-shoulders in terms of quality above the large majority of code I have seen.

    Regards,
    Colin
  23. Colin,
    Here’s what I have for ScheduleTimeTask.java, 1.4 (snippet):
    public class ScheduledTimerTask {

    private TimerTask timerTask;

    private long delay = 0;

    private long period = 0;

    private boolean fixedRate = false;


    public ScheduledTimerTask() {
    }

    public ScheduledTimerTask(TimerTask timerTask, long delay, long period, boolean fixedRate) {
    this.timerTask = timerTask;
    this.delay = delay;
    this.period = period;
    this.fixedRate = fixedRate;
    }
    I never actually implied (see my post) that this is criminal. Slovenly, it is, but not criminal. It just took me literally 2 minutes to randomly poke around to found this and other examples.

    And I agree that among open source project Spring has rather high standing in terms of documentation & code quality.

    As far as code reviews I am not going to argue - we certainly have somewhat different reference bars.

    Good luck,
    Nikita.
  24. Colin,Here’s what I have for ScheduleTimeTask.java, 1.4 (snippet) ...
    Another nice little misleading post created by including just a 'snippet' (of one class in the framework). I'm not going to bother quoting the whole class, but here's the link again:

    http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springframework/scheduling/timer/ScheduledTimerTask.java?view=markup

    Anybody actually taking a look at the source will see that there is a simple JavaBean, there is a class JavaDoc, and every method except that constructor has a JavaDoc, and in fact, every param in that constructor actually is documented in a JavaDoc for an equivalent setter method. Sure, the constructor should have had a JavaDoc, But it's not exactly rocket science for somebody to figure out what those params are, given the other JavaDocs. (fwiw, a look at the history will show the constructor was added later as a convenience
    http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springframework/scheduling/timer/ScheduledTimerTask.java?rev=1.4&view=log
    and somehow the JavaDoc got left out. Accidents happen, but this is exactly the kind of thing we fix all the time when we notice it or somebody points it out. Just today I went into a class to clarify the JavaDoc, based purely on the fact that somebody raised a question about something in a forum posting...)


    Slovenly, yes...

    Colin
  25. Colin,
    Missing Javadoc was my least important point (despite the fact it was mentioned first). Also, I hope you know that empty Javadoc will be generated even for methods that don’t have Javadoc at all :-) That should explain to you the “mystery” of auto-Javadocing…

    So what about the other points that I have made couple of posts up?

    Nikita.
  26. Colin,Missing Javadoc was my least important point (despite the fact it was mentioned first). Also, I hope you know that empty Javadoc will be generated even for methods that don’t have Javadoc at all :-) That should explain to you the “mystery” of auto-Javadocing…So what about the other points that I have made couple of posts up? Nikita.
    Wow, you seem to have a pathological need to agressively denigrate Spring (or us), by either exaggerating or making things up. Yes, I do know that an empty JavaDoc wil be generated for methods that don't have JavaDoc at all, and absolutely nothing I said above would indicate that there was any mystery on my part about auto-JavaDocing. So why are you implying that, except to try to make me look bad or something, although I must say you could have picked a better mechanism as I don't exactly think it's criminal to not know that little tidbit...

    This exaggeration was my main point w/regards to the JavaDocs. Warts and all that they might have, they are objectively pretty good by the standards of most open and close-source java apps, and certainly not 'slovenly'.

    In the same vein, let's take a look at a paragraph from your earlier post:
    Since Spring is an open-source product I and others have a freedom for a more deeper evaluation of it. I found the basic ideas behind it are sound (see above) but implementation (the coding) is mediocre at best and many design decisions are downright flawed. Exception handling is just probably the biggest problem for me (combined with constant pushing of it). Aside from that, I found project organization & packaging is rather broken and hasty (usual problem for open source stuff), (over)usage of inheritance is lighthearted, code quality dismal and conceptual integrity of the project that is lacking.
    Nice and full of unfounded opinion and/or untruths. You say, "I found project organization & packaging is rather broken". This is complete BS. We run an automated build every night, there is a complete and automated ant script in the source which builds everything, including tests which we do run, puts out reference docs, and builds distribution jars. We have put out a significant number of releases (on SF) without ever messing things up or causing pain to our users. We track test code coverage, etc. At the level of supporting the project we have responsive forums. So what the hell in all of this 'rather broken'? I can dispute every one of your points.

    I've had enough of this thread.

    Good night,
  27. Colin,
    By the time you read it I hope you calmed down and got a hold of yourself.

    When I pointed to couple of missing Javadocs for public APIs in your Java source files you referred me to… generated Javadoc. I assumed that you either have no clue on what you are talking about (unlikely) or purposely spinning it, unless of course you consider empty documentation good enough. So, I sarcastically pointed out that “mystery”. The facts are undeniable – the file just missing required Javadocs (as benign as it sounds).

    Enough on Javadocs.
    Nice and full of unfounded opinion and/or untruths. You say, "I found project organization & packaging is rather broken". This is complete BS.


    You and I apparently have different understanding of “organization & packaging”. What I meant is how your classes and interfaces are placed in Java packages. My original question was:
    All classes seem public. Where is the conceptual line between implementation and interfaces? What is intended for the end-use and what is internal implementation? It seems that everything is blob-ed together with everything else.
    I really don’t care about your build process as it is internal and has no direct impact on end users and I am sure you or someone else can do that “complex” task in Spring team. However, the API packaging has a profound effect on usability of software and requires significant design consideration, hence my question.

    When I look at the code (and I still write the code, by the way) I have developed a habit to look for the “small” things among others as they usually tell the big story. One of the many “small” things that I pay attention to is consistency of formatting in various logging. As benign as it sounds it really differentiates often sloppy, one-off code from more mature system. Another place to look is consistency in naming of the language elements. Another is grammatical and punctuation correctness of code comments, etc. Of course, none of these indicators is sufficient on its own to draw a conclusion yet in totality they can present a rather complete picture.

    So, there you have it.

    Regards,
    Nikita.
  28. What's the point. Spring,Struts ....... have given developer community to think about,I would appreciate what they have done, one of the reason JAVA is widely used is because of these frameworks,open discussions.

    The biggest advantage I see with these frameworks it is gives me an insight how the things are done, it doesn't mandates you to use them, it is left you how u do it. Why whining...........

    If you don't like piece of code in any of the framework go ahead change it or re-use it, no body is stopping from doing that.......

    I find it this discussion is going very personal and malicious attack on Spring framework. I hope you are against all open source frameworks ...

    Sounds like MS'ish


    Let's go back to the discussion of Checked and unchecked exceptions. I am of the opinion both should be used where it is required.That kind of decision as an architect/designer you will be making............


    my 2 cents
  29. When I pointed to couple of missing Javadocs for public APIs in your Java source files you referred me to… generated Javadoc. I assumed that you either have no clue on what you are talking about (unlikely) or purposely spinning it, unless of course you consider empty documentation good enough. So, I sarcastically pointed out that “mystery”. The facts are undeniable – the file just missing required Javadocs (as benign as it sounds).
    Listen, I might support use of checked exceptions, but this is ridiculous. You are claiming that you have been pointed to an "auto-generated" Javadoc and that you found it empty (no class or member commentary), well here is the excerpt from one of the classes you've been talking about:
    public class ScheduledTimerTask
    extends java.lang.Object
    JavaBean that describes a scheduled TimerTask, consisting of the TimerTask itself and a delay plus period. Period needs to be specified; there is no point in a default for it.

    The J2SE Timer does not offer more sophisticated scheduling options like cron expressions. Consider using Quartz for such demanding needs.

    Note that Timer uses a TimerTask instance that is shared between repeated executions, in contrast to Quartz which instantiates a new Job for each execution.



    Since:
    19.02.2004
    Author:
    Juergen Hoeller
    See Also:
    TimerTask, Timer.schedule(TimerTask, long, long), Timer.scheduleAtFixedRate(TimerTask, long, long)

    --------------------------------------------------------------------------------

    Constructor Summary
    ScheduledTimerTask()
                
    ScheduledTimerTask(java.util.TimerTask timerTask, long delay, long period, boolean fixedRate)
                
      Method Summary
     long getDelay()
              Return the delay before starting the job for the first time.
     long getPeriod()
              Return the period between repeated task executions.
     java.util.TimerTask getTimerTask()
              Return the TimerTask to schedule.
     boolean isFixedRate()
              Return whether to schedule as fixed-rate execution.
     void setDelay(long delay)
              Set the delay before starting the task for the first time, in milliseconds.
     void setFixedRate(boolean fixedRate)
              Set whether to schedule as fixed-rate execution, rather than fixed-delay execution.
     void setPeriod(long period)
              Set the period between repeated task executions, in milliseconds.
     void setTimerTask(java.util.TimerTask timerTask)
              Set the TimerTask to schedule.
      Methods inherited from class java.lang.Object
    clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
    I can clearly see commentary on the class and on the methods, which usually is quite good enough along with self-explanatory member names. What is it exactly that you have against Sping's documentation such that even with proof provided you are still in denial? C'mon take a closer look and stick to the facts.

    If you think your support resources and documentation are flawless check the developer forum on your website: http://www.fitechlabs.com/forum/index.jspa.

    By the way, that is some exception handling, it is really interesting to know the following:
    Error:
    You do not have a valid license for this product. Please check the jiveHome/logs/jive.error.log file for error messages.
    It is indeed a minor thing, but since you are trying to deface Spring by pointing out such minor things as well than here you go.

    One thing is a technological dispute, but the "you suck, no you suck" discussion has nothing to do with the TSS purpose and definitely nothing with original topic of discussion. It is a shame to see members of two well-known and respected entities behave in such unprofessional manner.

    Are you going to compare sizes next?

    Regards,

    Artem D. Yegorov
  30. Konstantine,
    Sorry to ruin your hope, nut it is ridiculous to restate in Javadoc the same thing that method signature tells clearly and loudly.
    Well, in a product company you have somewhat different requirement and we always prefer to err on the side of more documentation. I would challenge you to find any commercial software product (framework, such as Spring) that would just rely on signature and parameters names for documentation.

    Artem,
    Listen, I might support use of checked exceptions, but this is ridiculous. You are claiming that you have been pointed to an "auto-generated" Javadoc and that you found it empty (no class or member commentary), well here is the excerpt from one of the classes you've been talking…
    I am bit tired of this Javadoc deal. I was just casually pointing that public API has not Javadoc in Java source (and no, auto-generated empty Javadoc that you and others stumbling on is not counting in my book). Wise up.

    As far as forum we of course know it’s down but we are having strange dispute with Jive Software regarding our license. We are working on it. Here is the link to our Javadoc, which is more relevant to our discussion: http://www.fitechlabs.com/javadoc/index.html

    Best,
    Nikita.
  31. Nikita,
    I am bit tired of this Javadoc deal. I was just casually pointing that public API has not Javadoc in Java source (and no, auto-generated empty Javadoc that you and others stumbling on is not counting in my book). Wise up.
    Do not take it personally, as it and other stuff is really irrelevant to the core of the discussion. You made a point of something and I made a point back.
    I have absolutely no wish to argue with you and respond to any type of patronizing insults like "Wise up". Stick to your guns, I'll stick to mine.

    As far as your APIs JavaDoc is concerened it is pretty amazing given the detail of documentation, diagrams and clarity. So kudos on that.

    Forum was a minor thing that was worth mentioning after the heat of the discussion has taken everybody into the nonsense realm.

    Anyway...nobody is discussing lightweight service-oriented frameworks here or even the checked vs. unchecked exception anymore. I guess , time to move on for me as well.

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  32. Here is the link to our Javadoc, which is more relevant to our discussion: http://www.fitechlabs.com/javadoc/index.html
    HTTP Status 404 - /javadoc/index.html
    The requested resource (/javadoc/index.html) is not available.
    Apache Tomcat/4.1.29
  33. javadoc nonsense example[ Go to top ]

    Konstantine,
    Sorry to ruin your hope, nut it is ridiculous to restate in Javadoc the same thing that method signature tells clearly and loudly.
    Well, in a product company you have somewhat different requirement and we always prefer to err on the side of more documentation. Here is the link to our Javadoc, which is more relevant to our discussion: http://www.fitechlabs.com/javadoc/index.htmlBest,Nikita.
    Constructor Summary
    BoolArrayFactory(int size)
              Creates factory for creation of BoolArray instances.
     
    Method Summary
     java.lang.Object createObj()
              Creates and returns new object.
     void disposeObj(java.lang.Object obj)
              Disposes given object.

    The example above taken from your Javadocs and IMO clearly represents wasted time on nonsensical comments to the obvious things and in the same time ommitting important ones like meaning of Size parameter in the constructor.

    If developers were required to produce _meaningfull_ comments then they would comment on 'size' parameter and nothing else.

    IMO the Javadocs above is absolutely meaningless and exists solely for nice management report regarding project metrics.
    I would challenge you to find any commercial software product (framework, such as Spring) that would just rely on signature and parameters names for documentation.
    I never ever advocated reliance on signature and parameters names only. But it is _preferred_ method of documentation ( if possible ).
  34. javadoc nonsense example[ Go to top ]

    Konstantine,
    I’m trying to be nice but it’s getting harder and harder :-)
    Constructor Summary
    BoolArrayFactory(int size)
              Creates factory for creation of BoolArray instances.
     
    Method Summary
     java.lang.Object createObj()
              Creates and returns new object.
     void disposeObj(java.lang.Object obj)
              Disposes given object.

    The example above taken from your Javadocs and IMO clearly represents wasted time on nonsensical comments to the obvious things and in the same time ommitting important ones like meaning of Size parameter in the constructor.
    If you click for detail description of the constructor and bout 25 pixels below on the screen after:
    BoolArrayFactory(int size)
              Creates factory for creation of BoolArray instances.
    You will see the following:
    Parameters:
    size - Size of arrays to create, cannot be negative.
    So, why are doing it? I hope you do know how to operate HTML-based Javadoc… Check you postings twice; it will save you from looking caught “pants down”.

    Regards,
    Nikita.
  35. javadoc nonsense example[ Go to top ]

    So, why are doing it? I hope you do know how to operate HTML-based Javadoc… Check you postings twice; it will save you from looking caught “pants down”.Regards,Nikita.
    My honest apologies. I was too lazy to scroll that screen.

    However I still consider this comment unnecessary:
    >>Parameters: size - Size of arrays to create, cannot be negative.
    Changing parameter name to ‘arraysLength’ would suffice.

    From reading comments to the methods createObj and disposeObj I would say that those names are not quite appropriate and misleading, I would suggest: borrowObj and returnObj, which would imply things you have described in comments.

    If names were renamed then comments are unnecessary IMO, but their existence would nicely reinforce implied message.

    Please do not take this as attack on your product or documentation; I just use it as illustration to my point.
  36. Hi Konstantin,

    For the most part I agree with your posts on TSS, except for this thread :-) You seem to know your stuff. However, I don’t think you fully understand the meaning of the ObjectPoolFactory interface provided by object pool service in xTier, and hence you do not understand BoolArrayFactory class which implements that interface:
    Konstantin:
    From reading comments to the methods createObj and disposeObj I would say that those names are not quite appropriate and misleading, I would suggest: borrowObj and returnObj, which would imply things you have described in comments.
    The factory’s responsibility is to create the objects to be pooled and dispose of them before they are given to GC – they are analogous to constructor and distractor for the pooled objects. One is called to _create _ an object, not borrow it, another is called right before the object is given to GC or _disposed_.

    I think you are confusing ObjectPoolFactory operations with ObjectPool operations. For example, the ObjectPool interface has methods like _acquire()_, _acquireWait(long)_, and _release()_.

    Regards,
    --Dmitriy.
  37. Dmitry,
    Hi Konstantin,For the most part I agree with your posts on TSS, except for this thread :-) You seem to know your stuff. However, I don’t think you fully understand the meaning of the ObjectPoolFactory interface provided by object pool service in xTier, and hence you do not understand BoolArrayFactory class which implements that interface:
    Konstantin:From reading comments to the methods createObj and disposeObj I would say that those names are not quite appropriate and misleading, I would suggest: borrowObj and returnObj, which would imply things you have described in comments.
    The factory’s responsibility is to create the objects to be pooled and dispose of them before they are given to GC – they are analogous to constructor and distractor for the pooled objects. One is called to _create _ an object, not borrow it, another is called right before the object is given to GC or _disposed_.I think you are confusing ObjectPoolFactory operations with ObjectPool operations. For example, the ObjectPool interface has methods like _acquire()_, _acquireWait(long)_, and _release()_.Regards,--Dmitriy.
    Of course I do not know how that factory works, I simply read javadocs:
    http://www.fitechlabs.com/javadoc/com/fitechlabs/xtier/services/objpool/arrpools/BoolArrayFactory.html
    createObj

    public java.lang.Object createObj()

        Description copied from interface: ObjectPoolFactory
        Creates and returns new object. Note that there is no requirement that this method should return a new instance everytime. Implementation is free to reuse objects if it is required or applicable so.

        Specified by:
            createObj in interface ObjectPoolFactory

        Returns:
            Newly created object.
        See Also:
            ObjectPoolFactory.createObj()
    I guess that excerpt above just proves my point: method signature could accurately describe method intension and deeds (your description) and it is extremely easy for javadoc to be out of sync with reality:
    >>Note that there is no requirement that this method should return a new instance everytime. Implementation is free to reuse objects if it is required or applicable so.<<
    The comment sounds like reuuse-or-create pool functionality, therefore my suggested name 'borrowObj'

    So, what was here about pants? :)
  38. Konstantin, I will be brief.

    Where have you seen a factory class with method name _borrow_ as opposed to _create_? It is a very standard practice that factory interfaces/classes have _create_ method. Yet none of the factories ever state that you _must_ return a new object. You can do whatever you want in your implementation.

    We are using a standard design practice here – javadoc stands!

    It seems that you don’t care to look around and prefer to blindly take interfaces out of context (your previous posts suggest the same). There are 2 interfaces in objpool package: ObjectPool and ObjectPoolFactory. They even have self-explanatory names which you like. Why in the world would you confuse the two?

    Regards,
    --Dmitriy.
  39. Meaning of words in source code should not be different from everyday use:
    create - http://webster.com/cgi-bin/dictionary?book=Dictionary&va=create&x=0&y=0
    is not appropriate word for a method that might omit act of creation.
    Do not like 'borrow' that _implies_ act or returning/disposing, use neutral 'get'.

    >>We are using a standard design practice here – javadoc stands!
    Using 'standard design practice' does not prohibit usage of standard speech patterns.
  40. Do not like 'borrow' that _implies_ act or returning/disposing, use neutral 'get'.
    Konstantin, ObjectPoolFactory is implemented by user, not by xTier. We only provide the interface.

    Inside the createObj() method user will most likely _create_ new objects and return them. These objects will end up in the object pool. When object pool is being shutdown or shrinks in size, objects in the pool are passed into disposeObj(Object) method.

    In 99.9% of the cases the factories will instantiate new objects and return them. However, there are some rare cases when a factory potentially could, for example, reset the object in disposeObj(Object) call and then return them from consequent calls to createObj() method. Note, that the same factory can be reused across different object pools.

    However, as far as ObjectPool is concerned, the objects returned by the factory are semantically created - thus the name 'createObj()'.

    I seriously considered the names you are proposing, such as get or borrow, but I believe that they would be very confusing here.

    Thanks,
    --Dmitriy.
  41. javadocs[ Go to top ]

    ScheduleTimeTask.java is kind of self explanatory and do not really need Javadocs. Personally I prefer self documenting style, where class-,method-,and variable-names are meaningful enough.

    What is better style 1 or 2?
    #1:
    long delayInSeconds;
    or #2:
    /**
    * this is rarely used field that hold delay value in seconds
    */
    long _d;

    I vote for #1 and I consider requirement to document all code to be ridiculous.
  42. javadocs[ Go to top ]

    Konstantine,
    I clearly referred to public APIs missing any Javadoc. I think you would agree that’s not ridiculous to require any public API to have extensive Javadocs in projects like Spring.

    As far as private APIs – it’s up to each project.

    Self documenting can also go to absurd extremes. These methods from Spring are the good example:
    isNativeConnectionNecessaryForNativePreparedStatements()
    throwExceptionOnWarningIfNotIgnoringWarnings()

    Regards,
    Nikita.
  43. javadocs[ Go to top ]

    Konstantine, I clearly referred to public APIs missing any Javadoc. I think you would agree that’s not ridiculous to require any public API to have extensive Javadocs in projects like Spring. As far as private APIs – it’s up to each project. Self documenting can also go to absurd extremes. These methods from Spring are the good example:isNativeConnectionNecessaryForNativePreparedStatements()throwExceptionOnWarningIfNotIgnoringWarnings()Regards,Nikita.
    Yes, this is the first rule how to write unmainable code, declare "How" method is implemented and nobody will know "That" it doe's.
  44. javadocs[ Go to top ]

    Konstantine, I clearly referred to public APIs missing any Javadoc.
    I apply logic that I'v stated above to the public and interface classes. In short: Javadocs should exist only for non-obvious things.
    I think you would agree that’s not ridiculous to require any public API to have extensive Javadocs in projects like Spring.
    Sorry to ruin your hope, nut it is ridiculous to restate in Javadoc the same thing that method signature tells clearly and loudly.
    Also, when method signature seems vague, it helps to read it package- class- name and signature as one English sentence. Source code should be READABLE!!! that is the key.
    Well, there are cases when it is not clear at a glance what method/field does that might be OK too. Those things exist in the context of program. Do you expect to understand what is going on in a novel by reading one sentence in a middle of that book?

    PS: By no means I discourage Javadoc comments, they are necessary …. sometimes
  45. I found [Spring's] implementation (the coding) is mediocre at best and many design decisions are downright flawed. [...] project organization & packaging is rather broken and hasty (usual problem for open source stuff), (over)usage of inheritance is lighthearted, code quality dismal and conceptual integrity of the project that is lacking.
    Really strange. Is this some version of Spring in a parallel universe that I know nothing about? The copy I have here is one of the most robust, well-organised, well-documented and heavily unit tested open source products I have had the pleasure to work with.

     - Peter
  46. Gavin King is on record as saying that he wished Hibernate had chosen unchecked exceptions, and Hibernate 3 switches from checked to unchecked exceptions.
    That would be very unfortunate move. Lack of checked Exceptions prevents me from using Spring, I would not call the design flawed, there are two mindsets: one welcomes checked exceptions and another rejects them.

    To the defence of unchecked exceptions I would say that it is possible to create very useful and robust systems without exceptions at all (Unix),
    but I am big time supporter of checked exceptions and I do not want to worry constantly if something can suddenly be thrown from lower levels and I do not like when library/framework developer decides for me if _I_ can or cannot deal with exceptions. That smells MSft.

    Long live checked exceptions!
  47. Dmitriy, spare us the drama here. You lose all credibility with your "guarantee" that developers using Spring have "no clue" where exceptions are handled. And the written origin of Rod's ideas on exceptions - in his first book - clearly state the cases where checked exceptions are the right idea and where unchecked exceptions can be a better fit. It's probably too much to ask you to bother to read it, as that might deaden your knee-jerk reaction to posting yet another tiresome, mis-informed attack on Spring. Unfortunately for you, those that adhere to the guidelines in that book - and that book is hardly alone in advancing such guidelines - are happily using *both* unchecked exceptions and checked exceptions in logical places in their applications, and know nothing of the chaos that you seem intent on implying as the inevitable fate of Spring users.
  48. I am not arguing for unchecked exceptions here, but I wish there is a way to turn all the unchecked exceptions inside the JDK into checked with just a setting, then we'll see how all these checked exception zealots handle OutOfMemory, IllegalArgument, and their various other friends with just about every method or constructor call. I bet they would all have coded their stuff with the beloved try { } catch(Exception allException). To me, RuntimeExceptions are about choice BUT they have to be documented.
  49. It's probably too much to ask you to bother to read it, as that might deaden your knee-jerk reaction to posting yet another tiresome, mis-informed attack on Spring
    Let me rebuke couple of "blind-folded" followers over here...
    Since I work with Dimitry and I know that we both read the Rod's book. We didn't get much new information in it but Rod’s a good writer and it was a pleasant reading even if I disagree with some in particular, especially the error handling "doctrine".

    I will strongly restate the Dmitry’s point that system based on the error handling such as dictated by Spring have inheritably flawed stability.
    Unfortunately for you, those that adhere to the guidelines in that book - and that book is hardly alone in advancing such guidelines - are happily using *both* unchecked exceptions and checked exceptions in logical places in their applications, and know nothing of the chaos that you seem intent on implying as the inevitable fate of Spring users.
    I’m glad you adhere to something but the problem is that stability issues come up much later in the life of a project and thus are much costly to fix making the right choice extremely vital for the success of the project. So the reason is that many of like you don’t see the rather obvious flaw is just a manifestation of the fact that Spring is pretty new software.
    I am not arguing for unchecked exceptions here, but I wish there is a way to turn all the unchecked exceptions inside the JDK into checked with just a setting, then we'll see how all these checked exception zealots handle OutOfMemory, IllegalArgument, and their various other friends with just about every method or constructor call.
    You need to get off that medication of yours, seriously… Nobody suggested getting rid of runtime exception – it’s just right balance and design that are in question. Wise up.
     
    In place where we work we have somewhat unique expertise working with .NET (no checked exceptions) and Java. So instead of theorizing we have a first hand experience with what runtime-only exceptions mean for a large and long-running middleware project.

    Regards,
    Nikita.
  50. Dmitriy, spare us the drama here. You lose all credibility with your "guarantee" that developers using Spring have "no clue" where exceptions are handled. And the written origin of Rod's ideas on exceptions - in his first book - clearly state the cases where checked exceptions are the right idea and where unchecked exceptions can be a better fit.
    I guarantee it because I know first hand that it is true. Even .NET C# language, which entirely lacks checked exceptions, leaks undocumented exceptions. It is extremely hard to build robust applications based on C# (believe me, I tried), and it must be hard to build robust applications based on Spring. Of course, you can stick your head in the sand and claim that no exception in your code leaks out... That may be true if your application is running on less than 50 classes and you checked all classes and all methods one by one – any serious application must use checked exceptions to guarantee robust error handling.

    Moreover, if Rod is so balanced in his exception usage, how come then out of about a 100 exceptions created by spring framework, there is only 1 checked exception – MetadataAccessException. It was pretty bold of Rod to decide that metadata access errors should be checked and handled within application, but Database access errors should not.

    <blocquote>
    It's probably too much to ask you to bother to read it, as that might deaden your knee-jerk reaction to posting yet another tiresome, mis-informed attack on Spring. The fact that Rod wrote a book does not make him right! You should not take for granted every word that he writes – sometimes it does not hurt to use your own experience and judgment. And by the way, Yes, I read his book. Please keep your focus on the discussion, not on personal attacks.
    Unfortunately for you, those that adhere to the guidelines in that book - and that book is hardly alone in advancing such guidelines - are happily using *both* unchecked exceptions and checked exceptions in logical places in their applications, and know nothing of the chaos that you seem intent on implying as the inevitable fate of Spring users.
    I do not imply the inevitable fate of Spring users. There are plenty of systems written in C and C++ without any checked exceptions at all. You can even chose to write your so-called robust code in assembly if you are a masochist.

    Usage of checked exceptions makes it much easier to properly handle all errors and gives much higher guarantees about the robustness of the code – this is the undeniable fact!

    Regards,
    --Dmitriy.
  51. It must be interesting to see not trivial the "real world" example with checked exceptions, problem and motivation to see how it makes code more robust, I can help to convert this example to "unchecked" (but not on this forum please, do you have some blog ?) I am sure it will not help to prove something, but it can be more interesting discussion than plain claims.
  52. It must be interesting to see not trivial the "real world" example with checked exceptions, problem and motivation to see how it makes code more robust, I can help to convert this example to "unchecked"...
    Checked exceptions make code more robust because you know which exception can be thrown at any point of time, thus you know what to handle. Also, there is no possibility of _forgetting_ to handle an exception.

    However, you keep claiming in all your posts that robust applications must produce core dumps. Such claims are immature enough to drive away even such hard-core unchecked exception junkies as Rod.

    Regards,
    --Dmitriy.
  53. It must be interesting to see not trivial the "real world" example with checked exceptions, problem and motivation to see how it makes code more robust, I can help to convert this example to "unchecked"...
    Checked exceptions make code more robust because you know which exception can be thrown at any point of time, thus you know what to handle. Also, there is no possibility of _forgetting_ to handle an exception.However, you keep claiming in all your posts that robust applications must produce core dumps. Such claims are immature enough to drive away even such hard-core unchecked exception junkies as Rod.Regards,--Dmitriy.
    Yes, prefer "core dump" it help to fix problem and I am sure it is better not to handle exeptions and to die on unexpected error than to try find workaround and to
    produce side effect. "finally" is a very good way to cleanup before to die, but I do not understand how design by exception can help for robust systems.

    1)
    try{
     
       action1();

      }catch( SomeErrorThrownBySomeLayerIDoNotKnow e ){
         try{
           doWorkaround();
          }catch(WorkaroundFailedException next){
            try{
             doNextWorkaround();
             }catch(NextWorkaroundFailedException next1){
                   ............
                  }catch(WorkaroundNFailedException nextN){
                     ...........
                  }
                   
             }
          }

       }

    2)
    try{
     
       action1();

      }catch( CatchMeIDoNotKnowHowToHandleItMyself e ){
           // It will never happen, I have tried it on my PC
       }


    3) void DragAndDropMe()throws SorryICanDoItOnWindowsOnlyDoNotForgetToTrySomeWorkaround;

    4) void tooManyExceptionsToDeclareInThrowClause()throws IAmJustWrapperTryCause;

    5) void click() throws ItWillUseIOTryIt, ButItWillUseSQLToo, ProbablyIWillNeedToConnectToLDAPLaterTooCatchitYourself, ....

    I think it is better to clear stuff you allocate in "finally" and die on exception than to try make more space on disk in IO exeption handler or to try to fix firewall configuration on RemoteException or DropConstraintOnSQLException.
  54. If you have to implement failover in your code, for instance authenticating against an LDAP directory and you have more than one instance, out of which any may go down, but one will always be running, and you have to authenticate the user, dying will not really help and let's say throwing a 500 error (if done over HTTP) will not gain your product lot's of credability and acceptance.

    You have to catch your exception and have the logic to go against the other LDAP instance, until connection is successful, so to successfuly authenticate the user and provide the service no matter what, as well as interpret the complete communication failure in case all of the instances are down and present the user with a meanigful error message and record a meanigful error code and technical error description for the support personell.

    A Generic "excuse" message like "Generic Error: Sorry our system just died for whatever reason, we will fix it as soon as we figure out what happened by grepping all of log files for last hour exceptions if the developer handled the exception at least generically" will not cut it. Alerting support personell with menaigful error code and description over a pager/email/RIM or whatever will get the problem solved much quicker. And having things recorded will give you an ability for good statitical reports to pinpoint weak links in your infrastructure/implementation.

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  55. Usage of checked exceptions makes it much easier to properly handle all errors and gives much higher guarantees about the robustness of the code – this is the undeniable fact!
    Dmitriy, I followed typical Java convention and defined very few unchecked exceptions in my first few years of using Java. Like you, I was utterly convinced by the theoretical arguments that high use of checked exceptions would help to guarantee correctness. Like you I was shocked when someone first suggested greater use of unchecked exceptions.

    Back in 2001 I did I thorough look through the codebase of numerous open source products and sample applications and--far more importantly--several real, large, J2EE applications. I began to see that this theoretical guarantee is just that: when you look at how exceptions are handled in any large, real, application, it's obvious that this "guaratee" doesn't scale well in practice. For example, it's rare to recover after a data access exception. Yet there is typically reams of code dealing with SQLException (which of course has many more serious problems than being checked), catching and wrapping, catching and wrapping and losing stack traces, obscuring readability etc. The reality is that there's a tradeoff, and you're taking an extreme view, ignoring the negative side of checked exceptions for conditions that are usually unrecoverable.

    Shortly afterwards I discovered that I wasn't alone, and saw some of what people like Bruce Eckel had written on the subject. His argument about how the conclusions you might make based on small programs not applying well to large code bases really tallied with mine.

    I know you've read my book, but I find it hard to believe that you approached the material on checked exceptions with anything like an open mind.

    Rgds
    Rod
  56. To take an issue with your title (Good Exception Hierarchy != Unchecked Exceptions), exception hierarchies are less useful with checked exceptions, because you still need to catch the base class. For example, with DataAccessException being unchecked, it's possible to catch only DataIntegrityViolationException if that's the only condition you can retry. If DataAccessException were checked, you would need to catch it also in an additional catch block, and the compiler would no longer be enforcing the catch block for the exception you were actually interested in.
  57. Shortly afterwards I discovered that I wasn't alone, and saw some of what people like Bruce Eckel had written on the subject. His argument about how the conclusions you might make based on small programs not applying well to large code bases really tallied with mine.
    Of all the people, you chose Bruce Eckel. Bruce hasn’t had a sane idea in a decade. Just look to community replies around his latest articles. However, it gives me a good understanding of how you derive your opinions.

    You keep saying that many projects abused and misused checked exceptions and therefore unchecked exceptions must be better. This argument holds no water because it can be easily reversed – many projects do abuse unchecked exception and therefore checked exceptions must be better.
    I know you've read my book, but I find it hard to believe that you approached the material on checked exceptions with anything like an open mind.
    I gave your book a fair chance, however I largely disagree with your believe that you can decide for everyone which errors are fatal and which aren’t. Moreover, fatal errors are also important and in many cases must be handled.
    With unchecked exceptions you loose track of error handling in your code.

    --Dmitriy.
  58. Of all the people, you chose Bruce Eckel. Bruce hasn’t had a sane idea in a decade. Just look to community replies around his latest articles.
    Well I could have chosen plenty of other people besides Bruce. This is what I meant by "here we go again" after your first post. So far in this thread you have grossly patronized everyone who disagrees with you. Bruce Eckel is now apparently insane because he disagrees with you, and Nikita has told someone else to "get off their medication" and "wise up". No wonder I (and others) cringe whenever this topic comes up.

    Sure, Bruce is sometimes wrong. Everyone is. But he's a smart guy and has a lot of worthwhile things to say. I can recall you abusing him here before, but I haven't seen a detailed rebuttal of his arguments.
    However, it gives me a good understanding of how you derive your opinions.
    If you'd actually read my post you would see that I noted that I came to my conclusions before seeing Bruce's views on this.

    Btw, my observations based on the applications I reviewed have been confirmed by my experience since, when I've made greater (but not exclusive) use of unchecked exceptions.
    I gave your book a fair chance, however I largely disagree with your believe that you can decide for everyone which errors are fatal and which aren’t.
    Yes, that's right. I want to decide on which errors are fatal for all Spring users and everyone else as well. If you attempt to write code to catch say Spring's DataAccessException or any of it's subclasses I'll personally come and take your hands off the keyboard. You can catch unchecked exceptions if you want to. Don't you see that you're determined to make the decision the other way?
  59. Rod,
    We are "taking" on Spring, as you allude, in part because this is probably the only well-known software project that has an audacity to heavily advertise its, in our and many other’s opinion, seriously flawed error handling design.

    But I have a more interesting observation, I think. It seems to me, judging by your posts, that you and others of your ilk really believe that you have uncovered and smartly corrected a significant flaw in Java design and doing a good service to a developers’ community informing them about the "right" way of doing things.

    Yet in my opinion and those who agree with my point of view - you simply missed the point and allowed your novice and amateur experiences working with Java in the early days to derail you into land of make-believes and self-fulfilling prophecies constantly reinforced by many "followers" who are lazy enough to think for themselves or challenge your points.

    Best,
    Nikita.
  60. Rod, We are "taking" on Spring, as you allude, in part because this is probably the only well-known software project that has an audacity to heavily advertise its, in our and many other’s opinion, seriously flawed error handling design.
    Have you actually tried it, Nikita? Or are you arguing on theoretical grounds only? Like you, and like Rod, I was a sceptic at first. Checked exceptions make so much sense. But having switched to a judicious use of unchecked exceptions on real, sizeable projects, I find that none of the horrors that you are so vigorously predicting materialise. If anything, error handling has improved, and our code has become more readable. It is important to appreciate that this isn't limited to just having shorter throws clauses. It also eliminates much exception wrapping code (which is so often turned into a total mess anyway).

    Reality is so very hard to argue with on theoretical grounds, don't you think?
    [you] simply missed the point and allowed your novice and amateur experiences working with Java in the early days to derail you into land of make-believes and self-fulfilling prophecies constantly reinforced by many "followers" who are lazy enough to think for themselves or challenge your points.
    I actually don't want to respond to this. I just thought this was so good that it ought to be framed in a blockquote.

    Your lazy, novice, and derailed follower,

     - Peter
  61. So far in this thread you have grossly patronized everyone who disagrees with you. Bruce Eckel is now apparently insane because he disagrees with you, and Nikita has told someone else to "get off their medication" and "wise up". No wonder I (and others) cringe whenever this topic comes up.
    Not having a "sane" idea, as I phrased it, and calling someone insane, as you did, are two different things. Bruce Eckel does not hold any credibility in Java community anymore, and I am not talking about unchecked exceptions only. Check his latest articles and posts around them (even here on TSS). There is only a small group of followers who will find Bruce Eckel's latest ideas credible, and apparently you are one of them. Again, it explains a lot where you stand.

    By the way, if you cringe when this topic comes up then remove unchecked exceptions from the Spring marketing campaign because I cringe every time you bring it up.
    You can catch unchecked exceptions if you want to.
    With your erroneous unchecked exception strategy YOU DON'T KNOW in what methods and even in what application layer your unchecked DataAccessException pops up. Period!

    You took on a whole mission to save developer a simple throws clause declaration at the expense of clarity and robustness.

    Regards,
    --Dmitriy.
  62. With your erroneous unchecked exception strategy YOU DON'T KNOW in what methods and even in what application layer your unchecked DataAccessException pops up. Period!You took on a whole mission to save developer a simple throws clause declaration at the expense of clarity and robustness.Regards,--Dmitriy.
    Note that DataAccessExceptions thrown by Spring DAOs are usually the result of a *cleaned-up* data access operation. In other words, there are never leaking resources: Everything's properly closed and cleaned up already. So a caller does *not* have to worry about catching those exceptions for cleanup!

    This is why most callers can let such exceptions through without worries, to be logged at the outermost error handler level. I don't see why this would cause a lack of robustness... An unchecked exception that demands resource cleanup by the caller would be questionable, but this is never the case with Spring.

    BTW, I believe that it *is* valid to look at how other frameworks handle exceptions. Besides Hibernate3, TopLink and JDO, the iBATIS DAO framework - the only other well-known open-source DAO framework besides Spring - uses an *unchecked* DaoException too. So will you also attack Clinton Begin now?

    Juergen
  63. Note that DataAccessExceptions thrown by Spring DAOs are usually the result of a *cleaned-up* data access operation. In other words, there are never leaking resources: Everything's properly closed and cleaned up already. So a caller does *not* have to worry about catching those exceptions for cleanup!

    This is why most callers can let such exceptions through without worries, to be logged at the outermost error handler level. I don't see why this would cause a lack of robustness... An unchecked exception that demands resource cleanup by the caller would be questionable, but this is never the case with Spring.
    Excellent point!

    What makes you think that when working with database, my code does not hold a JMS connection open at some upper level... Or maybe, I am also in the midst of talking to some legacy system. For Christ sake, what if I am dealing with two databases? Does spring DAO framework clean up all resources and my kitchen sink too?

    You bring up a very simple use case and scream out loud – "It works!". On a larger scale you fail to see that my application may have 10 other open resources that will be left in unknown state just because your DAO exception penetrated all the way through the whole application code to the 'main' method. Such behavior can hardly be called robust.

    At the end, companies will have to decide what is a better saving for them: a _throws_ clause, or a support call at 2am.

    Regards,
    --Dmitriy.
  64. What makes you think that when working with database, my code does not hold a JMS connection open at some upper level... Or maybe, I am also in the midst of talking to some legacy system.
    Well, you should clean up your JMS or legacy system connection in a finally block anyway - there could always be Errors or RuntimeExceptions. So following those common guidelines that are generally considered a best practice, this will properly work even if a DAO throws an unchecked exception - your finally block will do the cleanup in any case.
    For Christ sake, what if I am dealing with two databases? Does spring DAO framework clean up all resources and my kitchen sink too?
    If you're talking to multiple databases through Spring DAOs or talking to JMS through Spring's JMS support, Spring will indeed clean up *all* involved resources automatically. The same applies to Spring-managed transactions. Believe it or not, this does work properly without the user having to worry about it too much. And for custom code, write proper finally blocks.

    My point is that you usually do not need to be aware of the specific DAO failure that happended, because you don't need to code specific cleanup for the resource that caused the failure. Of course, you still have to assume general failures, so code your custom resource access defensively through finally blocks. This scenario does arguably *not* require checked exceptions.

    Juergen
  65. Juergen:
    An unchecked exception that demands resource cleanup by the caller would be questionable, but this is never the case with Spring.
    Yes, IT IS the case with Spring... My logic may have 10 other resources outside of Spring DAO framework and unchecked exceptions thrown by Spring will not clean them up. Cleaning the resources in a finally clause may not even be an option for a user since it can be in totally different thread of execution. Runtime exceptions thrown by Spring will kill their threads and leave the rest of the application in the limbo state.
    Juergen:
    Please concentrate on your own commercial application framework, and stop spreading FUD about design decisions in open source products that were made in totally different contexts and for totally different purposes.
    You say it like being a part of commercial product is the same as joining Nazi party :-)

    Need I remind you that Spring is also a commercial entity? Moreover, as Rod states, most of its earnings are used to pay your salary. So don’t make it sound like you don’t have a commercial interest.
    You still prefer to not mention that your own product competes with Spring - to some degree, at least. I'm aware that you want to make people believe that you do not compete with Spring in the first place, but looking closer, you *do* compete in some respects, even if maybe targeting a different audience.
    Well, Sherlock... You got me :-)

    Your deep and thorough investigation, composed of clicking on my name on TSS and looking into other threads I participated in, revealed the very secret fact that I am a part of a commercial entity called xTier which in some respects does compete with Spring.

    The reason I didn't mention it is because it has absolutely NOTHING to do with exception handling strategy picked by Spring. If you have any criticism or saw any design flaws in our product, feel free to reveal them and I will be happy to prove you wrong again.

    By the way you never clearly stated in this thread that you work for Spring either. Stop hiding and come out clean! :-)

    Regards,
    --Dmitriy.
  66. My logic may have 10 other resources outside of Spring DAO framework and unchecked exceptions thrown by Spring will not clean them up. Cleaning the resources in a finally clause may not even be an option for a user since it can be in totally different thread of execution. Runtime exceptions thrown by Spring will kill their threads and leave the rest of the application in the limbo state.
    Sorry, I don't understand what you mean here. You should *always* clean up in a finally block within the thread that you invoked the operation in. If you let a thread work with a resource that it is not responsible for cleaning up, you're in trouble anyway: You can always get unexpected Errors or RuntimeExceptions, which will kill your thread then. You need to code defensively against that: Always code proper cleanup procedures.

    My point is that in such a defensive case, you don't care what kind of exception you get: Just just clean up and let the exception pass through. Checked exceptions don't help here, if you usually can't handle them in a special manner anyway. The Error/RuntimeException-aware cleanup code needs to be there anyway, no matter whether the data access library throws checked or unchecked exceptions.

    Thus, your scenario is arguably not an illustration for a deficiency in Spring's exception handling but rather for a lack of proper cleanup and defensive coding in the custom thread handling of your application. Mind you that I'm purely talking about usually fatal exceptions here: If there's an exception with business meaning which is usually recoverable, it should of course be checked - no doubt about that.
    You say it like being a part of commercial product is the same as joining Nazi party :-)Need I remind you that Spring is also a commercial entity? Moreover, as Rod states, most of its earnings are used to pay your salary. So don’t make it sound like you don’t have a commercial interest.
    I admit that this was a kind of knee-jerk reaction; please re-read your tone above to see where this came from. Anyway, I didn't want to imply that Spring did not have commercial backing - I just wanted to point out that you do have a commercial interest in making Spring look inappropriate. Note that we never attacked your product, despite our "commercial interest"; rather, *you* attack our product and Rod as a person every time you have the chance to,
    Your deep and thorough investigation, composed of clicking on my name on TSS and looking into other threads I participated in, revealed the very secret fact that I am a part of a commercial entity called xTier which in some respects does compete with Spring. The reason I didn't mention it is because it has absolutely NOTHING to do with exception handling strategy picked by Spring
    .
    Don't make it sound like I just did that research on the occasion of this thread. We had the pleasure of meeting repeatedly on TSS, and we even already had a discussion about your competing efforts. Questioning Spring's exception handling is one thing; making it sound ridiculous or dangerous in a very harsh and offensive tone is a completely different thing. The former is perfectly fine, of course; it's the latter which makes one wonder about your motivations.
    By the way you never clearly stated in this thread that you work for Spring either. Stop hiding and come out clean!
    Oh my, you caught me now ;-) Seriously, I guess most inclined TSS readers know about my role in the Spring project. Well, when talking about Spring - the topic here -, everyone can easily find out who's involved there. In contrast to that, we're not talking about xTier here, aren't we, so how should readers know who you are and why there is so much vibrant aggression against Spring in some of your posts? They certainly can't find out through googling about the topic.

    Juergen
  67. I will ignore all the fluff you posted, and concentrate on the _stuff_ only.
    Juergen:
    Sorry, I don't understand what you mean here. You should *always* clean up in a finally block within the thread that you invoked the operation in. If you let a thread work with a resource that it is not responsible for cleaning up, you're in trouble anyway: You can always get unexpected Errors or RuntimeExceptions, which will kill your thread then. You need to code defensively against that: Always code proper cleanup procedures.
    Nobody is provoking defenseless coding. But you either purposely or due to some, deeply embedded by now, blinded-ness make it sound like if one thread in application dies, all other threads can go on with their business like nothing happened.

    That is NEVER the case! If one thread dies, all others are left in the limbo state – you cannot argue with such fundamental statement. This is exactly the behavior provoked by Spring runtime exception policies – let the thread of execution die and all other threads can produce crap... So what? Fatal errors almost never happen... Why should we be concerned with them?

    Your statement that you can always get unexpected RuntimeException’s in your code is absolutely false (unless, of course, you are a Spring user). If you don’t use runtime exceptions for failures that can happen in production – then you will NEVER get Runtime exceptions in production (please, don’t count NPE’s and the like here, because they are a result of buggy code and should not happen in production).

    Regards,
    --Dmitriy.
  68. ... Your statement that you can always get unexpected RuntimeException’s in your code is absolutely false (unless, of course, you are a Spring user). If you don’t use runtime exceptions for failures that can happen in production – then you will NEVER get Runtime exceptions in production (please, don’t count NPE’s and the like here, because they are a result of buggy code and should not happen in production).Regards,--Dmitriy.
    <sarcasm>
    Yes, you're right, I've never seen a NullPointerException, IllegalArgumentException, or any number of other unchecked exceptions blow up a production app or cause it to mess up, because it was only very carefully catching (and often discarding, but that's another story) all checked exceptions but not bothering with uncchecked exceptions (something you say it shouldn't have to bother with).
    </sarcasm>

    Any app needs to properly deal with both checked and unchecked exceptions, at appropriate times.

    This is so old; I'm going home.

    Colin
  69. Colin:
    <sarcasm>
    Yes, you're right, I've never seen a NullPointerException, IllegalArgumentException, or any number of other unchecked exceptions blow up a production app or cause it to mess up, because it was only very carefully catching (and often discarding, but that's another story) all checked exceptions but not bothering with unchecked exceptions (something you say it shouldn't have to bother with).
    </sarcasm>
    Please come out of your shoe box and look around :-)

    You are suggesting that applications deal with NPE's, IllegalArgumentExceptions, and Spring's DataAccessExceptions in the same way?!?

    NPE is a clear bug in code - if you have buggy code, then there is nothing you can do. My issue is when the code is not buggy, then Spring's DataAccessException will still happen in production, and by all means it should not be handled in the same manner as NPE!!!

    There are 20 different ways to handle DataAccessException:
    1) Log and gracefully exit closing all threads and resources.
    2) Alert the admin.
    3) Wait for 2 seconds and try again.
    4) Send a JMS message to another node to perform backup.
    ...
    etc, etc, etc
    ...

    DataAccessException should be a checked exception because it should be up to the user to decide whether it is a fatal error or not. If compiler does not remind developers about possible errors, then errors will be leaked, missed and mishandled!

    --Dmitriy.
  70. If compiler does not remind developers about possible errors, then errors will be leaked, missed and mishandled!--Dmitriy.
    Errors might be leaked, missed and mishandled whether or not the compiler reminds about them. It's really not that difficult to catch unchecked exception if you feel like it. It's also not too difficult to keep the documentation of a method up to date, if that's a problem in your team it's probably not the only one.
  71. Juergen:An unchecked exception that demands resource cleanup by the caller would be questionable, but this is never the case with Spring.
    Yes, IT IS the case with Spring... My logic may have 10 other resources outside of Spring DAO framework and unchecked exceptions thrown by Spring will not clean them up. Cleaning the resources in a finally clause may not even be an option for a user since it can be in totally different thread of execution. Runtime exceptions thrown by Spring will kill their threads and leave the rest of the application in the limbo state.
    If the app is multi-threaded and if say a parent thread is killed due to an unchecked exception, what happens to the child threads? Are there any best practices / strategies to clean up the child threads in places other than the catch block? In case of unchecked exception handling the recovery inside a catch block where there is enough context information about the child threads may not be an option and what does the spring team got to say about this?

    Venkat
  72. the iBATIS DAO framework - the only other well-known open-source DAO framework besides Spring - uses an *unchecked* DaoException too. So will you also attack Clinton Begin now?
    I will, it is a biggest frustration for me that iBatis does not have checked exceptions.

    checked vs unchecked exceptions resembles DOS vs Unix:
    - With DOS you do not need that ridiculous tree file system, it is just C:
    - DOS has no insane symlinks;
    - DOS has no file acess rights;
    - DOS FAT does not waste bytes to provide abilities to work with disks more than 512MB - you will never ever need it;
    - With DOS you do not have to deal with all that network madness;

    DOS is plain and simple! Hurraaah!
  73. I will, it is a biggest frustration for me that iBatis does not have checked exceptions
    Then catch it then.. there is no one stopping you.
    You can even put it in the throws clause if you wish...
    hey even in the javadoc..

    Its good to question things.. however you have your opinion and you are probably not going to convince Rod, Juergen, Bruce(x2), Gavin, Clinton, etc..
    and alot of other developers out there..

    this.topic == horse.beat()
  74. I will, it is a biggest frustration for me that iBatis does not have checked exceptions
    Then catch it then.. there is no one stopping you.You can even put it in the throws clause if you wish...hey even in the javadoc.. Its good to question things.. however you have your opinion and you are probably not going to convince Rod, Juergen, Bruce(x2), Gavin, Clinton, etc..and alot of other developers out there..this.topic == horse.beat()
    Thank you.
  75. I will, it is a biggest frustration for me that iBatis does not have checked exceptions
    Then catch it then.. there is no one stopping you.
    That is exactly what I do with my cglib proxies.
    Its good to question things.. however you have your opinion and you are probably not going to convince Rod, Juergen, Bruce(x2), Gavin, Clinton, etc..
    Never dreamed of it.
    and alot of other developers out there..
    That is actually my aim. Someone might have a chance to decide if checked exceptions are good.
    I just want educate people and use (and contribute to)frameworks which welcome and use checked exceptions.
  76. With your erroneous unchecked exception strategy YOU DON'T KNOW in what methods and even in what application layer your unchecked DataAccessException pops up. Period!You took on a whole mission to save developer a simple throws clause declaration at the expense of clarity and robustness.Regards,--Dmitriy.I have exactly the same opinion.
    There is no shortcut which leads to quality and who takes shortcuts is often not sleeping at home.
    For me checked exception are just minimal guarantee that code is written in a fully conscious way.
    Note that now exits an option to "soften" checked exception with AOP if you wish or to catch uncheck exception in "random" place. But this is not something which is proven pratice from the point of view of experience.



    Michal
  77. For me checked exception are just minimal guarantee that code is written in a fully conscious way.
    Interesting remark, this. It actually illustrates a problem with checked exceptions.

    Good software design attempts to hide all detail not relevant to the problem at hand from the developer's mind. It increases the complexity of the problems we can handle by reducing the proportion of the complexity that you have to deal with at any one time. Abstraction, encapsulation and so on are all geared towards this goal. Good design is about removing things from the developer's consciousness. No-one in his right mind is trying to write code "in a fully conscious way".

    Checked exceptions, in particular, should propagate to the point (or layer) where developers can generally deal with them, and no further. Beyond this point it's so much irrelevant complexity that a good design will try to hide. The traditional approach is to wrap the exception (e.g. SQLException) inside some generic layer-specific exception (MyLayerDatabaseDisasterException extends MyLayerException). But how useful is this really? It's not as if we can recover from a MyLayerDatabaseDisasterException by this time. Having a ubiquitous and amorphous "throws MyLayerException" in all your method signatures doesn't achieve much either; we can only propagate or wrap it. Worse, its presence may obscure other MyLayerException subclasses that are meaningful and recoverable at this point. Another problem is that properly wrapping exceptions takes discipline that in my experience not all developers have; we end up with the mother of all throws clauses or, in extreme cases, with a "throws Exception" (hands up everyone who has never seen this happen... thought so).

    What, then, is so evil about turning checked exceptions into unchecked ones at the point where it generally no longer makes sense for the developer to remain "fully conscious" of them? I have worked on a couple of projects now where we do exactly this, and have found it to be purely beneficial.

     - Peter
  78. IMHO, a caller doesn&#8217;t have to know what type of technical problem a method may have. It doesn&#8217;t have to know if it's a SQLException, NPE, IOException. In all case of technical exceptions, I (the top-level caller) will do the same: catch it, log it, and display a standard error message (&#8220;Internal error. Please contact your administrator.&#8221;). So, because NPE or ClassCastException are already unchecked, lets put all technical problems bellow RuntimeException.

    But for user exceptions (invalid password, not enough credit, etc.), I want them to be part of the signature of the method because they are *normal* way to exit of a method. They are part of the Use Case in UML. The caller has to do something with them. So I recommend to let them checked.

      Adrien
  79. IMHO, a caller doesn&#8217;t have to know what type of technical problem a method may have. It doesn&#8217;t have to know if it's a SQLException, NPE, IOException. In all case of technical exceptions, I (the top-level caller) will do the same: catch it, log it, and display a standard error message (&#8220;Internal error. Please contact your administrator.&#8221;). So, because NPE or ClassCastException are already unchecked, lets put all technical problems bellow RuntimeException.But for user exceptions (invalid password, not enough credit, etc.), I want them to be part of the signature of the method because they are *normal* way to exit of a method. They are part of the Use Case in UML. The caller has to do something with them. So I recommend to let them checked. Adrien
    I think exception driven programming sucks, why do you need to care how to fix "invalid password" ? "isValid(password)" must be a better way for flow control too than "catch( InvalidPassvordOrSomeSubclassOfThisException )". I more prefer to declare that method doe's than to declare how it doe's stuff, Is it interesting for application how driver connects to database, are you going to catch SocketError or NamedPipeError in application, do you know how to fix connection problems ? Why do you need to try if you know all causes ? Just do it if you know them all. It doe's not work ? then die if you do not know cause.
  80. I more prefer to declare that method doe's than to declare how it doe's stuff, Is it interesting for application how driver connects to database, are you going to catch SocketError or NamedPipeError in application, do you know how to fix connection problems.
    And therefore we declare that software load-balancing and failover techniques should not be followed. How are you going to implement something that needs to failover if you are dying on the SocketError?
    Why do you need to try if you know all causes ?
    Because in some situation the Exception is all you have to notify you of failure.
    Just do it if you know them all
    Just do what? Not connect? Quit the application before any failure occurs, since you know that it might occur? If you know the failure causes, what specifically are you supposed to do, if not handle the failure Exception?

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  81. And therefore we declare that software load-balancing and failover techniques should not be followed. How are you going to implement something that needs to failover if you are dying on the SocketError?
    Yes, just do it and die on error (AOP tricks can help to implement clear crash). load-balancing is not an application aspect, this kind of home made workarounds just polute application code, infrastucture must handle application crash, this infrastructure can be fail tolerant or not, it can halt or forward (I do not need this deployment specific logic in application ). Halt is a very normal deterministic machine operation too.
  82. BTW, this is more about "That" vs. "How" logic, not about checked vs. unchecked and we can not agree for this reason.
  83. I guess you are right. I use both whenever applicable anyway.

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  84. load-balancing is not an application aspect, this kind of home made workarounds just polute application code, infrastucture must handle application crash, this infrastructure can be fail tolerant or not, it can halt or forward
    Load-balancing is a perfect application aspect, especially if each of your solutions does nto invole buying overly expensive load-balancing hardware .BTW Intel's load-balancer series software is written in Java and embedded in the hardware load-balancer appliance, how do you think they handle Layer 3 errors propogated through the socket APIs? I would not call Intel's products a home-made workaround.
    it can halt or forward
    You are familiar with a concept of SLAs? How would your claim stand under 99.9% uptime SLA?
    I do not need this deployment specific logic in application
    How is authenticating user's against LDAP Directory server is a deployment specific logic? What is so deployment specific about fault-tolerance and load-balancing?
    AOP tricks can help to implement clear crash
    Not specific enough to be considered anything but the pollution of you argument. I would rather write code against accepted design patterns and standards, than use "tricks".
    Halt is a very normal deterministic machine operation too
    Does the VM handle it and throw exeption? Comparing Halt operation and load-balancing/faul tolerance techniques does not stand as a valid argument for me.

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  85. Doe's your "load balancer" handlers unchecked exeptions in different way as unchecked ? Doe's you application knows about deployment and you try to reconnect to alternative databases in exception handlers ? Doe's your application restarts container if JVM return error code, starts recovery on database ?
    Do you have use case for checked exeptions or you just talk nonsences to blame Spring, C#, AOP and all things you do not understand ?
  86. Doe's your "load balancer" handlers unchecked exeptions in different way as unchecked ?
    Well, it handles unchecked as unchecked. What are you trying to ask here? Does it handle the checked exception differntly than unchecked. Well, yeah, since unchecked are handled generically and passed through and checked are handled specifically and are retained, at least in my case. I hope that answers your question.
     Doe's your application restarts container if JVM return error code, starts recovery on database ?
    Yes,my application restarts container or failovers to another container in a cluster if the JVM on a particular node returns an error code. It also generates a report of various erros to help the recovery of data in the database.
    Do you have use case for checked exeptions or you just talk nonsences to blame Spring, C#, AOP and all things you do not understand ?
    I dare you to quote me talking nonsense about any of the above mentioned technologies and frameworks. I am using all of the above with exception of Spring (which I haven't said a single bad word about) and I am fine with any of those things. I work in C# and I use AOP from the attribute binding perspective to bind classes and their memebrs to relational data DAO factories. My personal project has a heavy use of ApectJ for logging and security.

    And yes, I have provided an overview of a use case with authentication against multiple LDAP directories with requirement to failover until a good commmunication link is found.
    and all things you do not understand
    What do you personally know about me to make any types of accusations? Who are you to pass any personal insults and judgement about me or other people to that respect around?

    And it looks like a common trend on TSS theese days.

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  87. Sorry if you take it personal, but I think it is a nonsence, Spring and runtime exeptions can not break any load balancer and do'e not polute JVM return codes.
  88. Spring and runtime exeptions can not break any load balancer and do'e not polute JVM return codes
    I take it personally because I did not say that Spring has anything to do with that and expecially why would I even think that Spring has any relationship to a load-balancer? I was talking about load-balancing and fault-tolerance TECHNIQUES, not appliances and definitely not in relationship with Spring framework. I think you misunderstood me, as I have nothing against Spring and do support the idea and I think it is one of the best projects we have in the open-source community.

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  89. I do not want to be rude, just load balancing and fail tolerance looks very srange for me in this context. "checked vs. unchecked" becomes a war in all discussions for some reason, probably it is better not to start it, nobody can find good arguments.
  90. I love the theory of checked exceptions. They force you to declare and handle errors. In practice, I find them wanting. Ted Neward converted me by asking me to pay close attention to the exception management in the code that my customers write. (I do design reviews for a living, now with Interface 21.) I found that most code was not in a position to deal with a given exception. So, they either:

    1) Used the "nesting doll" exception model, wrapping one exception in another, and throwing it up the chain. It's ironic, because the behavior that we're trying to simulate here is the unchecked exception.

    2) Used the "log it and forget it" model.

    That's what exceptions in Java have become. It's not about the code that I know that you or Rod could write. It's about the exception strategy of the masses. Frankly, there isn't one.

    Most dangerously, exceptions increase the "noise" level in Java code to dangerous levels. Now, when you see a "catch" block, I'd guess that 80-90% of them do not handle the exception. We can only hope that they throw it up the chain. And we see way too many "throws" clauses. The real danger of noise is when you read code. The kneejerk reaction, today, is to ignore the exception syntax. Clutter always reduces your ability to maintain code, and that's the very benefit that most claim that checked exceptions will buy you.

    So well before I found Spring, I became a convert to unchecked exceptions. I can deal with a problem at the right level rather than the lowest level, I reduce my clutter and increase readability,, and I make the try/catch/throw clauses much more important (and likely to be read and understood) by removing them from situations where they do not and should not apply.
  91. I love the theory of checked exceptions. They force you to declare and handle errors. In practice, I find them wanting. Ted Neward converted me by asking me to pay close attention to the exception management in the code that my customers write. (I do design reviews for a living, now with Interface 21.) I found that most code was not in a position to deal with a given exception. So, they either:1) Used the "nesting doll" exception model, wrapping one exception in another, and throwing it up the chain. It's ironic, because the behavior that we're trying to simulate here is the unchecked exception.2) Used the "log it and forget it" model. That's what exceptions in Java have become.
    So you are saying that bad pratice should be mandated becouse it is popular?
    And it should be even simlper to write bad code?
    It's not about the code that I know that you or Rod could write. It's about the exception strategy of the masses. Frankly, there isn't one.Most dangerously, exceptions increase the "noise" level in Java code to dangerous levels. Now, when you see a "catch" block, I'd guess that 80-90% of them do not handle the exception. We can only hope that they throw it up the chain. And we see way too many "throws" clauses.
    Honstely I don't think it is a noise.

    It is a verbose, precise notation of strongly type language.
    Scripting languages have much less how you call "it noise" as even you don't
    have to deal with types, exceptions etc. I think it was proven many times
    that such approach does not scale well.
    The real danger of noise is when you read code. The kneejerk reaction, today, is to ignore the exception syntax. Clutter always reduces your ability to maintain code, and that's the very benefit that most claim that checked exceptions will buy you.
    I have exactly opposite feeling - as it is easier to maintain and refractor code written in strongly typed languages like Java then do the same thing with say Perl.
    And as explicit defined types and super useful so is explicit and forced exception handling. Even the information: I am hiding exception, wrapping it or propagating it up is helpful while you are reading the code.

    If my code was written against certain interface and that interface changed

    from

    interface I
    {
    void someMethod() throws FooException
    }
    to

    interface I
    {
    void someMethod() throws FooException, BaaException
    }

    or

    interface I
    {
    void someMethod()
    }

    I will be forced to consciously react to this change and make decision how I want to handle it. This is something very important. Far more important then shorter code which is easier to write.


    Michal
  92. It is my experience that the unchecked exceptions followers prefer such not for the reason of writing robust code, as you can do the same with checked exceptions, but because such people are lazy to spend enough time in the design sessions to figure out what exactly each application module is going to do and what is the behaviour of the dependency APIs. It is much easier to let the lower-level API exception go through, since you do not have to care what is being thrown, rather than figure out exactly what Exception you need to handle and actually HANDLE them. In the end, even if the applications is more flexible and robust, without any checked exceptions it is extremely complicated to debug and maintain any code.

    I am working with both C# and Java at the moment, and at many time C# applications are extremely tough to debug, as an exception thrown, does not always refer to the actual problem.
    Unfortunately for you, those that adhere to the guidelines in that book - and that book is hardly alone in advancing such guidelines - are happily using *both* unchecked exceptions and checked exceptions in logical places in their applications, and know nothing of the chaos that you seem intent on implying as the inevitable fate of Spring users.
    I do not want to blame any product, but I am convinced that a healthy balance should always be present in any product or a framework between checked and unchecked exceptions. I think it is a good design practice and skill to know when one is more applicable or even required than the other.

    Anyway, just my two cents...

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  93. Read Spring ...[ Go to top ]

    The X18p-config.xml is just applicationContext-*.xml in Spring's samples.

    For web apps, it could be loaded with other *-servlet.xml and *-dao-jdbc, *-dao-ibatis, *-dao-hibernate.xml files, rather than hardcoded. The rest settings should be set using IoC, rather than hardcoded in the java code.

    The dao layer can be done using spring + ibatis, spring can handle transactions very nicely. The coding is just one line per sql statement.

    The web tier in Spring is IoC'd from applicationContext, even better than hardcoded dependencies.

    With Spring, it's easy to start with business objects, then consider web interface, webservice interface, or API interface. In the business tier, you build dao interface, nao(network access objects) interface, or whatsoever, and then implement them off the business tier.
  94. reasonable unchecked exceptions[ Go to top ]

    If the db connection pool is down, or SQL grammer error, can you do anything about it even if you catch the exception? You can't fix them, the best thing you could is to send some message to the screen. Do I need to care "which exception is handled at which tier or even in which method"? No, I don't because they are fatal and there is nothing more we can do about it. I only translate a few of top ones at the presentation layer for security reasons(not to reveal the internal structure).

    JDK is doing the same thing for the same reason, e.g., ConnectionException, TimeoutException, etc, for the network. Do you want to know where you can get these exceptions? Probably not, because the error is from the network settings, not the code.
  95. Checked vs. Unchecked[ Go to top ]

    My personal experience shows that lots of developers, working with checked exceptions either:
    1) rethrow it
    3) handle it inappropriately like printing stacktrace

    Checked exceptions, in my opinion, should be used with caution and not on every project. I would give one simle example:

    public Product getProduct(int id) throws ProductNotFoundException

    In this case it's perfect to declare ProductNotFoundException as checked, because it indicates business lagic flaw, that MUST be correspondingly handled by the developer. For all other cases, runtime exceptions are much, much better.
    Even in this scenario, this ProductNotFoundException can be declared as unchecked. Indication in the method signature would be sufficient, that it must be handled. If it's not, it'd popup in the QA anyway.

    By the way, check out this article ;) :
    http://www.artima.com/intv/handcuffs.html
  96. Checked vs. Unchecked[ Go to top ]

    Agreed, but nonetheless neither checked or unchecked exceptions are "evil". Both have their use and should be used accordingly. Misuse is usually a result of lack of experience or just an honest mistake in desing or implementation.
    public Product getProduct(int id) throws ProductNotFoundException

    In this case it's perfect to declare ProductNotFoundException as checked, because it indicates business lagic flaw, that MUST be correspondingly handled by the developer. For all other cases, runtime exceptions are much, much better.
    That's what I was trying to convey, but reading my own post could not even convey it to myself. :-) For any business apsects of any framework or a library checked exception are a close to a must, other than that it is up to the developer and a set of accepted standards within that individual's team to figure out what applies better and where.

    That's why I did not want to blame any products/frameworks discussed(in case of this post Spring or iBATIS) as such do not cover any business apsects and are strictly aimed at the developer communty that write a more "down to earth" products based on those "helper" frameworks, so unchecked exceptions in any low-level framework is not a big deal, since one can introduce a whole bunch of checked ones in the actual product implementation based on such framework(s).

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  97. decreased coupling with JDO[ Go to top ]

    JDO provides a good example of loosening the coupling between application logic and database. This means that developers no longer have to worry about messy DAO code but rather just map java objects directly to database fields.

    JDO also works nicely with Spring.

    Zeeshan Samdani
    www.powermapjdo.com
  98. move over struts,spring,jsf , ... shine framework is become. Empire of Shine frame work Hello! I'm a java developer. A few days ago, I encounter a new Java frame work named Shine. I read it's getting started document and that motivated me to test it. I really enjoyed it, when I worked with it more! The Shine's Developer had written some documents about it, in Sourceforge.net & J2sos.org. The documents said that Shine: 1. Is a full java service oriented frame work. 2. Is a JWMS (Java Web Model Service architecture) frame work for web base projects. 3. Includes Ajax, MVC, Service Oriented Scope. So I tried to implement a simple sample in order to know it better. I found out that shine has a different view point about Service & to be Service oriented, that was very interesting for me! Shine has deployed on JWMS architecture that is exclusive to itself. Furthermore it supports MVC architecture too. As another advantage, Shine doesn't have the complexity of the other frameworks (for example FormBean component in Struts, …) and let developers to work with a very strong but simple operational process. The other advantage is full Ajax supporting of Shine. The simplicity but the power of Shine's validation is one of its advantages too. After working with Shine a little more, I realize something interesting in it. In addition to the Shines Special capability which I said, it has complex capabilities of Tapestry, Struts, Servlet, Jsp & … . I had developed some big java application projects. And as a professional developer I think Shine has some disadvantages, too. Shine is at its first version & doesn't have enough documents, Also it isn't experienced by developers. So it isn't reliable enough to develop the projects with it. And this is the reasons that don’t let me to deploy a real project with it. Time will show us, whether shine is so strong to show itself as a powerful framework among the others or not?! I don’t know, maybe Shine has some other advantages or disadvantages too. I really hope to learn about it more & will be glad if you let me know about your experiences touching Shine framework. you can finde more information about shine framework in: www.j2sos.org in technical forum. and for downloading shine framework you must viasit this link in sourceforge.net: http://sourceforge.net/projects/shine-app/ have a nice time with shine. bye
  99. you can find shine framework`s sample in this links: http://groups.google.com/group/j2sos/web