Zero Turnaround Time: the crucial flaw?

Discussions

News: Zero Turnaround Time: the crucial flaw?

  1. Zero Turnaround Time: the crucial flaw? (144 messages)

    David Geary, member of the JSF 1.0 expert group, has written up a blog entry called "Ruby on Rails Koolaid, Redux" in which he revisits an earlier statement about Ruby on Rails. It's an interesting view of Java enterprise development in a nutshell, with a crucial statement: "JSF was created for tool vendors; Rails was created for developers." For better or for worse, this statement highlights a flaw many developers have noted in Java Enterprise deployment: a focus and reliance on tool vendors.

    The emphasis here is that Rails allows instant turnaround, with no real deployment cycle, one of the hallmarks of most Java enterprise development. Many developers focus time and effort on minimizing the effect of the deployment cycle, and defectors from Java to PHP and Ruby (among others) focus on the lack of a deployment cycle as a major benefit of such transitions.

    The deployment cycle affects almost all aspects of Java, from persistence and business components (under EJBs) to Web Services (with JAX-RPC having a compilation/deployment step) to web applications. While there are real benefits to the Java EE deployment cycle (i.e., late and passive binding for resources, among others), many programmers prefer injection (via Spring or other such containers) or more simple deployment models altogether (such as Ruby, et al.)

    As Mr. Geary says,
    Why is development with Rails so much faster than with JSF, Tapestry, Struts, or whatever? The single biggest reason is zero turnaround time. You make changes to your application, refresh the browser, and voila, instantaneous feedback. For some, this might not be as appealing as it is for me. Coming from a SmallTalk background, I like to make a tiny little changes quickly in succession. Some folks, like my friend Rob, who I worked with on my Cleveland job, like to write a ton of code before redeploying the app in the servlet container. In fact, I took quite a ribbing from Rob because I wasn't man enough to write large chunks of code at a time.
    The "zero turnaround time" lends itself well to rapid development, because of the benefit of instant feedback over whether your changes were correct or not. The competition between Ruby on Rails and Java frameworks (ignoring the Trails project) seems to be a reaction from both sides, with the Rails proponents saying "development shouldn't be hard" and the Java camp responding with "development should be correct" instead. Yet most people who try Ruby on Rails seriously end up seeming to be genuinely impressed with its capabilities.

    With the statement that "JSF was created for tool vendors," Mr. Geary is expressing the sentiment that JSF was not geared for developers - which calls its entire reason for being into question, because end users don't often care what technology was used to create an application, but instead only care that the application works and was delivered in a timely fashion.

    What do you think of the issue? Are tool vendors too dominant when it comes to designing APIs for Java, Enterprise Edition? Why are the two camps - Java and Rails - so opposed to each other? Is the deployment and development cycle's dependence on tools a problem across the entire standardized Java development platform - and should it be repaired? If so, how? Why is the typical Java Enterprise mindset so architecturally "heavy"?

    Threaded Messages (144)

  2. With the statement that "JSF was created for tool vendors," Mr. Geary is expressing the sentiment that JSF was not geared for developers - which calls its entire reason for being into question

    That is not a correct logical statement. Just because JSF may be been designed to be useful for tool vendors does not mean it is not also geared for developers (whatever that is supposed to mean). The one statement does not imply the other. Also, why should an emphasis on tool vendors 'call its entire being into question'? Don't developers use tools?

    I develop with JSF, and I have no problem using it without any tools, so the "reliance on tool vendors." Is not an issue at all in my experience, at least for JSF.

    Even if there was a reliance on tools, why is that a flaw? Do we want to move back to hand-edited scripts for everything?
  3. Hardly David, hardly. Why the heck does someone need a tool to drop a component in the form of a JSP tag into a page? Where the hell is all of this FUD coming from? Stop it, please.
  4. Even if there was a reliance on tools, why is that a flaw? Do we want to move back to hand-edited scripts for everything?

    I don't think anyone will disagree with me when I say that developing JSF components is more difficult than something like RoR-- but not impossible, not by a long shot.

    The fact that JSF is tool-able is a major benefit in long term maintenance and for taking advantage of horizontal markets. Even within your own department, being able to package a component that can be drag and dropped into a page by an entry-level programmer or non-programmer is huge.

    When people talk about all the XML required, it's not, only if you want to use your component in a vendor tool. Adding a component to JSF only takes 2 values in a config file: the component-type and the component-class. Done. The rest of the elements are optional for toolability. Is that developer friendly enough?
  5. Even if there was a reliance on tools, why is that a flaw? Do we want to move back to hand-edited scripts for everything?
    I don't think anyone will disagree with me when I say that developing JSF components is more difficult than something like RoR-- but not impossible, not by a long shot.The fact that JSF is tool-able is a major benefit in long term maintenance and for taking advantage of horizontal markets.

    Unfortunately, I was not clear about the context of 'tools' in that comment. I intended a generally comment about tools throughout J2EE, not just specifically for web pages. Personally, I have no objection to hand-coding JSF - indeed, your facelets code will make things especially productive! My point was that switching to something like Ruby, and leaving behind the tools and IDEs used for general Java/J2EE development, seems such a backwards step. Indeed, a good J2EE IDE will allow incremental development and fast turnaround time, similar to Smalltalk or RoR.

    I agree that the development of JSF components could be far easier, but experience from other UI environments (such as Visual Basic) suggests that the number of developers using components far exceeds the number of developers producing them, so I don't see this being much of an issue for JSF adoption, especially when there are many high-quality component libraries already available (such as ADF).
  6. David Geary, member of the JSF 1.0 expert group
    Well, that confirms it. He has no idea what JSF is about and what he says should not be taken seriously.
    experience from other UI environments (such as Visual Basic) suggests that the number of developers using components far exceeds the number of developers producing them

    Hmm. Visual Basic...

    But seriously, just because JSF may make writing components difficult and would require significant knowledge to do so without tools, that does not mean that the concept should be used rarely and only by cherry-picked people. There are other frameworks out there that make writing compoents extremely trivial and do not raise the bar on the developers who code that way.

    After all, writing objects in C may be tricky, but that does not mean that OO is a rarely-used super-advanced technology. The language just does not make the task easy.
  7. David Geary, member of the JSF 1.0 expert group
    Well, that confirms it. He has no idea what JSF is about and what he says should not be taken seriously.

    Who is saying that? The fact that we are commenting here shows that he is. Also, it is my impression that being on an EG does not mean that you share the opinions of others in that EG.
    experience from other UI environments (such as Visual Basic) suggests that the number of developers using components far exceeds the number of developers producing them
    Hmm. Visual Basic...

    Well, indeed. Not the ideal example of a development language, perhaps! But it illustrates the point.
    But seriously, just because JSF may make writing components difficult and would require significant knowledge to do so without tools, that does not mean that the concept should be used rarely and only by cherry-picked people. There are other frameworks out there that make writing compoents extremely trivial and do not raise the bar on the developers who code that way.After all, writing objects in C may be tricky, but that does not mean that OO is a rarely-used super-advanced technology. The language just does not make the task easy.

    I'm sure that things will get better with JSF, and I agree that the difficulty in creating components is not an advantage, however I still can't see how that is going to hold back adoption significantly - it certainly didn't for VB components.
  8. I do not understand how it illustrates JSF points if it is not difficult to develop VB components http://pages.cpsc.ucalgary.ca/~saul/vb_examples/tutorial10/activex01.html and you need to write many custom components to develop application with any component framework (if we do not count lame component framework usage)
  9. I do not understand how it illustrates JSF points if it is not difficult to develop VB components

    It isn't difficult now, but it used to be. In early versions of VB there was no way to write components in Visual Basic; it was a job for a C expert. However, this did not seem to slow the uptake of Visual Basic.
  10. I do not understand how it illustrates JSF points if it is not difficult to develop VB components
    It isn't difficult now, but it used to be. In early versions of VB there was no way to write components in Visual Basic; it was a job for a C expert. However, this did not seem to slow the uptake of Visual Basic.

    LOL. Steve, my guess he hasn't tried to do this. They are such a pain. Creating a component in Swing is a Sunday School picnic compare to that. And really, creating ActiveX controls as they show isn't like creating real controls like dropdowns, etc. I've done it. It is better to pay the $50 for a professionally done component.

    Creating controls in VB - another Mad TV "Look what I can do!" moment.
  11. LOL. Steve, my guess he hasn't tried to do this.
    It looks like you know me better than my wife.
  12. LOL. Steve, my guess he hasn't tried to do this.
    It looks like you know me better than my wife.
    Nope, I'm not omniscient, like a wife. Just a lucky (educated) guess.
  13. LOL, you are not lucky at this time.
  14. you need to write many custom components to develop application with any component framework (if we do not count lame component framework usage)

    This is obviously not true, as if it was, Visual Basic 1.0 would never have taken off (unless you wish to label VB 1.0 as 'lame'). There is already a rich set of components available for JSF (look at MyFaces and ADF).

    And anyway, it is not impossible to write new JSF components - a competent Java developer should be able to do it. It simply isn't trivial.
  15. Navigation?[ Go to top ]

    When people talk about all the XML required, it's not,
    >only if you want to use your component in a vendor tool.
    >Adding a component to JSF only takes 2 values in a config
    >file: the component-type and the component-class. Done.


    and what about page navigation in the config file? Why it is good to restart the container for the flow changes in the one application?

    Marina
    http://www.servletsuite.com
  16. Navigation?[ Go to top ]

    and what about page navigation in the config file? Why it is good to restart the container for the flow changes in the one application?
    I prefer to edit 1 XML file to change the flow of an application instead of editing many JSP files. I'd take a restart of container over that any day.
  17. Navigation?[ Go to top ]

    Sure, you can restart, but see our subject: zero turnaround time. What could you suggest for those who dislike that procedure? Or simply works in the hosted environment?

    Marina
    http://www.servletsuite.com
  18. Server Restart Slack Time[ Go to top ]

    ... Hey. If I didn't have to wait for server restart when would I have time to read this thread? ;-)
  19. The fact that JSF is tool-able is a major benefit in long term maintenance and for taking advantage of horizontal markets.

    The toolability of JSF is a competitive advantage over Rails only if Rails isn't also toolable. Is Rails readily toolable?
  20. With the statement that "JSF was created for tool vendors," Mr. Geary is expressing the sentiment that JSF was not geared for developers - which calls its entire reason for being into question
    That is not a correct logical statement. Just because JSF may be been designed to be useful for tool vendors does not mean it is not also geared for developers (whatever that is supposed to mean). The one statement does not imply the other. Also, why should an emphasis on tool vendors 'call its entire being into question'? Don't developers use tools? I develop with JSF, and I have no problem using it without any tools, so the "reliance on tool vendors." Is not an issue at all in my experience, at least for JSF.

    Let me second that statement - I don't have a problem using JSF without tools either. As a matter of fact, I did it for about a year when I was writing my book, because there weren't any tools available. I don't think it's any worse than using Struts without tools (actually, I think it's easier.)

    So much of JSF was designed to facilitate ease-of-development, and it's a big mistake to overlook that fact.

    So, while tools are definitely an important part of the JSF story, being toolable does not imply that a product wasn't developed with developers in mind.

    Kito D. Mann
    Author, JavaServer Faces in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info

    Are you using JSF in a project? Send your story to trenches at jsfcentral dot com, and you could get your story published and win a free copy of JavaServer Faces in Action!
  21. Ok, so maybe a little biased, but why do we have to ignore the Trails project, exactly?
  22. Trails was mentioned in context of the "competetion" between RoR and Java - because Trails is a port of Rails to Java. Therefore it's not part of the competition, by definition.
  23. Trails is not a port of Rails, actually, but I understand what are saying. My point is that rather than trying to say how great Java is or how terrible Rails is, let's learn from Rails and make Java development a better experience.
  24. Trails is a port of Rails to Java

    But with important differences, in my opinion. For example, whereas Rails defines the domain model as a schema, Trails defines it as classes. This alone makes Trails vastly better, I believe. There are other differences; so many that Chris Nelson states (http://today.java.net/pub/a/today/2005/06/23/trails.html) "Trails is in no way a port of Rails".
  25. Trails is a port of Rails to Java
    But with important differences, in my opinion. For example, whereas Rails defines the domain model as a schema, Trails defines it as classes. This alone makes Trails vastly better, I believe. There are other differences; so many that Chris Nelson states (http://today.java.net/pub/a/today/2005/06/23/trails.html) "Trails is in no way a port of Rails".

    True. I find that Trails does a decent job in providing some sort of middle point between Java "seen-as-heavy" developing and Rails, and of course it uses some excellent tools. But it's not quite there yet. I love the ant tasks that I can just run over and over from my IDE if I need to recompile and redeploy changes, the only real complain I have is getting 18MB of web app just for a mere 6 table application.

    Just for your information, at the other side of the fence (.net) there's a framework called MonoRails from Castle that is more similar to Rails and it uses the programs that have been straight ported from Java land like Hibernate and Velocity. I tested it and it looks nice, maybe this time these .net guys got it right? Maybe they don't get it at all, what do you think?
  26. Sorry for my previous off-topic, but back in the original "rail", I got used to code a little, test a little, make it work, code a little more, etc.

    Just like other people mentioned, I was getting frustrated working with Java in web apps because the amount of time it takes to code some parts, prepare mock objects, unit test, integrate, tweak config files, prepare a test build, deploy, restart server, etc. you know the tune. This was getting bad some time around a year ago at work because of deadlines so management decided to flush Java for small to middle sized web applications and switch to PHP. Although our PHP apps are object oriented with separation of layers, MVC, good tools and the rest, it's never going to be like Java simply for a matter of performance, but the point is that developing is smooth and fast, even without a full featured IDE.

    Just some time ago I was able to create a rapid prototyping environment in Java, using Resin and Eclipse loaded with many plugins that allow me to see the changes with a browser refresh, but it's still more cumbersome than in some other languages like Ruby and PHP. As for JSF, I think it's a great framework but I also think (like others in here) that is geared towards tool-vendors. It's true that you can create JSF pages without tools in an easy way (if you know the framework very well) but it takes more time, and with managements like the one I have, they will think "if we have to do it with JSF, well let's buy the tool and be happy (and faster)".
  27. It's true that you can create JSF pages without tools in an easy way (if you know the framework very well) but it takes more time, and with managements like the one I have, they will think "if we have to do it with JSF, well let's buy the tool and be happy (and faster)".

    It is occasionally stated that development with JSF is difficult and time-consuming compared to other frameworks. I'm afraid I simply can't see how that is. Let's look at the JSF to produce a simple form:

    <f:view>
    <h:form>
    input: <h:inputText value="#{myBean.text}"/>
    <h:commandButton value="Send" action="#{myBean.process}"/>
    </h:form>
    </f:view>

    All that is then needed is a few tags in an XML file to specify the class and scope of "myBean", and that is all.

    I just can't see how this is supposed to be difficult, or how it requires detailed knowledge of the framework, or how it isn't 'geared towards developers', or how it requires tools. It seems to me to be simpler than other frameworks (such as Struts) that are rarely considered to require tools, and there is actually less code on the web page than in Ruby on Rails (once you have started to move beyond the initial 'scaffolding', this is significant).

    I am seriously interested in what developers consider what the issues are - I am willing to be educated about the supposed faults!
  28. Do I need to restart server after I change font style in "<strong>input:<strong>" ?
  29. Do I need to restart server after I change font style in "<strong>input:<strong>" ?

    No.
  30. OK, it is very cool. As I remember JSP it was not so cool.
  31. OK, it is very cool. As I remember JSP it was not so cool.

    This is the same for JSPs - you don't need to restart a server if you change them. They are individually re-compiled when required.
  32. OK, it is very cool. As I remember JSP it was not so cool.
    This is the same for JSPs - you don't need to restart a server if you change them. They are individually re-compiled when required.
    So JSF parses markup, generates servlets, compiles code and it must be restarted to avoid errors. Why do I need this stuff to change font in HTML ?
    BTW are you so lucky and do not restart container after you change JSP or some class ?
  33. Do I need to restart server after I change font style in "<strong>input:<strong>" ?
    No but you should use CSS for cosmetics.
  34. The "zero turnaround time" lends itself well to rapid development, because of the benefit of instant feedback over whether your changes were correct or not.

    I think the whole discussion is going the wrong way. The main concern is the time between writing code, and able to see the code working, and not about the tool support.

    I personally do like the approach, code a little and test a little. This will make sure what I am doing is progressing and I don't end up having to debug complex problems later on.

    With JSF, if you have to restart the servers, or reload applications, or change packaging, testing the code just becomes too complex. For the tiny project we did on JSF, I found my self waiting lot of time for the entire framework to start and stop for every change I am making, including changing a small code to increment the hit count.
  35. For the tiny project we did on JSF, I found my self waiting lot of time for the entire framework to start and stop for every change I am making, including changing a small code to increment the hit count.

    That's something easily resolvable under the current specification. The difficulty is that Java is compiled for performance, so even if we do add config monitoring to the RI or MyFaces, your new classes still have to be seen by the classloader.

    When it comes to developing pages in JSF, JSP will automatically re-compile the pages for you and using something like ADF (and soon the RI), state will correctly refresh when the view changes.

    One take away is that JSF is huge. Huge enough that the hurdles and comparisons are winnable in the long run with JSF. We will get there in the EG, very soon. Other frameworks for JSF are popping up too, such as Facelets, that has templating capabilities and Tapestry-like features.
  36. what?[ Go to top ]

    Maybe I'm stupid, but what's this whole non sense about JSF being the critical flaw of Java and J2EE? I can use JSTL, JSP or anything else I want. Am I to believe that JSF == J2EE. I find the arguement stupid.

    if I want instant gratification, I'll use JSP. the one thing I like about the java community is the diversity. some projects JSTL is appropriate, while others use Struts. If someone feels JSF is the right choice, then good for them.

    peter
  37. Erm[ Go to top ]

    a) I actually prefer to use tools for my development. In fact I have for some time now.... Until people try JSF they probably won't believe the comments above (ie: tools? who cares) Do the Ruby guys consider TextMate a tool?

    b) Java is good enough for enterprise Java development. How do I tell a manager that they should dump a "good enough" tech stack (and all that goes with it) for something a guy in Japan wrote -- because "we can probably develop 5-10x faster with it?" Or, why use both? Some developers can't even convince a manager that they want to use AOP for unit testing...

    c) What exactly is the size of the Ruby on Rails developer base and where is it? If I need four RoR developers for a new project will I be paying through the nose for them?

    If enterprise development was just all about project turn-around time, then wouldn't the world be a great place?
  38. Using WSAD 6.0 at work, or MyEclipseIde at home, I edit a JSP page, Java class, etc, save, and hit refresh, bingo, Zero turn around time.
  39. Using WSAD 6.0 at work, or MyEclipseIde at home, I edit a JSP page, Java class, etc, save, and hit refresh, bingo, Zero turn around time.
    And what if you change a method signature? Or introduce a new class? Or change a hibernate mapping?
  40. Yeah but 95% of the time when I have to tweak a UI it's not necessary for me to add a new class or change a hibernate mapping. Your example is the rare case. The truth is that it appears that most people who are trying RoR don't have a clue how to deploy a web app properly in a development environment such that they don't have to restart the container every time. Their ignorance does not make RoR superior nor does that 5% case where I actually do want a change a hibernate mapping to make my UI right.

    Also, I'd like to know what Ruby fans use for an IDE. See, mine has all this cool refactoring stuff that makes me more productive. It's called IDEA. A while ago some ruby developers were posting on the IDEA forums begging JetBrains to add support for Ruby. Evidently tool support is important to Ruby developers too...
  41. Yeah but 95% of the time when I have to tweak a UI it's not necessary for me to add a new class or change a hibernate mapping. Your example is the rare case.

    ..rare for what you are doing. Not rare in the case of an existing application that the UI is defined and only the business logic needs to change. But you are correct, most template changes and even simple class changes are instantaneous.
    The truth is that it appears that most people who are trying RoR don't have a clue how to deploy a web app properly in a development environment such that they don't have to restart the container every time. Their ignorance does not make RoR superior nor does that 5% case where I actually do want a change a hibernate mapping to make my UI right.

    Somehow, I have the feeling that Mr. Geary, who was on the JSF EG for a time, does in fact know how to deploy a web app properly in a dev environment.
    Also, I'd like to know what Ruby fans use for an IDE. See, mine has all this cool refactoring stuff that makes me more productive. It's called IDEA. A while ago some ruby developers were posting on the IDEA forums begging JetBrains to add support for Ruby. Evidently tool support is important to Ruby developers too...

    I love IntelliJ -- so you won't see me argue that point. There are some Ruby IDE's out there that are 'ok' (rubyeclipse, arachnoruby), but nothing with IDEA's quality. IDE's are always important, but the degree of their importance varies from app to app and framework to framework.
  42. Somehow, I have the feeling that Mr. Geary, who was on the JSF EG for a time, does in fact know how to deploy a web app properly in a dev environment.

    I'd like to believe that but from what I've read so far that assumption is wrong. If he did know, then he would at least have put in the caveat that you do not always have to restart the container for Java apps. If he did know and still failed to put the caveat in then it appears he has a hidden agenda of some sort and is at the very least, biased. Either way, it makes his entire blog post suspect in spite of his participation on the JSF EG.
  43. ROR and CF devleopers[ Go to top ]

    From reading some comments here, it seems to me - some ROR developers want an environment similar Cold Fusion, or PHP (instant gratification) and pratice code-pecking instead of properly scaffolding their applications up front.
  44. ROR and CF devleopers[ Go to top ]

    From reading some comments here, it seems to me - some ROR developers want an environment similar Cold Fusion, or PHP (instant gratification) and pratice code-pecking instead of properly scaffolding their applications up front.
    I do not think ColdFusion was similar to PHP, but as I understand developers want an environment similar FreeMarker http://freemarker.sourceforge.net, I see it is mature and solves problems related with JSP, but it is not hyped on TSS for some reason.
  45. ROR and CF devleopers[ Go to top ]

    From reading some comments here, it seems to me - some ROR developers want an environment similar Cold Fusion, or PHP (instant gratification) and pratice code-pecking instead of properly scaffolding their applications up front.

    I do not think ColdFusion was similar to PHP, but as I understand developers want an environment similar FreeMarker http://freemarker.sourceforge.net, I see it is mature and solves problems related with JSP, but it is not hyped on TSS for some reason.

    ColdFusion predates PHP, JHTML, JSP and ASP. Now coldfusion uses JSP tags.

    peter
  46. ROR and CF devleopers[ Go to top ]

    Yes, FreeMarker can use JSP tags too and it doe's not need to generate and to compile servlet to use JSP component, but the "right" framework must be "standard" to be popular for some reason.
  47. ROR and CF devleopers[ Go to top ]

    ...and now with JSTL you can code in your SQL connections and statements and loops over ResultSets and HTML code right in your JSP and there you have it - quick turnaround and unmaintainable applications - but GREAT for prototyping or hacking or job security.

    I remember 7 years ago doing the EXACT same thing in Cold Fusion, now Cold Fusion uses JSP and JSP can do Cold Fusion, and someone is telling me I have to use ROR?

    It's all too confusing, I'm looking for a nice cave for a well deserved retreat.
  48. Long deployment cycles are true of Tapestry, JSF, Struts or any other web framework. In fact Trails has the same problem so there's no reason to special case it.

    We can use JUnit to test database and business logic code but writing a complex UI, as I did two months ago (in Tapestry), is an absolute exercise in frustration. You spend 75% of your time waiting for the build and app server to reload the EAR. I wound up spending a day figuring out how to make Tapestry run with mock HttpServletRequests in JUnit; over the next few weeks this probably saved me several days in app server cycling since it cut the cycle time from 5 minutes to 30 seconds.

    I did evaluate Ruby several weeks ago and was quite impressed with what they have but its strength is also a big weakness. The language is so dynamic that it is very difficult to program without a good IDE. Rails adds methods to your object dynamically and so it is very difficult initially to understand what methods are available and how they are used.

    Garbage collection was a big reason why developers liked Java over C so much. I can't help but think that the next big language will win over Java because it will have ZTT.
  49. ZTT?[ Go to top ]

    Hi

    Could you explain a bit more what you mean by ZTT ?

    Thanks !

    ZedroS
  50. A case for scripting[ Go to top ]

    JSF was created for tool vendors; Rails was created for developers.

    Essentially this shows what happens when you have a scripting environment - like JSP - and want to marry it with a non-scriptable environment like J2EE. At some point your "zero turnaround time" breaks, the question is where and when.

    Building JSF in a way that makes it reread its config files every time would have been a breeze and servlet containers are usually able to reread classes when they are updated nowadays.

    On top of that JSF could have been easily build to enable you to declare simple controllers right in your JSP eh voila, there is your zero turnaround time. No classes at all to go into your jar but a couple of data containers and third party libraries for database access etc.

    However this was not what was done with JSF, which I find sometimes a bit sad. (let alone JSF 1.0 being just, well, very weak in its own right).

    What I find funny is that it still stirs people up. I remarked upon this ca. 3 years ago....
  51. Yes, if JSF doe's not work with JVM scripting languages ("Zero Turnaround Time") then it is a flaw.
  52. The one of the themess of the article came down to this point that it was no big deal to tweek a page and then refresh the screen to see the change - great.
    Any decent Java IDE should give you this in any case for the development part of the cycle. But, I'd argue that packaging and deployment are not a big deal when it comes to the larger issue of installing and patching live systems - That kind of thing generally involves planning, fallback procedures and so on... This is what takes the time and needs to be done properly. The packaging/deployment part is such a small part of the whole and will sensibly be automated in any case to reduce further the screw-up risk.
    I'm not a Rails user so I won't comment on the overall development speed, that is a much more worthy subject to concentrate on that time to glass turnaround on changes.
  53. Some folks, like my friend Rob, who I worked with on my Cleveland job, like to write a ton of code before redeploying the app in the servlet container. In fact, I took quite a ribbing from Rob because I wasn't man enough to write large chunks of code at a time.

    LOL ! I was told the same by somebody to whom I was complaining about the time I have to wait for things. I was a bit ashamed about myself even. Especially lately i feel really frustated with the time lost on doing nothing while waiting for the server to start up again, so frustated that I also begin to dislike the word JAVA. This is a waste because JAVA as a language is great. Why can we not script while developing and compile on deployment, for some reason this seems to be impossible, can somebody tell me why I really don't understand. Btw i don't want to learn ruby, i don't want to use Rhino I just want to use JAVA the whole day instead of 30% of the day. I guess we just have to keep discussing this as must as possible untill somebody fixes this flaw.
  54. http://www.beanshell.org/manual/syntax.html#Standard_Java_Syntax
  55. Some folks, like my friend Rob, who I worked with on my Cleveland job, like to write a ton of code before redeploying the app in the servlet container.
    This was necessary to test just about anything, in the bad old days of J2EE development, but is no longer. With a POJO-based architecture it should be possible to pick up many breakages through unit tests that run instantly. It should also be possible to run many integration tests, testing JDBC queries, O/R mappings and the like, in plain JUnit tests outside an application server. These should also run extremely quickly--we've usually achieved 200+ tests per minute in client projects, with only a few seconds ramp up time. The productivity gain is enormous.

    Regular deployment to the app server environment remains important, of course, but is not necessarily part of development round trips.
    In fact, I took quite a ribbing from Rob because I wasn't man enough to write large chunks of code at a time.
    The more often integration occurs, the less the cost of breakage and the less likelihood of nasty breakage. Good practice is often about being able to work in baby steps.
  56. Great, JSF. Let's just start by fixing JSP. JSP is at the center of web development and even when we all agree that we should not code directly in JSP, it would be nice to have a uniform, well documented basis for web development. JSP does not fit this bill. I mean, JSP doesn't even support proper line number based error reporting! JSTL is half baked. I usually resort to writing little snippets of code in JSP for stuff b/c I can't figure out fast enough how it should work in JSTL. If you go the documentation site for JSTL, you just get some "articles". that describe some aspect of JSTL.

    It's great to develop highly structured applications that promise high maintainability. And no, we should not develop straight in JSP. But would it be too much to ask to make developing in JSP a joy in stead of a pain. For what little stuff I do in JSP, it should be easy as pie. And if someone wants to develop everything in JSP. Why shouldn't that be easy either? Let's take a cue from Cold Fusion on this one.

    From all the cricism I have read of JSF, it seems we're taking the same road: it's good but not great.

    Kind regards,

    Marc
  57. "I mean, JSP doesn't even support proper line number based error reporting!" As I remember it was some specification to solve this problem, is it broken ?
  58. Let's start by fixing JSP[ Go to top ]

    "I mean, JSP doesn't even support proper line number based error reporting!" As I remember it was some specification to solve this problem, is it broken ?

    The problem is that most of the server vendors were in a rush to claim J2EE compatibility, and they took a short-cut and just shipped the Apache JSP compiler (jasper, I think( that was a POS.

    Some vendors (e.g. Caucho) took the time to write their own JSP compilers, and the difference is staggering.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  59. Let's start by fixing JSP[ Go to top ]

    ...From all the cricism I have read of JSF, it seems we're taking the same road: it's good but not great. Kind regards,Marc

    Sure, there's criticism.. as well as hype.. but that's true for any technology especially if its relatively new and has many competitors who have their own interests in mind. Instead of just believing what you read and determining that its "not great", I suggest that you take it for a test drive and decide for yourself if it works for you.

    I'm all for making JSP better/easier as well.. .Tags and Unified EL I think are good enhancements..

    -Chris
  60. Let's start by fixing JSP[ Go to top ]

    JSTL is half baked. I usually resort to writing little snippets of code in JSP for stuff b/c I can't figure out fast enough how it should work in JSTL. If you go the documentation site for JSTL, you just get some "articles". that describe some aspect of JSTL.

    Download the spec. It is extremely easy to read, and in about 20 minutes you will be up and running. Since the first time I picked up JSTL, I have never had the temptation, much less the need, to code in JSP.
  61. prototype to production[ Go to top ]

    The ironic thing is, you tend to get zero turnaround time at the start of a project when prototyping. As you start ramping up to production standard, you find yourself adding all sorts of 'critical' bloat & therefore adding complexity to your product and increasing turnaround time. I find in general, a long turnaround time will distance a developer from a codebase and decrease effectiveness - especially when bug fixing. The trick would be to choose a framework that allows you to keep that prototype feel but give you the confidence to deploy as production code - but which?
  62. IncompatibleClassChangeError[ Go to top ]

    I'm pretty happy with java development. The only big issue I'm having is the fact that when a class is modified in such a way that an IncompatibleClassChangeError is thrown (http://java.sun.com/j2se/1.4.2/docs/api/java/lang/IncompatibleClassChangeError.html), I have to restart a server. Restarting takes time, it's frustrating and it costs money.

    Now that happens too often to be ignored. Even sometimes when I add a private method to a class I have to restart jboss (I am using Eclipse+MyEclipse). Why is that ? Why can't the VM update a class when a private method has been added ? At least that should be possible - I understand that it's difficult (maybe even impossible) if attributes are added/removed from classes.

    I'd even pay for a VM which is better than current VMs in this regard.

    Has anbybody found a solution to this problem ?
  63. I'm not buying it...[ Go to top ]

    I've setup my IDE to do different deployment tasks.

    JSPHOTDEPLOY (1-2s)
    MAKE (1-3s)
    MAKECLEAN (5-10s)
    ETC...

    I can make incremental changes to any of my code, and can be testing changes in the browser in near real time.

    ...so I'm not buying this argument for using <insert latest popular open source 'enterprise-grade' retrofitted scripting language>.

    JCD
  64. RE: I'm not buying it...[ Go to top ]

    I've setup my IDE to do different deployment tasks.JSPHOTDEPLOY (1-2s)MAKE (1-3s)MAKECLEAN (5-10s)ETC...I can make incremental changes to any of my code, and can be testing changes in the browser in near real time....so I'm not buying this argument for using <insert latest popular open source 'enterprise-grade' retrofitted scripting language>.JCD

    Well, I'm glad that you have a simple or straightforward application that this actually works for you.

    Unfortuantely, most of the apps I work on aren't this simple.

    Change a Tile in Struts tiles-defs.xml, cycle the container.
    Change a flow (or anything really) in Struts struts-config.xml, cycle the container.
    Add a new dependency in Spring's context.xml file, cycle the container (yes there are ways to cycle this without cycling the container, but the re-init with Hibernate is nearly as long anyway).
    Change anything in your Hibernate mapping, cycle the container.

    And if you happen to delete a field in a class or change it's type, or change a static, it still requires cycling of the container...

    ...so whether you "buy it" or not is irrelevant because its a fact of (current) container-based Java software development. :)
  65. RE: I'm not buying it...[ Go to top ]

    Add a new dependency in Spring's context.xml file, cycle the container (yes there are ways to cycle this without cycling the container, but the re-init with Hibernate is nearly as long anyway).
    Which container do you mean? The app server/web container or the Spring container? You can just do the latter with the org.springframework.test package out of the box, or by writing your own JUnit test infrastructure. And re-initializing Hibernate should take at most a few seconds and the result will be cached across all tests with the the org.springframework.test approach. (By default it will cache the Spring context statically so JUnit can't blow it away between each test case.) This is very much faster than going through a full deploy cycle, plus you have a lot of advantages such as the ability to dependency inject tests, actually get into your middle tier to test it fully rather than purely going through web pages/remote endpoints, automatic transaction rollback etc. We've found that this is highly productive, and it's possible to spot breakages through transactional, database-aware regression tests within seconds.
  66. RE: I'm not buying it...[ Go to top ]

    Add a new dependency in Spring's context.xml file, cycle the container (yes there are ways to cycle this without cycling the container, but the re-init with Hibernate is nearly as long anyway).
    Which container do you mean? The app server/web container or the Spring container? You can just do the latter with the org.springframework.test package out of the box, or by writing your own JUnit test infrastructure. And re-initializing Hibernate should take at most a few seconds and the result will be cached across all tests with the the org.springframework.test approach. (By default it will cache the Spring context statically so JUnit can't blow it away between each test case.) This is very much faster than going through a full deploy cycle, plus you have a lot of advantages such as the ability to dependency inject tests, actually get into your middle tier to test it fully rather than purely going through web pages/remote endpoints, automatic transaction rollback etc. We've found that this is highly productive, and it's possible to spot breakages through transactional, database-aware regression tests within seconds.

    I was referring to the app/web container. The Spring container is very fast to cycle when Hibernate isn't involved, and I've even written a simple web interface to cycle the Spring context with a button click (for local development purposes only of course). And initialization being "a few seconds" I guess is relative -- 15 to 20 seconds for ~300 highly related model objects on a 1.7 Centrino laptop, to which a full Tomcat cycle only takes another 5 seconds.

    And I agree, unit testing changes is the way to reduce the time spent waiting on the container to cycle -- if only every application I inherit had complete and concise unit tests. ;) Time to start writing then, eh?
  67. RE: I'm not buying it...[ Go to top ]

    Phil
    And initialization being "a few seconds" I guess is relative -- 15 to 20 seconds for ~300 highly related model objects on a 1.7 Centrino laptop, to which a full Tomcat cycle only takes another 5 seconds.
    True, Hibernate initialization will take a while if you have a large number of mapped objects. But there are still major advantages in being able to cut the servlet engine/app server out of the round trip. For example, deployment to a high end app server such as WebSphere, when that's your ultimate target, will be well over 5 seconds... Breakages (for example due to bad mappings) will be detected more quickly than through Tomcat Deployment. Test failures will be reported with a stack trace right in your IDE that you can click on, without any special tooling support required beyond JUnit. And even if you deploy to Tomcat it's very hard to get inside your code to test it properly (you need to go through the web interface or deploy tests in the servlet container), and you aren't going to have any automatic transaction rollback.

    Rgds
    Rod
  68. RE: I'm not buying it...[ Go to top ]

    Phil
    And initialization being "a few seconds" I guess is relative -- 15 to 20 seconds for ~300 highly related model objects on a 1.7 Centrino laptop, to which a full Tomcat cycle only takes another 5 seconds.
    True, Hibernate initialization will take a while if you have a large number of mapped objects. But there are still major advantages in being able to cut the servlet engine/app server out of the round trip. For example, deployment to a high end app server such as WebSphere, when that's your ultimate target, will be well over 5 seconds... Breakages (for example due to bad mappings) will be detected more quickly than through Tomcat Deployment. Test failures will be reported with a stack trace right in your IDE that you can click on, without any special tooling support required beyond JUnit. And even if you deploy to Tomcat it's very hard to get inside your code to test it properly (you need to go through the web interface or deploy tests in the servlet container), and you aren't going to have any automatic transaction rollback.RgdsRod

    I completely agree -- I don't think too fondly of days when I used to wait 1-2 minutes for JRun or Weblogic to cycle. :) (fortunately that was long, long ago)
  69. RE: I'm not buying it...[ Go to top ]

    Well, I'm glad that you have a simple or straightforward application that this actually works for you. Unfortuantely, most of the apps I work on aren't this simple. ...tiles-defs.xml ... struts-config.xml ...new dependency in Spring's context.xml ... re-init with Hibernate.. ...its a fact of (current) container-based Java software development. :)

    So your saying a Tiles-decorated MVC app with an IOC container and a complex O/R mapped application might take a little longer to develop in than Ruby on Rails?

    Why don't we cut to the chase and would someone please point me to a ROR application with the above features?

    Matt
  70. RE: I'm not buying it...[ Go to top ]

    Well, I'm glad that you have a simple or straightforward application that this actually works for you. Unfortuantely, most of the apps I work on aren't this simple. ...tiles-defs.xml ... struts-config.xml ...new dependency in Spring's context.xml ... re-init with Hibernate.. ...its a fact of (current) container-based Java software development. :)
    So your saying a Tiles-decorated MVC app with an IOC container and a complex O/R mapped application might take a little longer to develop in than Ruby on Rails? Why don't we cut to the chase and would someone please point me to a ROR application with the above features?Matt

    Well, all RoR apps have these features by default (with the possible exception of IoC, which I'm pretty sure Needle (a Ruby IoC) can be used). Just not sure the level of sarcasm contained in your post. ;)

    Anyway, I believe Mr. Geary's point was reduced turnaround time, and that Java and the community in general should take a look at RoR to borrow ideas for increasing productivity. Something like Trails is a good first step, but I think the dynamic nature of Ruby will make finding Java equivalents more difficult.
  71. RE: I'm not buying it...[ Go to top ]

    I've setup my IDE to do different deployment tasks.JSPHOTDEPLOY (1-2s)MAKE (1-3s)MAKECLEAN (5-10s)ETC...I can make incremental changes to any of my code, and can be testing changes in the browser in near real time....so I'm not buying this argument for using <insert latest popular open source 'enterprise-grade' retrofitted scripting language>.JCD
    Well, I'm glad that you have a simple or straightforward application that this actually works for you. Unfortuantely, most of the apps I work on aren't this simple. Change a Tile in Struts tiles-defs.xml, cycle the container.Change a flow (or anything really) in Struts struts-config.xml, cycle the container.Add a new dependency in Spring's context.xml file, cycle the container (yes there are ways to cycle this without cycling the container, but the re-init with Hibernate is nearly as long anyway).Change anything in your Hibernate mapping, cycle the container.And if you happen to delete a field in a class or change it's type, or change a static, it still requires cycling of the container... ...so whether you "buy it" or not is irrelevant because its a fact of (current) container-based Java software development. :)

    Maybe you should try something other than Struts?

    Same for the JSF advocates in here... You talk about it not being that bad and compare it to Struts... Ok, but what about compared to the several frameworks which basically sprang up because Struts makes things more difficult than they need be?
  72. RE: I'm not buying it...[ Go to top ]

    I've setup my IDE to do different deployment tasks.JSPHOTDEPLOY (1-2s)MAKE (1-3s)MAKECLEAN (5-10s)ETC...I can make incremental changes to any of my code, and can be testing changes in the browser in near real time....so I'm not buying this argument for using <insert latest popular open source 'enterprise-grade' retrofitted scripting language>.JCD
    Well, I'm glad that you have a simple or straightforward application that this actually works for you. Unfortuantely, most of the apps I work on aren't this simple. Change a Tile in Struts tiles-defs.xml, cycle the container.Change a flow (or anything really) in Struts struts-config.xml, cycle the container.[snip]...so whether you "buy it" or not is irrelevant because its a fact of (current) container-based Java software development. :)
    Maybe you should try something other than Struts?Same for the JSF advocates in here... You talk about it not being that bad and compare it to Struts... Ok, but what about compared to the several frameworks which basically sprang up because Struts makes things more difficult than they need be?

    I've tried almost every major Java web framework out there and investigated thoroughly several others -- Spring WebMVC, WebWork, Tapestry, JSF, Wicket, Cocoon, Maverick, Barracuda, etc. Admittedly, I've not built full blown application with every framework because that's simply not practical. As a result, some frameworks have gotten more attention than others.

    Given that I'm quite familiar with your relationship with WebWork, are you suggesting that a change in 'xwork.xml' or 'validator.xml' will not force (or even require) a server restart? Or was your comment more of a "you should not just look at Struts"? ;) Or perhaps something else entirely?
  73. RE: I'm not buying it...[ Go to top ]

    Given that I'm quite familiar with your relationship with WebWork, are you suggesting that a change in 'xwork.xml' or 'validator.xml' will not force (or even require) a server restart? Or was your comment more of a "you should not just look at Struts"? ;) Or perhaps something else entirely?

    That's right, it won't. You can edit the xwork.xml file and have your IDE copy it into your exploded .war file and it will be picked up automatically (if you have the proper setting in your config, which is usually just used for development, not production).
  74. another cut at jsf[ Go to top ]

    news to some:
    http://bugs.sakaiproject.org/confluence/pages/viewpage.action?pageId=4981

    .V
    http://roomity.com
  75. Which were complained in the article.
    For the scope problem there exists the sort of excellent x:saveState problem.
    The component set is huge and generally it is a good framework to start with.
  76. Tooling: evil?[ Go to top ]

    I believe David Geary has a very valid point when he states that JSF was created for tool vendors.

    If a tool vendor were to provide for JSF what is there at ASP.NET development (click on the "Watch" link) then you can be incredibly productive in a matter of minutes without getting too deep into JSF, JSF components, Tag libraries, syntax, events, validation etc.

    Of course, if you are an experienced Java developer and more importantly, savvy with web development frameworks then it may be a moot point that a tool will help you be that much more productive. But the learning curve has probably been steep.

    However, you have to take into account the fact that members of development teams are not equally experienced and that is where the proper and judicious use of tools can help speed up development.

    If people were to take 15 minutes in watching the above video, and you were asked to code the equivalent without a tool - say using Struts/JSF - armed with only a Struts manual or a JSF component library manual and notepad, an experienced web application developer might do that in less than an hour. Ask a non-experienced developer to code the same web application and it might take him a day (maybe more, maybe less).

    With a proper tool support, the underlying implementation technology becomes a non-issue. And the focus is on getting the job done quickly without necessarily sacrificing quality.

    I do work for Borland - a tool vendor, but the opinion expressed here is my own.

    -krish
  77. don't tell me anybody thinks waiting for a server to be restarted is a good thing. So what's wrong with cutting down those unproductive times ? This has nothing to do with RoR vs. Java, it's just about productivity. So if anybody has found a fast way of using Hibernate + Spring + JSF + (insert any other framework here) without having to restart the app server every 15 minutes, pls let us know ;-)
  78. don't tell me anybody thinks waiting for a server to be restarted is a good thing. So what's wrong with cutting down those unproductive times ? This has nothing to do with RoR vs. Java, it's just about productivity. So if anybody has found a fast way of using Hibernate + Spring + JSF + (insert any other framework here) without having to restart the app server every 15 minutes, pls let us know ;-)

    I'm beginning to see a picture here of why some people think ROR is great. If the point of software development was all about prototyping, I would agree whole heartedly that something simple like ROR would be appropriate for the general solution.

    In the real world that I know, most of software development is about maintenance and debugging. Development methods that rely on instantaneous results have a tendency of producing hard to maintain software. Frameworks like Struts, JSF, etc limit the developer in the hope of producing software that's easier to maintain. I see no difference between ROR and writing a ton of scriplet code in JSP. Both lead down the path of throw away code that rapidly becomes a maintenance bottleneck. I've seen this on several occasions. The end result in all the cases I've seen is the management realize that some formal process and framework is good. It provides a check point and enforces certain way of developing software.

    The real issue in my mind is a struggle between "get it done yesterday" and "build it so the software is maintanable." If a developer is always operating under "get it done yesterday," frameworks like JSF or Struts probably feels much too cumbersome. On the otherhand, if the project involves 4 different divisions in a large company and dozens of developers, there is a need for frameworks like Struts and JSF. Are they perfect? Does perfect even exist?

    peter
  79. I totally agree[ Go to top ]

    Where I work, for each web application we do, we get updates to the web interface right up to the day we go live. And after.

    The guys who do the JSP development are really frustrated by this, because of the amount of time it takes to go through the edit/compile/test cycle.

    It would be nice to be able to do much more prototyping, and be able to go easily from there to something deployable and sustainable as, unfortunately, the compressed timelines and frequent changes have warped the entire codebase, to the point where there must be regular interventions by one or two "heroes" who've been here forever and remember all the decisions that led to the current codebase, and can make the increasingly difficult decisions about where to hack the next fix.

    I've been trying to get the team thinking in terms of layered architectures, if only to cordon off the messes when they can't be prevented. I'm doing all the layers as seperate projects that build on each other (as layers will, ta da!), but I'm getting pushback, notably from one of the "heroes", who has declared that he likes "all the code in one project - it makes it easier to debug things." (Yes, he speaks in hyphens, and all.) (He's the same guy who debugs all his code with System.out.printlns that he deletes before he checks in. Log4j? What's that?)

    So, I guess I'm living the reality of prototyping, taken the the nth degree, and I'm trying to help the company recover to something more sustainable. I've downloaded Ruby on Rails, and I've been playing with it, and it's nice. I'm just glad that most of the people I work with don't pay enough attention to technology to know about it. Else, I'd be looking at another fire. I just know it.
  80. I totally agree[ Go to top ]

    Where I work, for each web application we do, we get updates to the web interface right up to the day we go live. And after.The guys who do the JSP development are really frustrated by this, because of the amount of time it takes to go through the edit/compile/test cycle.It would be nice to be able to do much more prototyping, and be able to go easily from there to something deployable and sustainable as, unfortunately, the compressed timelines and frequent changes have warped the entire codebase, to the point where there must be regular interventions by one or two "heroes" who've been here forever and remember all the decisions that led to the current codebase, and can make the increasingly difficult decisions about where to hack the next fix.I've been trying to get the team thinking in terms of layered architectures, if only to cordon off the messes when they can't be prevented. I'm doing all the layers as seperate projects that build on each other (as layers will, ta da!), but I'm getting pushback, notably from one of the "heroes", who has declared that he likes "all the code in one project - it makes it easier to debug things." (Yes, he speaks in hyphens, and all.) (He's the same guy who debugs all his code with System.out.printlns that he deletes before he checks in. Log4j? What's that?)So, I guess I'm living the reality of prototyping, taken the the nth degree, and I'm trying to help the company recover to something more sustainable. I've downloaded Ruby on Rails, and I've been playing with it, and it's nice. I'm just glad that most of the people I work with don't pay enough attention to technology to know about it. Else, I'd be looking at another fire. I just know it.

    But what does it say that your guys are frustated by the edit/compile/test cycle but others are not? Do you seriously suggest that we who are not frustrated have tons of time coupled with a higher tolerance for frustration?

    It sounds like your process, or at least those used by your JSP guys are flawed. In fact, I'll go out on a limb and question your guys especially the all code in one project. To be frank, you guys may not be all that good at their jobs.

    One of the major complaints I see from junior and "okay" developers is the why we use interfaces.

    Perhas java is okay and your process sucks.
  81. Development methods that rely on instantaneous results have a tendency of producing hard to maintain software. Frameworks like Struts, JSF, etc limit the developer in the hope of producing software that's easier to maintain.

    Why can't we have both? Instantly reloadable servlets, classes, etc. _and_ J2EE. It seems to me you are taking a shortcoming of J2EE development, and trying to paint it as if it was a methodolody choice. Well, it was NOT. They simple dropped the ball on this one.

    And please, no more injection, IoC, unit testing bull**t. Integration tests are more important than unit tests. And I do not want to leave all my lifecycle management to some framework that will take me right into XML hell. We should not invent workarounds when "reloading after compile" is a normally expected feature.

    It can be done.
  82. We should not invent workarounds when "reloading after compile" is a normally expected feature. It can be done.
    Yes, it can be done for JSP if generated servlet doe's not define fields for constants, new JVM implementations must redefine this kind of class without problems (but code generation, compile is not very fast itself and it doe's not make sence to compile markup anyway).
  83. Development methods that rely on instantaneous results have a tendency of producing hard to maintain software. Frameworks like Struts, JSF, etc limit the developer in the hope of producing software that's easier to maintain.

    Why can't we have both? Instantly reloadable servlets, classes, etc. _and_ J2EE. It seems to me you are taking a shortcoming of J2EE development, and trying to paint it as if it was a methodolody choice. Well, it was NOT. They simple dropped the ball on this one. And please, no more injection, IoC, unit testing bull**t. Integration tests are more important than unit tests. And I do not want to leave all my lifecycle management to some framework that will take me right into XML hell. We should not invent workarounds when "reloading after compile" is a normally expected feature. It can be done.

    It's my bias experience. Since I've done quite a bit of contract work, a large part of my work has been cleaning up stuff that was written very quickly and now has to be replaced. I disagree it's a limitation of Java or J2EE. J2EE encompasses a lot of stuff including servlets. It's a limitation of how one builds frameworks on top of servlets. I see no reason why someone can't use Beanshell, jelly or groovy to do the same thing. I'm bias, but to me J2EE is more about management choices and less about technical choices.

    If J2EE is defined as SUN blessed technology, then I'd agree completely. But I don't buy into Sun's definition of what J2EE is suppose to be. I have my own definition of J2EE, which basically says, "do what's best for my customer." Needlessly following all of Sun's recommendations isn't healthy for anyone. The great thing about J2EE is I have a diverse set of tools I can pick and choose. With ROR, what choices to have when it comes to building a real-time trading system?

    peter
  84. And please, no more injection, IoC, unit testing bull**t.
    Thanks for the detailed, well thought out and argued points here. We're all a lot wiser thanks to your input. If you have any points to make based on your experience, I (and no doubt others) would like to hear them.
    Integration tests are more important than unit tests.
    That's a matter of opinion. But it's odd that often advocating unit testing is taken to mean a lack of interest in other forms of testing. In fact, the more forms of testing the better. Unit testing is very important, and is far from a recent fad in agile methodologies or lightweight J2EE. There has been research dating back many years showing that the earlier defects are spotted, the easier they are to fix. Anyway, people have been talking about both unit and integration testing in this thread.

    Like most advocates of TDD, I used to work the traditional way, with ad hoc testing, and limited in-container integration testing. Having experienced both approaches for several years, I wouldn't want to go back.
  85. The real issue in my mind is a struggle between "get it done yesterday" and "build it so the software is maintanable." If a developer is always operating under "get it done yesterday," frameworks like JSF or Struts probably feels much too cumbersome. On the otherhand, if the project involves 4 different divisions in a large company and dozens of developers, there is a need for frameworks like Struts and JSF.

    Interesting. I see the same dichtomy, but come to the opposite conclusion. If my team is proceeding cautiously and carefully, adhering to a good development process, building things with maintenance in mind, etc., then they don't need a framework that "enforces" quality. In fact, the rules imposed by the framework will more than likely make it harder to get things done.

    On the other hand, if they're just hacking crap together, then those frameworks, as cumbersome as they seem, may be providing just enough discipline to avoid a total meltdown.
  86. envy[ Go to top ]

    The real issue in my mind is a struggle between "get it done yesterday" and "build it so the software is maintanable." If a developer is always operating under "get it done yesterday," frameworks like JSF or Struts probably feels much too cumbersome. On the otherhand, if the project involves 4 different divisions in a large company and dozens of developers, there is a need for frameworks like Struts and JSF.

    Interesting. I see the same dichtomy, but come to the opposite conclusion. If my team is proceeding cautiously and carefully, adhering to a good development process, building things with maintenance in mind, etc., then they don't need a framework that "enforces" quality. In fact, the rules imposed by the framework will more than likely make it harder to get things done.On the other hand, if they're just hacking crap together, then those frameworks, as cumbersome as they seem, may be providing just enough discipline to avoid a total meltdown.

    ahh, if only all development proceeded that way. the hardest part is finding a group of developers with the skill and discipline. could be contract work is 90% "clean up junk." :)

    peter
  87. Zero Turn Around Time[ Go to top ]

    RoR has zero turn around time because, when I want to add a property to one of my objects, I have to call a DBA, fill out 5 different forms, and bribe him with a case of beer in order to get the column added to the database.

    Isn't that more like a week turnaround time? Assuming the DBA doesn't decide to redesign the entire database?

    In some places not all delays are technical in nature...
  88. Zero Turn Around Time[ Go to top ]

    RoR has zero turn around time because, when I want to add a property to one of my objects, I have to call a DBA, fill out 5 different forms, and bribe him with a case of beer in order to get the column added to the database.Isn't that more like a week turnaround time? Assuming the DBA doesn't decide to redesign the entire database?In some places not all delays are technical in nature...

    And what would you do if you needed to add a new property to your Java class that had to be persisted into the DB? If it doesn't need persistence, it's no more difficult to add a property in RoR than in Java.
  89. Zero Turn Around Time[ Go to top ]

    And what would you do if you needed to add a new property to your Java class that had to be persisted into the DB? If it doesn't need persistence, it's no more difficult to add a property in RoR than in Java.

    A few minutes to redeploy a Java app versus a few seconds for a RoR app may be a big deal if deployment (or compiling + deployment) is your bottleneck.

    However, the difference between 5 days + 5 minutes and 5 days + 5 seconds is irrelevant.

    There's also stuff you can do to test your Java object w/o having persistence in place. So maybe while you're waiting for your DBA, you can get some piece of complicated business logic that depends on the field working.

    Of course, an organization that won't allow developers to modify database schemas probably won't let developers deploy RoR applications, either.
  90. Zero Turn Around Time[ Go to top ]

    There's also stuff you can do to test your Java object w/o having persistence in place. So maybe while you're waiting for your DBA, you can get some piece of complicated business logic that depends on the field working.Of course, an organization that won't allow developers to modify database schemas probably won't let developers deploy RoR applications, either.

    That's probably the best point made so far. With RoR, there's an assumption that development will be done in a 'vertical' fashion where you will be able to get your ducks in order to proceed to the next step in development. With larger projects, Java and the frameworks/separation available, development becomes just as efficient, if not more.

    Jacob Hookom (JSF EG)
  91. Zero Turn Around Time[ Go to top ]

    And what would you do if you needed to add a new property to your Java class that had to be persisted into the DB? If it doesn't need persistence, it's no more difficult to add a property in RoR than in Java.
    A few minutes to redeploy a Java app versus a few seconds for a RoR app may be a big deal if deployment (or compiling + deployment) is your bottleneck.However, the difference between 5 days + 5 minutes and 5 days + 5 seconds is irrelevant.

    I suppose if you only have to compile+deploy once that would be true ;) What if you have to 10 times per day? If my math is correct, you just added half a day (4 hours) to your 5 days, versus 4 minutes.
    There's also stuff you can do to test your Java object w/o having persistence in place. So maybe while you're waiting for your DBA, you can get some piece of complicated business logic that depends on the field working.

    A good point, but this is available regardless of framework or language -- merely multitasking. :)
    Of course, an organization that won't allow developers to modify database schemas probably won't let developers deploy RoR applications, either.

    An excellent point, and one that Bruce Tate alluded to a few comments back -- a RoR application is more geared towards developer driven applications. Can it be 'retrofitted' onto an existing database schema? I believe it can, but the productivity increase would drop dramatically. Then again, trying to fit Hibernate onto an existing legacy schema can be equally difficult. ;)
  92. The problem with Zero Turnaround Time is inherent in the JVM, and simply can not be easily fixed.

    And that problem is, simply put, that you can not change a class at runtime. Once you load a class, you're stuck with it.

    Now, for something like JSP's, it's not big deal. Even though each JSP compiles in to its own class, those classes are basically only referenced once in the mapping to the servlet container. These classes are easy to replace wholesale. Same thing can be said of servlets.

    Same thing can be said of any of the XML files necessary for a system. The container can be modified to refresh its internal state whenever the backing XML file changes, exactly the same way JSPs work.

    But what you can't fix are internal stored ojbects. If those objects classes change, then anything referencing the original objects is referencing their original classes as well, not the new ones (assuming a smart, change sensitive class loader, which is not the default).

    Whereas in something like Ruby or Smalltalk, this is not an issue. The classes have a protocol to facilitate changing themselves and their instances (note this is an assumption on my part regarding Ruby, I've never used it, but most dynamic languages have this facet).

    Now, if all of your transactions are truly stateless, (or you're always working from a spot that recreates all of the objects for the duration of a transaction that spans a couple of pages) then you don't have this problem if you're working with a sophisticated enough container, one that can detect class changes and reload things on the fly as necessary.

    So, for many web applications, this can be worked around if the container is smart enough to manage it. (I don't know if Tomcat is that smart right now or not, I believe it is, but I don't know).
  93. I do not think somebody needs to change and reload model for prototyping (I asume some kind of model always exists before prototyping). Prototyping is usefull for UI: define new variable in controler, format it in view, add style, preview, change color preview, ... . Prototyping using velocity or freemarker is as trivial as "Zero Turnaround Time", probably controler is an exception, it must be nothing wrong to use some scripting for controler too.
  94. The key to Zero Turnaround Time[ Go to top ]

    Whereas in something like Ruby or Smalltalk, this is not an issue. The classes have a protocol to facilitate changing themselves and their instances (note this is an assumption on my part regarding Ruby, I've never used it, but most dynamic languages have this facet).

    Sun could make changes to make it better for dynamic scripting languages, but I don't agree that it's an inherent problem with Java or the JVM. There are plenty of dynamic scripting languages for Java. For the last 10 months I've been working on a CLIPS interpreter which will eventually be part of Drools. Supporting this kind of dynamic behavior can be done cleanly. Just look at JESS for an example of how java supports dynamic languages. You can declare a deftemplate in JESS and change it without having to restart the JVM.

    peter
  95. Sun could make changes to make it better for dynamic scripting languages, but I don't agree that it's an inherent problem with Java or the JVM. There are plenty of dynamic scripting languages for Java. For the last 10 months I've been working on a CLIPS interpreter which will eventually be part of Drools. Supporting this kind of dynamic behavior can be done cleanly. Just look at JESS for an example of how java supports dynamic languages. You can declare a deftemplate in JESS and change it without having to restart the JVM.

    Umm...these scripting languages aren't necessarily using Java's Object model, they're using their own on top of Java.

    Simple example, if I have Class X and store instances of it in, say, the WebApp session, or even better the Application Context (which is basically global to the entire application), and lets say that Class X has two instance variables, A and B. I then recompile Class X and add a new instance variable C. I can't say what will happen when something grabs an instance of old Class X and tries to call "getC" on it, but I'm betting it won't be pretty.

    Systems like Smalltalk have protocols to promote instances to be compatable with the current class (some do this lazily, others do it actively). I'm not aware of any such protocol in Java.

    Far as I can tell when the new class is loaded, the old one "goes away", with the only references being the old instances.

    So, when my code tries to get the old version out of the ApplicationContext I'll either get a Class Cast Exception when I try and make Old X fit into New X, or if it survives that, I'll probably get a methodNotFound exception when I try to call "getC", because the original class never had it.

    Anyway, neither of these is particularly useful to dynamic redefinition of classes in running images, since most code wouldn't deal with it properly anyway.

    The closest Java comes to this is version aware Serialization and Externalization code, but none of that is relevant to this case.

    But, again, I think this conflict would be rather rare in practice when most folks who want ZTT would use it. Having a smart enough container that would be able to reload JSPs, Servlets and Bean classes (essentially anything within the WAR) on the fly in a framework that would reload any external changed config files would handle 95% of the ZTT issues for webapps, I suspect.
  96. Good points[ Go to top ]

    Sun could make changes to make it better for dynamic scripting languages, but I don't agree that it's an inherent problem with Java or the JVM. There are plenty of dynamic scripting languages for Java. For the last 10 months I've been working on a CLIPS interpreter which will eventually be part of Drools. Supporting this kind of dynamic behavior can be done cleanly. Just look at JESS for an example of how java supports dynamic languages. You can declare a deftemplate in JESS and change it without having to restart the JVM.

    Umm...these scripting languages aren't necessarily using Java's Object model, they're using their own on top of Java.

    absolutely true, but who says every single thing has to use strong typing?
    Simple example, if I have Class X and store instances of it in, say, the WebApp session, or even better the Application Context (which is basically global to the entire application), and lets say that Class X has two instance variables, A and B. I then recompile Class X and add a new instance variable C. I can't say what will happen when something grabs an instance of old Class X and tries to call "getC" on it, but I'm betting it won't be pretty.

    Right, but there are techniques one can use to enable dynamic classes. If I use schema, xmi or relaxng for my models and have the container compile and jar the file at deployment time, I can unload the webapp without restarting the servlet container. I did quite a bit of research into this area for wireless applications. We wanted to provide a way to allow custom objects. Users would extend a base model defining privacy roles and rules.
    Systems like Smalltalk have protocols to promote instances to be compatable with the current class (some do this lazily, others do it actively). I'm not aware of any such protocol in Java.

    Far as I can tell when the new class is loaded, the old one "goes away", with the only references being the old instances.

    So, when my code tries to get the old version out of the ApplicationContext I'll either get a Class Cast Exception when I try and make Old X fit into New X, or if it survives that, I'll probably get a methodNotFound exception when I try to call "getC", because the original class never had it.

    Anyway, neither of these is particularly useful to dynamic redefinition of classes in running images, since most code wouldn't deal with it properly anyway.

    The closest Java comes to this is version aware Serialization and Externalization code, but none of that is relevant to this case. But, again, I think this conflict would be rather rare in practice when most folks who want ZTT would use it. Having a smart enough container that would be able to reload JSPs, Servlets and Bean classes (essentially anything within the WAR) on the fly in a framework that would reload any external changed config files would handle 95% of the ZTT issues for webapps, I suspect.

    I'm bias, but many frameworks today haven't taken a dynamic approach. Should J2EE go that route? I have no idea, but I just don't agree that Java is at fault. Java is definitely biased towards one style of development and frameworks, but that's a cultural artifact and not a technical limitation.

    peter
  97. Dave?[ Go to top ]

    Does Dave Thomas ever poke his head in here?

    Would be nice to hear from him on the subject since IIRC he has written the largest Ruby application to date (35,000 lines?).
  98. Amusing topic.[ Go to top ]

    You've got one of the best selling authors of all time recognizing the strengths in another language and environment. He's on the expert group, and a core contributor, for the technologies being discussed. He's a world-wide speaker and independent consultant with more experience than the hardest core die hards, haven written the best selling JSF book, to my knowledge.

    Dave's points are sound. The rapid turnaround time is important, even critical, for test-first development. For the most part, Java's not very good at it. In fact, like others, I believe that emphasis on tools rather than developers is a cop out. Ruby on Rails lets you build very sophisticated and dynamic model/view/controller applications, with very little start up time. There's something to the wild productivity claims that many make. I've seen it first hand. Now, a hard-core Java expert like David Geary sees it too. James Duncan Davidson, creator of Ant and Tomcat, loves Rails. Wake up. Rails is real.

    Neither of us is ready to dump Java, but we're both expanding our tool box, and learning how to adopt Java, where possible, to do some of the things that Ruby on Rails is very good at doing. I think that in many ways, I like Spring because it's good at extending Java in a way that feels more dynamic, with AOP instead of more direct metaprogramming, inversion of control and inner classes instead of code blocks, and now continuation-like approaches in Web Flow.
  99. ...[ Go to top ]

    So Bruce,

    As a consultant, have you ever sat down with an IT manager and recommended their next project be done with RoR instead of Java?

    I've seen Dave Thomas in person demonstrate RoR and know that it's real. That's the easy part. Managers with a vested interest in their tech stack may not be so easy to convince on many fronts (available developer base, contract rates, available training, board of directors buy-in, etc).

    Also please clarify if you meant "adopt Java" or "adapt Java" in your comment.

    Thanks.
  100. Recommending Rails[ Go to top ]

    So Bruce,As a consultant, have you ever sat down with an IT manager and recommended their next project be done with RoR instead of Java?

    I'm starting to recommend RoR in spots, with good success. Usually, it's a big relational database with a web front end and moderate complexity in business logic, where the developers control the schema. A rather tight niche, but a common one.
    Adapt or adopt

    Typo...adapt.
  101. Recommending Rails[ Go to top ]

    So Bruce,
    As a consultant, have you ever sat down with an IT manager and recommended their next project be done with RoR instead of Java?

    I'm starting to recommend RoR in spots, with good success. Usually, it's a big relational database with a web front end and moderate complexity in business logic, where the developers control the schema. A rather tight niche, but a common one.
    Adapt or adopt
    Typo...adapt.

    If it's a potential fit, I would think the right thing to do is to include it in the list of options. Why does everything have to either/or? That would be like telling a customer, "you should write your own bulletin board site," when they ask, "can you install PHPBB."

    peter
  102. Amusing topic.[ Go to top ]

    haven written the best selling JSF book, to my knowledge.
    ...
    I believe that emphasis on tools rather than developers is a cop out.

    +1 on tools.

    He wrote a great JSTL book as well.

    Re: Tools - think of it this way, if a business has a bad process and we automate it... it's just bad faster.
    More on TOOLS:
    http://www.hacknot.info/hacknot/action/showEntry?eid=76

    .V
    http://roomity.com
  103. Amusing topic.[ Go to top ]

    I believe that emphasis on tools rather than developers is a cop out.

    I strongly disagree. Firstly, that the emphasis is on tools rather than developers, secondly that tools are in any way a cop out. Some of the most productive development systems ever, like Smalltalk, are a tightly integrated combination of language and tools. Without the tools, development would be a real slog.
    Wake up. Rails is real.

    And it is wrong. I'm sorry to sound so definite, but I feel the same shiver of horror when I see it that I used to when I saw Visual Basic in the early 90s. It was quick to develop with, very productive, and led to a huge number of badly designed and unsupportable applications.

    Tying applications to a schema, when almost all modern languages and frameworks seem to be moving away from this, is going backwards. To me, this flaw is the 'elephant in the room' that so many ignore when talking about Rails. The points about turn-around time and dynamic development are important, but there are other languages that have illustrated this far more effectively over the years.
  104. Amusing topic.[ Go to top ]

    Wake up. Rails is real.
    And it is wrong.
    Don't you mean 'wrong in your opinion'? ;)
    I'm sorry to sound so definite, but I feel the same shiver of horror when I see it that I used to when I saw Visual Basic in the early 90s. It was quick to develop with, very productive, and led to a huge number of badly designed and unsupportable applications.

    I developed a few VB apps in the early 90's, and even back then it had an IDE and even a "GUI designer" of sorts -- a tool if you will. ;) But I do agree that it too eaisly led to a mess of VB code for large applications. But was that a fault of the tools or the language itself?
    Tying applications to a schema, when almost all modern languages and frameworks seem to be moving away from this, is going backwards.

    I've seen you say this several times. Can you elaborate on what langauges and what frameworks are moving away from, as you put it, 'applications tied to a schema'?
    The points about turn-around time and dynamic development are important, but there are other languages that have illustrated this far more effectively over the years.

    This is true, but it was my impression that the original article was to point out that we need to think about how we can *improve* Java, the process, the frameworks or a little bit of everything by looking at alternatives - the article did not recommend ditching Java and have everyone start coding in RoR.
  105. Amusing topic.[ Go to top ]

    Wake up. Rails is real.
    And it is wrong.
    Don't you mean 'wrong in your opinion'? ;)
    Yes :)
    I'm sorry to sound so definite, but I feel the same shiver of horror when I see it that I used to when I saw Visual Basic in the early 90s. It was quick to develop with, very productive, and led to a huge number of badly designed and unsupportable applications.
    I developed a few VB apps in the early 90's, and even back then it had an IDE and even a "GUI designer" of sorts -- a tool if you will. ;) But I do agree that it too eaisly led to a mess of VB code for large applications. But was that a fault of the tools or the language itself?

    Absolutely (in my opinion). Gates has seen full-features OOP systems in the 80s (he had praised Digitalk Smalltalk), yet VB was released without these features - no inheritance for example. It was definitely a 'cut back' language.
    Tying applications to a schema, when almost all modern languages and frameworks seem to be moving away from this, is going backwards.
    I've seen you say this several times. Can you elaborate on what langauges and what frameworks are moving away from, as you put it, 'applications tied to a schema'?

    Sure. JDO, EJB3 etc. in Java; endless Smalltalk ORMs, various ORMs in PERL, Python etc. This is where you define the data model in terms of classes in the language, and then define the mapping to a database schema, or even to another method of persistence.

    For an example of how I think RoR should have done things, take a look at Dejavu for Python. You build your model by creating classes, not tables.
    The points about turn-around time and dynamic development are important, but there are other languages that have illustrated this far more effectively over the years.
    This is true, but it was my impression that the original article was to point out that we need to think about how we can *improve* Java, the process, the frameworks or a little bit of everything by looking at alternatives - the article did not recommend ditching Java and have everyone start coding in RoR.

    I agree. My problem is that so many people do seem to be pointing at RoR as the thing to look at, or even to occasionally use. Zero turnaround times have been a common feature of development with dynamic languages for a very long time. There have even been MVC web frameworks for such languages for years, and some of those languages have had full-featured refactoring IDEs and first-class debugging capabilities.

    I guess this may be a personal prejudice! I have been battling with issues caused by database schema and vendor dependence in various projects for years. Now I am starting to resolve those issues through the use of serious ORMs and portable persistence APIs. When I see so many developers praising RoR, with the specific schema-dependence of ActiveRecord, I wonder if sections of the developer community are determined to ignore the hard lessons so many of us have learned.
  106. Amusing topic.[ Go to top ]

    ...yet VB was released without these features - no inheritance for example. It was definitely a 'cut back' language.

    Well, I don't want to go too far off on a Ruby tangent here, becaues that's not the point, but just for clarity, Ruby is very OO (moreso than Java, IMO) and nothing like VB. :)
    Tying applications to a schema, when almost all modern languages and frameworks seem to be moving away from this, is going backwards.
    I've seen you say this several times. Can you elaborate on what langauges and what frameworks are moving away from, as you put it, 'applications tied to a schema'?
    Sure. JDO, EJB3 etc. in Java; endless Smalltalk ORMs, various ORMs in PERL, Python etc. This is where you define the data model in terms of classes in the language, and then define the mapping to a database schema, or even to another method of persistence. For an example of how I think RoR should have done things, take a look at Dejavu for Python. You build your model by creating classes, not tables.

    Again, for clarity, this is just default behavior in Rails. You can actually change the table name, the primary key reference, the foreign key references, and I believe even the property -> column mappings. Not to mention the default persistence engine (ActiveRecord) can be replaced with other persistence engines.

    So I'm guessing your real issue is that, in your eyes, the default is a poor practice?
    My problem is that so many people do seem to be pointing at RoR as the thing to look at, or even to occasionally use.

    Guess I don't see this as a problem. Nothing is going to stop someone from writing unmaintainable code no matter what the language and framework is. Even as recent as the beginning of this year I had to convert a completely JSP scriptlet based application (not legacy -- written this year!) with JSTL (and eventually Spring WebMVC).
    Zero turnaround times have been a common feature of development with dynamic languages for a very long time. There have even been MVC web frameworks for such languages for years, and some of those languages have had full-featured refactoring IDEs and first-class debugging capabilities.

    Sure, I would agree -- I guess I've just never seen anyone put it all together and present it so completely (as in end to end) as RoR.
    I have been battling with issues caused by database schema and vendor dependence in various projects for years. Now I am starting to resolve those issues through the use of serious ORMs and portable persistence APIs.

    I think this is where you and I fundamentally disagree. Unless you're writing deployable, 'shrink-wrapped' software products, database independence is a novelty. For companies that implement frameworks, write in house (or contract) applications, it's a different story. So many factors go into a decision to switch databases, that are outside the technical realm. "We have XYZ DBA's, not 123 -- who's going to support the new DB?" Or, "We get XYZ bundled with our app server/middleware/other product. We're not paying for a new DB." Or even, "We have an existing support contract with vendor XYZ until 2007. We'll talk then." I can name probably 2 or three more that I've heard. That's been the reailty of the IT consulting projects I've been working on.
    When I see so many developers praising RoR, with the specific schema-dependence of ActiveRecord, I wonder if sections of the developer community are determined to ignore the hard lessons so many of us have learned.

    Again, I see it differently. I see it as covering the basic "get a 'developer-driven' web app up quickly and easily, with minimal fuss". I don't see it as a "let's ditch Java frameworks and put RoR on our legacy database" -- even though that's possible.
  107. Amusing topic.[ Go to top ]

    Ruby is very OO (moreso than Java, IMO) and nothing like VB. :)

    I agree!
    the default is a poor practice?

    Yes.
    Guess I don't see this as a problem. Nothing is going to stop someone from writing unmaintainable code no matter what the language and framework is.

    True. The difference is when something like RoR seems (at least to me) to actively encourage such unmaintainable practice as a good an innovative thing through its defaults.
    Sure, I would agree -- I guess I've just never seen anyone put it all together and present it so completely (as in end to end) as RoR.

    I don't think it is that complete. Everything is fine for the first pass through things, but when you get away from the initial scaffolding and start to develop large and rich applications, there seems to me to be a lot missing. I would rather have a system that can do compile-time checking of how changes to fields in class can impact my model, my view, and even the persistence. I would rather have an IDE and tools that can deal which such changes through refactoring. Anything else seems primitive to me.
    I have been battling with issues caused by database schema and vendor dependence in various projects for years. Now I am starting to resolve those issues through the use of serious ORMs and portable persistence APIs.
    I think this is where you and I fundamentally disagree. Unless you're writing deployable, 'shrink-wrapped' software products, database independence is a novelty. For companies that implement frameworks, write in house (or contract) applications, it's a different story....

    I have been developing database-linked software for both in-house and deployable software for 20 years. I certainly don't think independence is a novelty. On the contrary, I think it is a major advance in the way software is developed. There are issues of version dependence even for the same DB vendor if you want to support the software over several years. I really do develop software and test it on workstations or even laptops using PostgreSQL and MySQL and then deploy on Oracle, and although it is not, of course, 100% portable all the time, it works very well. It means I can develop even internal software and we can then decide on which database it is to be deployed.
    When I see so many developers praising RoR, with the specific schema-dependence of ActiveRecord, I wonder if sections of the developer community are determined to ignore the hard lessons so many of us have learned.
    Again, I see it differently.
    I see it as covering the basic "get a 'developer-driven' web app up quickly and easily, with minimal fuss". I don't see it as a "let's ditch Java frameworks and put RoR on our legacy database" -- even though that's possible.

    Of course, I see it differently :)

    I think the "get any app up and quickly and easily with minimal fuss attitude" has been a serious problem for IT for a long time, as it has led to so many projects that have failed when the needed to deliver scalability and performance.

    In my 30 years as a developer, I have only used one environment that has come close to being able to deliver both the "minimal fuss" and "long-term supportable and scalable" promise and that is Smalltalk. You get zero turnaround time, web frameworks, true ORMs (including very high-performance commercial ones, such as Gemstone), IDEs with full-featured class browsing, refactoring, debugging, and all available on open-source implementations of the language. By comparison, Ruby on Rails looks (to me) primitive.
  108. Amusing topic.[ Go to top ]

    I developed a few VB apps in the early 90's, and even back then it had an IDE and even a "GUI designer" of sorts -- a tool if you will. ;) But I do agree that it too eaisly led to a mess of VB code for large applications. But was that a fault of the tools or the language itself?
    It is not a VB fault, it just a component oriented framework misuse. VB and VBA are designed to customize componets not to develop components or to be used as programming language (It is possible to use this stuff for programming, but it is lame). C++ with ATL and MFC stuff is used to develop components, scripts are used for fast prototyping and customizations like trivial event handlers (handlers delegate to custom components again in non trivial cases). There are many well designed ActiveX applications (and probably more than SmallTalk stuff) It must be better to learn from this stuff before to envent component oriented frameworks with known mistakes like JSF and to blame MS. Component oriented development was discredited by lames (in the same way as EJB), lames will descredit ORM stuff later too ( "You do not need to learn SQL, RDBMS is yust a persistent store ... ") .
  109. Amusing topic.[ Go to top ]

    It is not a VB fault, it just a component oriented framework misuse. VB and VBA are designed to customize componets not to develop components or to be used as programming language (It is possible to use this stuff for programming, but it is lame). C++ with ATL and MFC stuff is used to develop components

    No, this is not the case. You can now develop components in VB, and you have been able to for some time.
    It must be better to learn from this stuff before to envent component oriented frameworks with known mistakes like JSF and to blame MS.

    If Microsoft produced a cut back language to prevent use of features such as inheritance or development of components, it is fair to judge them on this (and to question their use of terms like 'innovative' to describe their adding these features years later). You can develop your own components with JSF; it simply isn't (yet) trivial. It is (in my view) rather extreme to call JSF a 'framework with known mistakes'.
    "lames will descredit ORM stuff later too You do not need to learn SQL, RDBMS is yust a persistent store"

    These are simply straw man arguments you keep repeating. We have convered this ground in depth in other threads. Use of ORM does not, of course, mean you do not need to learn SQL or that RDBMS is just a persistence store, for the majority of applications.
  110. Amusing topic.[ Go to top ]

    No, this is not the case. You can now develop components in VB, and you have been able to for some time.


    It was a very good reason not to develop and maintain componets writen as "script". This mistake is well known in UNIX too (like awk vs. C).

    Use of ORM does not, of course, mean you do not need to learn SQL or that RDBMS is just a persistence store, for the majority of applications.
    If applications doe's do not need RDBMS (Relational Database Management System) and uses it anyway (for object persistence only), then it is a lame technology usage or misuse again. I see some poster blame DBA on this thread too ... .

    I am too lame to talk about JSF at this time, but I will try it (any JEE programmer must use "standard" to be JEE programmer :)). Probably it is possible to avoid old JSP problems and known component development problems in JSF too.
  111. Amusing topic.[ Go to top ]

    If applications doe's do not need RDBMS (Relational Database Management System) and uses it anyway (for object persistence only), then it is a lame technology usage or misuse again.

    This seems to me to be a rather restrictive point of view, especially as many features of relational stores are useful for persisting and retrieving objects.

    However, this is getting off topic...
  112. Amusing topic.[ Go to top ]

    If applications doe's do not need RDBMS (Relational Database Management System) and uses it anyway (for object persistence only), then it is a lame technology usage or misuse again.
    This seems to me to be a rather restrictive point of view, especially as many features of relational stores are useful for persisting and retrieving objects.
    I am talking about direct B+tree usage for persistence and CRUD stuff. If data is not relational then it makes sence to transform it (for many reasons), but if data doe's not need to be managed then data management system doe's not make any sence.
    However, this is getting off topic...
    This kind of forums ("A" vs "B") are noisy anyway ...
  113. Amusing topic.[ Go to top ]

    You've got one of the best selling authors of all time recognizing the strengths in another language and environment. He's on the expert group, and a core contributor, for the technologies being discussed. He's a world-wide speaker and independent consultant with more experience than the hardest core die hards, haven written the best selling JSF book, to my knowledge.

    oh, come on, Bruce. Speaking and writing are no certification of anything other than being willing to do them. I know lots of great developers and architects who just aren't interested in spending the time to write a book or who don't want to stand in front of a roomfull of people.
    Dave's points are sound. The rapid turnaround time is important, even critical, for test-first development.

    What sort of test-first development are you doing that you need to have things immediately available in the container? In my unit tests my classes are immediately available for testing...
    For the most part, Java's not very good at it. In fact, like others, I believe that emphasis on tools rather than developers is a cop out. Ruby on Rails lets you build very sophisticated and dynamic model/view/controller applications, with very little start up time. There's something to the wild productivity claims that many make. I've seen it first hand. Now, a hard-core Java expert like David Geary sees it too. James Duncan Davidson, creator of Ant and Tomcat, loves Rails. Wake up. Rails is real.Neither of us is ready to dump Java, but we're both expanding our tool box, and learning how to adopt Java, where possible, to do some of the things that Ruby on Rails is very good at doing. I think that in many ways, I like Spring because it's good at extending Java in a way that feels more dynamic, with AOP instead of more direct metaprogramming, inversion of control and inner classes instead of code blocks, and now continuation-like approaches in Web Flow.

    Blah blah, name dropping, blah.... Has the first RoR enterprise application been written yet? More important, has it had it's 3rd release yet (that's usually when unmaintainable code will blow up on you, @see Netscape).
  114. Amusing topic.[ Go to top ]

    oh, come on, Bruce. Speaking and writing are no certification of anything other than being willing to do them.

    While what you say may be true, Bruce is very thoughtful and has shown a willingness to question his assumptions.

    While RoR may be a bit hyped, the real question is why Java app containers managed to get such a bad rap in the first place. There's no good _technical_ reason for slow re-deploys or requirements to restart containers ....

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  115. Amusing topic.[ Go to top ]

    oh, come on, Bruce. Speaking and writing are no certification of anything other than being willing to do them.
    While what you say may be true, Bruce is very thoughtful and has shown a willingness to question his assumptions.While RoR may be a bit hyped, the real question is why Java app containers managed to get such a bad rap in the first place. There's no good _technical_ reason for slow re-deploys or requirements to restart containers

    The ironic thing is that the Java platform *did* solve the ZTT issue, six years ago, when JSP pages could be recompiled in place. But all the Enterprise Java "experts" sneered ... "ewwww ... scriptlets ... intermixed business logic and presentation logic ... yuck!!!!"

    (Present company ***not*** excepted from this comment :-)

    The biggest problem with JSP turns out not to have been scriptlets. The biggest problem is that the ZTT capability of this environment tempted developers to mix things up that they shouldn't. Of course, you see this same temptation in any scripting language (compare the code of a PHP developer who has a clue what objects are about to the code a typical PHP newbie spews out). But I digress.

    There actually is a technically difficult challenge to providing ZTT capabilities that don't encourage bad habits. That is the lack of ClassLoader.unloadClass() in the JVM. It is certainly not a fatal flaw -- obviously, the folks building JSP compilers were able to work around it -- but it is a challenge for those of us providing development tools to pay attention to.

    Craig McClanahan
  116. Amusing topic.[ Go to top ]

    There actually is a technically difficult challenge to providing ZTT capabilities that don't encourage bad habits. That is the lack of ClassLoader.unloadClass() in the JVM. It is certainly not a fatal flaw -- obviously, the folks building JSP compilers were able to work around it -- but it is a challenge for those of us providing development tools to pay attention to.Craig McClanahan
    JVM has a standard way to "unload" class since 1.5 release (it was not standard before 1.5). Probably it cam help for ZTT, but JSP code generation and compilation is slow anyway and this step is usefull for flawed scriptlets only.
  117. Amusing topic.[ Go to top ]

    There actually is a technically difficult challenge to providing ZTT capabilities that don't encourage bad habits. That is the lack of ClassLoader.unloadClass() in the JVM. It is certainly not a fatal flaw -- obviously, the folks building JSP compilers were able to work around it -- but it is a challenge for those of us providing development tools to pay attention to.

    Craig, the biggest problem with the "Z" in "ZTT" is that most of the app servers used the same crap approach to compiling JSPs:

    1) Use Apache's Jasper to produce .java
    2) Use JDK's JavaC (i.e. create a new process that loads a JVM that loads 1000 classes and takes 5 seconds to start) to compile the .java to a .class
    3) Read the resulting .class(es) and clean up the mess the previous two steps made
    4) Use a temp class loader to define those classes

    That would have been an OK approach .. for a prototype in 1996 maybe. A "good" JSP compiler should be able to do steps 1..3 in about 5ms, and have the line numbers correct.

    As for unloading classes, there's no reason to. Just give the new class a different name and load it in the same class loader. Every couple thousand JSPs, just create a new classloader and lose the refs to the old one. (That lets the classes unload and the memory be reclaimed, and has mostly worked since JDK 1.0.2 in '96.)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  118. Craig, the biggest problem with the "Z" in "ZTT" is that most of the app servers used the same crap approach to compiling JSPs:

    1) Use Apache's Jasper to produce .java
    2) Use JDK's JavaC (i.e. create a new process that loads a JVM that loads 1000 classes and takes 5 seconds to start) to compile the .java to a .class
    3) Read the resulting .class(es) and clean up the mess the previous two steps made
    4) Use a temp class loader to define those classes

    At my work, I too got completely fustrated with the standard JSP approach of compiling code like this, with no line numbers, forced output to HttpResponse, slow refreshes, no refreshes when using included pages.... the list of flaws seemed endless.

    Instead, we developed a small product, maybe 10 classes, that reads a JSP file with tags, parses it to objects, and processes output from the objects.
    - each object records line numbers for errors
    - output is to a string buffer
    - multi-language setup just worked, as everything uses Java Strings
    - it re-reads the JSP file each time (optional), so you get ZTT for JSP pages
    - included JSP pages are no different to top-level JSP pages

    And the speed? Well, the read, parse and output turned out to be easily fast enough that we run live production systems that way (much faster than java compilation times). It won't suit Google, or EBay, but it does suit the rest of us.

    There is a downside with our implementation. It doesn't support scriptlets. No Java code is allowed. But we just use tags, so its actually a way to enforce a coding convention.


    Now, perhaps there might be interest in starting an open source project to replicate this code ;-) ???

    Stephen
  119. Just to clarify:
    Our tool just uses memory: there is NO compilation, NO temporary java class, NO javac.

    Sorry I wasn't clear.
    Stephen
  120. Amusing topic.[ Go to top ]

    As for unloading classes, there's no reason to. Just give the new class a different name and load it in the same class loader. Every couple thousand JSPs, just create a new classloader and lose the refs to the old one. (That lets the classes unload and the memory be reclaimed, and has mostly worked since JDK 1.0.2 in '96.)Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    It was worked on "old" JDK releases, but it was changed by specification and class can not be unloaded if class loader is reacheble ( JVM must unload class if and only if loader is unreacheble ) "singleton" was the motivation for exception in garbage collection.
  121. Amusing topic.[ Go to top ]

    It was worked on "old" JDK releases, but it was changed by specification and class can not be unloaded if class loader is reacheble ( JVM must unload class if and only if loader is unreacheble ) "singleton" was the motivation for exception in garbage collection.

    Understood. So make the ClassLoader unreachable ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  122. Amusing topic.[ Go to top ]

    What sort of test-first development are you doing that you need to have things immediately available in the container? In my unit tests my classes are immediately available for testing...
    As containers get better and code is more decoupled, you frequently have to test your pojos in context. That often means testing in container, for a significant percentage of the time. I've done TDD with both Java and Ruby. In my opinion, Ruby is much better at it. I don't think it's even arguable.
    Blah blah, name dropping, blah.... Has the first RoR enterprise application been written yet? More important, has it had it's 3rd release yet (that's usually when unmaintainable code will blow up on you, @see Netscape).
    You're changing requirements on me. I've never said anything about enterprise apps. (What are you calling an enterprise app? An app in an enterprise?) As far as I know, no one on this thread has suggested deploying RoR for apps requiring distributed two phased commit. Has RoR demonstrated success? Sure...for exactly the types of projects that I recommend for RoR. That's a database schema, controlled by the development team, babysat by a web ui. We build that app more often than any other Java app.

    Have we hit release 3? Let's just say that Ruby is proven; Active Record in dynamic languages is proven; MVC is proven. Ruby is about the metaprogramming, conventions and glue that let you get to a sound, proven architecture more quickly, and with more code in the framework instead of maintained by individual developers.

    Rails is not the only good tool, but certainly a good tool, that's certainly growing in market share among experts and novices based on good marketing and lots of technical merit. I think you should also pay attention to the hostility directed in the Rails direction. Most awful open source tools simply get ignored and go away.
  123. Amusing topic.[ Go to top ]

    Let's just say that Ruby is proven

    I have to disagree somewhat. Even the designer of Ruby considers current versions as flawed, and plans future versions which will contain major revisions, even to the extent of breaking existing code. (At least, this is how I understand things) In my view, this is not a situation which encourages any significant development in current versions of the language.
  124. Amusing topic.[ Go to top ]

    As containers get better and code is more decoupled, you frequently have to test your pojos in context. That often means testing in container, for a significant percentage of the time.
    Isn't it the contrary? As containers get better and code is more decoupled, there's _less_ dependency between your app and the container, thus reducing the need to to test in container. AFAIK, Spring and EJB3 are examples of that.

    Regards,
    Henrique Steckelberg
  125. Amusing topic.[ Go to top ]

    As containers get better and code is more decoupled, you frequently have to test your pojos in context. That often means testing in container, for a significant percentage of the time.
    Isn't it the contrary? As containers get better and code is more decoupled, there's _less_ dependency between your app and the container, thus reducing the need to to test in container. AFAIK, Spring and EJB3 are examples of that.Regards,Henrique Steckelberg

    Yes, absolutely right. There are some classes of problems which are very complicated to unit test (mostly because they're glue code between different pieces) and those are easier to test in-container. It's (part of) my job to keep the rest of my team from having to touch those.

    This whole thread reminds me of the old argument about whether to do something the right way or just the quick way to get it out the door. The thing is, once your app gets out there and it's in use, you don't know where it's going to go. If it's popular it's going to be asked to outgrow the tight little box Bruce has drawn around where RoR is a good fit. Once it gets to a certain size, the DBA / Information Architect group is going to step in, and now you've lost the tight control over your database schema. Next you're going to be asked to make it integrate with other apps, so you're going to need to figure out how to do integeration... Maybe if you're lucky the other apps can expose web services, otherwise you're stuck trying to build some infrastructure to mimic JCA. Now you're trying to find Ruby database drivers that support XA transactions... good luck there, after all these years the Oracle JDBC drivers still blow :-)

    If it takes you 2 months instead of 1 month to build it in Java, but you don't have to write JCA or have to debug database drivers, which one gets to the final end state first?
  126. Amusing topic.[ Go to top ]

    Sure...for exactly the types of projects that I recommend for RoR. That's a database schema, controlled by the development team, babysat by a web ui. We build that app more often than any other Java app.

    by we, I assume you mean your team and not "we" as in the java community at large. If I was building a personal site, ROR feels attractive.

    there seems to be a disconnect between the enterprise and non-enterprise people. People who work on large enterprise systems with multiple models and challenging integration point out the limitations of ROR, while those who have never done large scale dev claim ROR will rule the world. those who have seen both see worlds see where ROR might fit. In the end, it's just another tool. nothing new, no magic, just another round of flame wars.

    peter
  127. Amusing topic.[ Go to top ]

    Look at PHP first if you are going to build personal site, hosting is the most important aspect for this kind of stuff. Probably ROR is a better script than PHP,perl,python,TCL, ... , but I think it is very hard to prove this fact.
  128. Amusing topic.[ Go to top ]

    there seems to be a disconnect between the enterprise and non-enterprise people
    Also between the "webapp" and "application with a web UI" people. Then again, this might be a slight renaming of what you used.
  129. Give me taglibs and JSP[ Go to top ]

    For starters, I think that the proliferation of web frameworks is largely a waste of people's time. I've been writing web applications for years, and there's nothing I can't do quickly, cleanly and correctly using JSP pages and custom taglibs. In fact things were only a little bit worse back when I was using beans instead of tags.

    Most web frameworks just give developers a different way to do stuff they already know how to do. They all have their downsides to go with their upsides. A significant downside of any third-party framework is that it commits the developer and the company he's working for to a nonstandard platform that is more likely to be orphaned or become incompatible with future J2EE servers than something that is officially part of the spec.

    What web developers could really use is more high level tools, not more general purpose tools. How many web developers think they're being productive by choosing the latest third-party framework and then using it to write yet another shopping cart application? The real productivity is in not having to write the shopping cart in the first place because you were able to reuse someone else's. Same goes for forums, content management, etc, etc.

    Today's proliferation of general purpose frameworks reminds me of the 80s when everybody and his brother had their own C compiler. Yeah, it's a sexy and cool thing to do, and it lets you show off your skills to other programmers. But is it really necessary or important?

    Frank
  130. Give me taglibs and JSP[ Go to top ]

    For starters, I think that the proliferation of web frameworks is largely a waste of people's time. I've been writing web applications for years, and there's nothing I can't do quickly, cleanly and correctly using JSP pages and custom taglibs.

    If you're working by yourself, that's fine, although I'd still argue that its less productive. It's even more impractical with teams of developers working towards tight deadlines, all trying to maintain a consistent look and feel across an entire site.
    A significant downside of any third-party framework is that it commits the developer and the company he's working for to a nonstandard platform that is more likely to be orphaned or become incompatible with future J2EE servers than something that is officially part of the spec.

    Not sure I follow this. So you're saying I should dump Spring for EJB just because EJB is more likely to be compatible? On the contrary, these 'third-party' frameworks actually *are* garnering support in the app server community (see Struts, Spring and Hibernate). Though the beauty is that is none of these frameworks actually 'require' a J2EE app server.
    The real productivity is in not having to write the shopping cart in the first place because you were able to reuse someone else's. Same goes for forums, content management, etc, etc.

    I view these as applications, not frameworks. Are you advocating RAD tools? Or just pluggable applications? My past experience in the ERP world indicates that it's a monumental undertaking to try to create an application that meets the needs of all customers -- or even just half the needs *or* the customers.

    I think the point here is that more frameworks = more choices. IMO, it's an architects job to evaluate these frameworks to see if they fit within their organization (skillsets, timeframes, productivity, ramp-up time, etc.). But nothing prevents someone from using standard JSP and taglibs.
  131. Give me taglibs and JSP[ Go to top ]

    For starters, I think that the proliferation of web frameworks is largely a waste of people's time. I've been writing web applications for years, and there's nothing I can't do quickly, cleanly and correctly using JSP pages and custom taglibs. In fact things were only a little bit worse back when I was using beans instead of tags.Most web frameworks just give developers a different way to do stuff they already know how to do. They all have their downsides to go with their upsides. A significant downside of any third-party framework is that it commits the developer and the company he's working for to a nonstandard platform that is more likely to be orphaned or become incompatible with future J2EE servers than something that is officially part of the spec.What web developers could really use is more high level tools, not more general purpose tools. How many web developers think they're being productive by choosing the latest third-party framework and then using it to write yet another shopping cart application? The real productivity is in not having to write the shopping cart in the first place because you were able to reuse someone else's. Same goes for forums, content management, etc, etc.Today's proliferation of general purpose frameworks reminds me of the 80s when everybody and his brother had their own C compiler. Yeah, it's a sexy and cool thing to do, and it lets you show off your skills to other programmers. But is it really necessary or important? Frank

    I don't agree that web frameworks are a waste. Having lived through three companies with 3 different web frameworks, the consistency ushered in by Struts has been the #1 contribution to development by Struts, IMO. Before Struts, each company had its own web framework. And guess what? Since developers, myself include don't like writing documentation, how easy was it to ramp up. You had no forums, no books, no resources, entire sections abandoned because the guy who wrote his piece is gone.

    Struts may not be revolutionary, may not be the best implemenation, but it allowed all of us to adopted certain practices that pretty much every subsequent web framework followed, while allowing developers to move from project to project with a shallower ramp up.

    In addition, no matter how cleanly or quickly you can write, you cannot match the input that thousands of users will have on the usability of the framework.

    Raw JSP has fallen by the wayside because speed and corrects were goals not achievable consistently from company to company.

    I would say that Struts has proven your concerns that non-standard third-party frameworks being orphaned and unsupported are unfounded. In fact some of the best work from third parties like Log4j, Struts, Spring, Hibernate, and JDOM all seem to have more support and more compatibility than say EJB 1.0, a standard in the purest sense.
  132. Give me taglibs and JSP[ Go to top ]

    For starters, I think that the proliferation of web frameworks is largely a waste of people's time. I've been writing web applications for years, and there's nothing I can't do quickly, cleanly and correctly using JSP pages and custom taglibs. In fact things were only a little bit worse back when I was using beans instead of tags.Most web frameworks just give developers a different way to do stuff they already know how to do. They all have their downsides to go with their upsides. A significant downside of any third-party framework is that it commits the developer and the company he's working for to a nonstandard platform that is more likely to be orphaned or become incompatible with future J2EE servers than something that is officially part of the spec.What web developers could really use is more high level tools, not more general purpose tools. How many web developers think they're being productive by choosing the latest third-party framework and then using it to write yet another shopping cart application? The real productivity is in not having to write the shopping cart in the first place because you were able to reuse someone else's. Same goes for forums, content management, etc, etc.

    Today's proliferation of general purpose frameworks reminds me of the 80s when everybody and his brother had their own C compiler. Yeah, it's a sexy and cool thing to do, and it lets you show off your skills to other programmers. But is it really necessary or important? Frank

    I've used JSP and JSTL quite a bit. Haven't used Struts or ROR, but the one thing I'm pretty about is there's no single web framework to rule everything. I seriously doubt ROR would replace Struts in large projects in the hear future. It's also unlikely PHP sites are going to switch over to ROR.

    I don't agree it's a waste of time. It's a waste of time to some people, but to those writing frameworks, it's a great learning experience. That doesn't mean anyone should use a framework because it's new. If a framework works better than other tools and meets all the requirements, then use it. If not, being simplistic and saying J2EE is vendor centric and ROR is developer centric is disingenuous. There are plenty of Java projects are definitely developer centric.

    The Java landscape is diverse. If JSF fails to meet developer's needs, then it should die. It's as simple as that. If JSF is well thoughtout, but a specific vendor's implementation blows, then it should die. Drawing wild conclusions without pretty weak proof doesn't help move things forward.

    that's my bias 2 bits

    peter
  133. While this type of rapid development can be a big improvement in some applications, current tools deliver some type of rapid development for the current technology. Using tools like MyEclipseIDE i have most of this things most of the time (sometime it breaks).

    Nevertheless i think the real problem of Java EE is the fact, that it promises a component oriented world but i rarely see some real reuseable components based on this technology. If this promise would fulfill, we all were happy to edit all those XML based deployment descriptors etc. and to live with all impacts of these technologies.

    But after all i see some "light" shining at the horizons. Developing applications based on Tapestry (or JSF), Spring / Hivemind, Hibernate enables us to create some build blocks for applications of increasing size.

    And this may after all make the difference for complex enterprise applications.
  134. I definately like that there are people who are thinking about these things and trying to bring improvements in Java. Java only has things to gain, not lose.

    I understand why zero turnaround is important, because I can see how much it would help my own work. I really do not want to restart my web server or application server every time I have made a change. Sometimes it is not required but it is still a big nuisance when you have to do it.

    To me this is just a matter of focus, and Java can have all the things that RoR brings. In deed, there are Java adaptations of RoR that show that there is no reason why it can't be done in Java.

    From this perspective, all this Java vs. RoR discussion is like an inflated balloon. There might be the initial argument that J2EE is not focused in zero turnaround, but on the other hand, there is no reason why it could not. Therefore, it is good that these kinds of frameworks are brought forward as an example, but it is wrong to start advertising it as Java's demise, and that Java has a critical flaw - when none of that is true in the least.

    This tool discussion is getting out of hand as well. If you want to program Java things with a plain text editor, there is no reason why you can't do that. Afterall, most of us use only a slightly enhanced editor anyway for most tasks. Why is it wrong to have syntax highlighting, context helps, refactoring, plugins for launching Ant tasks etc. I personally do not need more than that 99% of the time and I suspect that an average Java developer is like I am.
  135. Pick Your Poison[ Go to top ]

    Let's consider two sound software engineering principles:
    1. Architectural layers should be cleanly separated with minimal dependencies.
    2. Don't repeat yourself.

    In RoR, your object model isn't cleanly separated from your database schema. Consequently, if there's a mismatch in the best way for your object to represent data and the best way for it to be persisted in a database, you're screwed. However, if there isn't a mismatch, or only a minor one, you get to avoid repeating yourself. The persisent data fields of your objects are defined in exactly one place - the database.

    Now, if you use Java and Hiberate, your object model and your database schema are reasonably loosely coupled. However, in order to achieve this loose coupling, you have to maintain three different definitions of your object: the Java class, the database schema, and the mapping between the two.

    So pick your poison. In Java, you can use annotations and code generators to reduce the tedium of maintaining triplicate definitions. In RoR I'm sure you can use some sort of facades over the schema-generated classes, or simply add methods/properties to them, in cases where your Ruby object needs to be different from your schema. But either way you're patching a design flaw in the underlying framework.
  136. Pick Your Poison[ Go to top ]

    your object model isn't cleanly separated from your database schema.

    Are per OMG? as read in a bathroom stall?
    I heard same argument about PHP(Drupal, TikiWiki,etc) and Plone and .NET people using stored procecuders, and all very sucessfull, and w/ great ROI.

    So lets consider this statment, to see if others can scientificaly duplicate this: "having a domain layer match the physical db and vice vera is very efficent and scaleable as proved by observation. Not naving a the 2 match leads to impedence". In esence you create a view prototyoe, and based on that do a db design, so that you querries are scaleable. I do not expect people new to development to necceseraly be able to absorb this, nor do I need them to.
    You *can* have a separte layer, that at the same time is a matching layer, designed for each other. Check w/ you DBA as to what makes your querries scale and why. (or do we not need DBA as per EJB/OMG?)
     
    In some Java organizations, the EJB marketing is taken as science, and "archictects" (aka: amatures that *NEVER* delivered a system to production) advocate that domain do not need to match db. My view, expressed in struts term is this:
    - The (HTML) "Form" matches "FormModel"(modern Struts often a Map, rather then a Bean).
    - The domain DAO (ibatis) matches the physcial DB.
    - We can design the db only after mock and prototype is done.
    (of course I no longer do Struts in favor of client side JDNC)
    So this whole EJB marketing promo was a dead end, fubar, used by pretneders. I even wonder if Sun knew that it does not work, racketering style. Lets not ever again use eWeek articles for architecture.

    Groovy I think is good aproach to simplify "J2EE", still use our jars, but simplify the implementation (and get rid of pre-processor defintions noise, aka anotations). We are all looking to get of this ship, untill a dominat palayer emerges: http://brennan.offwhite.net/blog/archives/000216.html
    At least Groovy is Java based, relative to Ruby, and it simplifies! (unlike BSF, which does not improve anything, it's same). So try Groovy for your back end (supported by jEdit editor, without a plug in).

    Last, realying on IDE and GUI generators is a bad idea, as per "Pragmatic Programers".

    .V
    http://www.theserverside.com/articles/article.tss?l=RiA
    roomity.com
  137. your object model isn't cleanly separated from your database schema.
    Are per OMG? as read in a bathroom stall?I heard same argument about PHP(Drupal, TikiWiki,etc) and Plone and .NET people using stored procecuders, and all very sucessfull, and w/ great ROI.So lets consider this statment, to see if others can scientificaly duplicate this: "having a domain layer match the physical db and vice vera is very efficent and scaleable as proved by observation. Not naving a the 2 match leads to impedence". In esence you create a view prototyoe, and based on that do a db design, so that you querries are scaleable.

    Some like Active Record, some don't. I say use the right tool for the job. Rails is not alone. Many Java frameworks are better when the schema and object model are highly similar. For small and intermediate apps (that often turn into large Java development efforts), the development team in fact does control the schema. Most of the DAO generation frameworks have some sort of practical requirement like this. RoR lets you break away from the model, or even replace ActiveRecord alltogether, and I think it's easier to replace in RoR than most integrated frameworks I've seen. It's just that at some point, the risk overwhelms the reward, and for RoR, the rewards are greatest when the schema and model mostly match. At least, that's where I deploy it.

    Spare me the ORM rhetoric. I've heard it all before, and have taught both Hibernate and Kodo JDO. You get tremendous benefit at tremendous cost with both. As with other technologies, choose the right tool for the job. Sometimes, ORM is overkill.

    You may not like RoR, but you'll come across as less of a blow hard if you actually try Rails for something nontrivial and base your criticisms on tangible problems in Rails. Active Record is a design pattern that's used in the Java space too. (See Fowler's patterns of enterprise development.) Many of the arguments against on this thread are misplaced. Rails is more object oriented, in general supports a cleaner code base, allows better metaprogramming and cleaner adaptability, requires far less code, and is much faster to learn than most Java stacks. From what I've learned so far, it's faster and easier to maintain too. There's less code, and the MVC code that does exist is easier to test and easier on the eyes. Java's design patterns may not always be the right answer to very question.

    I avoided Rails for a long time based on what I thought I knew. I basically tried it to shut up some of the evil bloggers in RoR land. Like David, I'm a Java author with a whole lot to lose. I didn't want to have the success that I did when I tried Rails. But now my eyes are wide open. To be sure, it's not the only tool in by box, but it's an increasingly important one.

    Kudos to David for coming out and telling the truth about his experiences, eating major crow in the process.
  138. I avoided Rails for a long time based on what I thought I knew. I basically tried it to shut up some of the evil bloggers in RoR land. Like David, I'm a Java author with a whole lot to lose. I didn't want to have the success that I did when I tried Rails. But now my eyes are wide open. To be sure, it's not the only tool in by box, but it's an increasingly important one.

    We were looking into using RoR for some of our new apps but decided to put it on hold, at least until Ruby2/Rite is released. The reasons mainly were:

    [] Some 3rd party Java libraries we use would not be easy to call from Ruby
    [] Better support for RDBMS' other than mySql
    [] No JIT for Ruby VM, yet
    [] Ruby is not widely enough used (yet), in my opinion.

    Regardless of the above, R/RoR does look very interesting and, I think, we'll hear a lot of goods things about the language and the framework in the coming years.

    --
    Igor Zavialov, Factoreal Corp.
    Factoreal Web Service API for Financial Data
  139. For small and intermediate apps (that often turn into large Java development efforts), the development team in fact does control the schema. Most of the DAO generation frameworks have some sort of practical requirement like this. RoR lets you break away from the model, or even replace ActiveRecord alltogether, and I think it's easier to replace in RoR than most integrated frameworks I've seen. It's just that at some point, the risk overwhelms the reward, and for RoR, the rewards are greatest when the schema and model mostly match.

    It's all about "better/faster/lighter" ;-) I am all for that. (Things like Struts are sucessfull, becuase they are simple).

    I disagree about the "impedence" statment above, nothing in myth of Java that lets it scale on large scale when the e/r models does not match the domain/dao, that would be magic, not science. If the E/R does not match the requirments, that is a problem for scalability.
    otoh, I bet you anything that best Jave Apache DAO/PetStore (iBatis! and it's SQL based) will run cicles arround RoR in productivity and performance. In Java, you have a choice to chose a good implemntation or a bad one. Simple = scaleable. A computer can be either simple and fast or complex and slow.

    Java's *best chance to survive* after:
    -EJB (vs E/R),
    -JSF (vs anything),
    -anotations(back to C pre-processor definitions)
      is:
    -JDNC, (for client side rendering of UI layer, minus their DS)
    -Groovy, (instead of Ruby)
    -and Harmony (for cross platfrom deployment of runtime, eg: Mac, Linux PPC, shiped by vendors on PCs, etc. Quite hard deploying now w/ Sun's controll of JRE. JRE in Mustang is a huge download, but no support for Linux PPC or Mac )
    Only one of these things esential to Java future is Sun related(JDNC). They continue to sink and would be OK w/ status quo (EJB, JSF-server side rendering of UI, and deployment of JRE as is). Sun aproach to fixing EJB, JSF, JRE is marketing and changing names, puting more lipstic on the pig that just won't sing. If only people realized that using "magic" beans, they DON"T have to worry about E/R.
    Some of use got a C/S degree, where the word Science means that it can be independenlty reporudced in our enviroment. Magic is poof that hapens on stage.

    (I think even E. Hatcher may be a RoR fun)

    Come back from RoR, PHP, etc. and use Java like it was RoR or PHP, same dessign paters can be implemented w/ same benefits!

    .V
    http://rOOmity.com - where you can see java's bigest advantage implemented (JDNC)

    "Any fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction.}
    -E.F. Schumacker
  140. I disagree about the "impedence" statment above, nothing in myth of Java that lets it scale on large scale when the e/r models does not match the domain/dao, that would be magic, not science. If the E/R does not match the requirments, that is a problem for scalability.

    I'm going to take this to mean: If the (insert your language here) object model doesn't match the E/R model, then the application will not scale.

    As a rule of thumb, that may be true. But there are cases where just the opposite is true.

    Let's say several of your primary domain classes have a requirement on them to have access control lists that determine which users can view, update, delete, and/or change edit permissions of each object. The permissions-related behavior is the same for all your domain classes.

    You create an abstract baseclass called PermissionedObject that implements permissions-related methods. PermissionedObject uses instance of a class called UserPermission to represent what each user who has access to the object can do (if there's no UserPermission instance for a User, then the User has no access to the object). All your domain classes that need permissions are derived from PermissionedObject.

    Now you have to decide: Do you use one table to represent all of your UserPermission objects? Do you use one table per concrete PermissionedObject class?

    If you force your schema to match your class model the way ActiveRecord does, then you use one table to store all of the UserPermission objects.

    This has a couple problems. The first is you end up with about a billion rows in the UserPermission table, and pretty much every transaction has to hit this table one or more times. The second is determining how you relate the entries in the UserPermission table to each concrete class table and still user proper referential integrity constraints.

    I've seen this before in a commercial system and it creates a performance nightmare. DBAs pull their hair out and demand gigabytes upon gigabytes of RAM so they can put the entire table, and its indexes, into memory.
  141. E/R model and object model are almost the same stuff, both are informal (conceptual) models, object model just adds "operation" concept. Probably you are talking about logical or physical models, this stuff doe's not need to "match" conceptual model and there are many good reasons not to pollute conceptual model with implementation details (physical model) and to transform conceptual model to formal (logical model).
    Performance is physical model aspect, "big table" problem is solved using "partition","index". Constaints belong to logical model and physical model aspects must not drive it too.
  142. Pick Your Poison[ Go to top ]

    your object model isn't cleanly separated from your database schema.
    Are per OMG? as read in a bathroom stall?

    As per the fact that in RoR your object model is generated based on your database schema. Hence why you don't have to have to define what is very often the exact same information in three different places.
    I heard same argument about PHP(Drupal, TikiWiki,etc) and Plone and .NET people using stored procecuders, and all very sucessfull, and w/ great ROI.

    Having an object model that matches the database schema isn't inherently bad. It isn't inherently good, either. It depends on your requirements and your development team.
  143. In Java EE, Zero Turnaround Time has been negelected and need to take more importance. Ruby on Rails exploit a weakness in JavaEE that is resolvable. Could J2EE expert group enforce through specs the Zero Turn Around time? Java EE is not at fault in all its parts, but ZTT is lost too often through the stack. It is worse on the web tier because you cannot unit test all pages details.

    I recently tried Netbeans 4.1 with SJAS 8.1. I didnt find an easy way to not always redeploy for changes to JSP. I'm new to EJB development and this was a big show stopper for me. After much search, I found a semi-functionnal way to develop and test pages in separately deploying modules (ejb,web) and using remote ejb interface instead of local ones. Netbeans 4.1 integration with SJAS 8.1 is a great improvement, it have some rough edges though. This tool flaw is also aggravated by libraries and frameworks limitations.

    Two tools I use that force too often a webapp reload with Webphere Studio are Struts and Log4j. Both when I edit config files. For Struts, I think it will be replaced by a better framework and that it is inevitable.

    It is just not clear now which framework at the moment offer a significantly better symbiose with the Web and the development. JSF dont seems to be it. HTML components would be nice. But I would prefer them in the browser, à la XUL, but I dont see it happening soon.

    AJAX getting recognition with SOA could make a successor for Struts to show up. But I dont have found one I like yet. One thing I expect is to be able leverage the HTTP protocol cache artifacts. That is one benefit of AJAX. Also, it help develop less complex and slow compiling JSP pages.

    Maybe one thing that could be improved about JSP pages, it is they could be interpreted at development time. JSP specification could mandate using beanshell since its scripts can be strongly typed. It could even be used at run time if it compile scripts to byte code like Rhino.

    While waiting for JSP and other tools to improve, XML and Zero turn around time is what made me develop more XSLT than JSP pages. XSLT is somewhat like JSP + JSTL, and if interpreted in the browser with AJAX and SOA, it makes very fast application that integrates well with Java EE applications.


    It is easy to get a heavy architecture putting all in one J2EE application. Maybe spliting things a little more often could help remove needs for so much frameworks we use now.
  144. ZTT, this is an old hat[ Go to top ]

    Its sunday and there is time to step in here. Mostly i see people highlighting the zero turnaround time. As a matter of fact, and Steve Zara pointed that out too, this is nothing new to most of us. I developed PHP and Perl long before i joined the Java camp and ZTT was just there.

    Now i dont have this feature anymore but do i think about switching back to PHP or to RoR? No, because ZTT is not really my biggest problem. We speak about 10-15 seconds container recycling with a medium sized app (if you have that more cycling time, you should chose a different dev container). Some changes can be done without cylcing at all and soon everyone will have DualCore desktop PC where you do all that stuff in the without even noticing a performance hit, so within that 15 seconds, you can do some other things in your IDE.

    I have seen RoR only on some slides and i dont think its bad, but i still think that java has to offer a lot more, especially for enterprise applications. As Bruce pointed out very well, for some DB frontend stuff, RoR is a contender to PHP. A year ago, i ve still been using PHP here and there for some mini-noncritical-applications , but now i would most likely use RoR the next time. So to me this discussion is not about Java vs. RoR, its about RoR vs. other dynamic typed languages.

    As a side note, i used a 4GL tool called "Magic" for client server development some years ago and it was so crazy fast to develop applications that i outcoded every VB or J2SE developer by a factor of 8, but the price was very high. If you left the "defined" path or needed some extra features, it was nearly impossible to get it done. Development speed can become quite irellevant, believe me.

    Marc Logemann
  145. Zero Turnaround Time is a myth[ Go to top ]

    Even for rails, you will have to restart from time to time in any oo language, as soon as you apply patterns like singletons or have session objects which can go out of state etc...
    The reason many people simply dont do this is because they are not aware of this isse and then they program against values which are totally bogus because the system state already is haywire.
    I have developed long enough to know that, and to my knowlege most java ides try to prevent server restarts as long as you do not run into those states, ufortunately there still is an issue which could be resolved differently in java.
    Introduction of new methos enforces a server restart, while it should not because the state of the system is consistent at that time, and that is in my experience the 90% case of all enforced server restarts in J2EE.

    But getting on rails and thinking, I do not need to restart the server and have zero downtime, is totally false it is just that the system does not force you to it, but in the end you might end up in a huge mess.

    A friend of mine is highly successful with applying rails, but from day one he was/is aware of that issue and that is one of the reasons why he is successful.