TSS at JavaOne 2005 - Day 3 & 4 Coverage

Discussions

News: TSS at JavaOne 2005 - Day 3 & 4 Coverage

  1. TSS at JavaOne 2005 - Day 3 & 4 Coverage (17 messages)

    Day three of JavaOne started off with an IBM keynote, and included the Brazilian presentation on annotations, and covered even more on JSF. To be sure, more happened on Day Three - Java One is always busy! In our Day 4 coverage, we looked at the case study of the Daily Planet site as well as the Web Framework Shootout.

    Read Day Three Coverage
  2. The code generation was so large that it took 13 minutes to do it all! There were a total of 543,020 classes hand-written, and 744,495 generated classes

    I take it that among these 1,287,515 classes there were 435,891 EJBs packed into that a 2GB EAR that took a total of 37 days to deploy on a 128-way HP superdome with 1TB of RAM. What about the time to precompile the 8,345,398 JSPs :o)

    Seriously guys, I was not at the session, but this is more than certainly LOC, not classes.
  3. Hi guys,

    I was one of the speakers for "Using Annotations in Large-Scale Systems...", and here are a couple of corrections about Floyd's notes on our BOF.
    Seriously guys, I was not at the session, but this is more than certainly LOC, not classes.

    Yes, Stephane, those figures are LOC, not classes - thank God. Your description of what it would be like to have that many classes will give me nightmares for the next week :-)

    The 13min generation time is correct, but our application is split into modules and no one has to build it all at once. Anyway, 3min builds for one changed class in a module weren't very productive, and that was our motivation.

    I believe that when the author said "ANT generated EJB 2.X classes..." he really meant "APT generated...". We indeed used ant 1.7's apt task to run apt, but generation credit goes to apt.

    Finally, we did NOT manage to reduce total generation time from 13min to 6s, unfortunately :-)

    Incremental builds (when only few classes have changed) are much faster now, but it still takes circa 30s to generate, compile, package, deploy, etc. depending on project/module size. The 6s figure is our best case, and refers only to the APT part of the build, when only one class changes.
  4. You guys didn't make it to the web frameworks smackdown, but went and just copied down the JSF pablum? Jeez...
  5. You guys didn't make it to the web frameworks smackdown, but went and just copied down the JSF pablum? Jeez...

    I seem to remember you skipped your slides in order to do your pitch ;-) Quite a few of us thought you did an excellent job standing up against 'true' component frameworks. But I felt you didn't emphasize the benefits of WebWork vs. putting down the other frameworks (which I admit the jabs were pretty good).

    I do think there's tons of merit within WebWork vs. the larger component frameworks (JSF, Tapestry, Wickett). If people are looking for something more refined than Struts, without the 'plugability' factor of components, then WebWork is the big winner moving forward.

    I think the JSF spec has more to learn from WebWork than it does from Tapestry.

    -- Jacob Hookom
  6. You guys didn't make it to the web frameworks smackdown, but went and just copied down the JSF pablum? Jeez...

    Ouch Jason. Of course we made it. I even stood up during the audience participation section and asked "How many active deployments do you have using your framework" and mentioned your awesome reply "Do I get to count each Google server as it's own framework". You got major points for that reply too.

    And I stand by my rankings. Webwork doesn't have a component model. HMVC is nice and gives you a greater element of reuse than does struts, but JSF and Tapestry take it to a whole nother level. Time will tell if web components prove successful. But I believe it most definitely will, and the AJAX components coming out is strong evidence of this. You'll notice that all the web frameworks were rated very closely in the technical category (all between 4.0 and 5.0).

    On the business side, Webwork also did very well. Struts was ranked higher because it's got even more deployments than webwork, even counting Google servers. And JSF is a standard with adoption by a lot more vendors than Webwork, and that will matter to an IT manager. But Webwork came in a close 3rd.

    Now, if you want to make your case as to why Webwork deserves a higher category, our readers will certainly be interested. But copy and paste, we did not. Our ratings were very carefully weighed and measured. :)
  7. Ouch Jason. Of course we made it.

    My bad, I missed the link for "Day 4"... Of course I could have been confused since it was on Wednesday and the conference opened on Monday, making it Day 3 by my count...
    And I stand by my rankings. Webwork doesn't have a component model. HMVC is nice and gives you a greater element of reuse than does struts, but JSF and Tapestry take it to a whole nother level. Time will tell if web components prove successful. But I believe it most definitely will, and the AJAX components coming out is strong evidence of this.

    Yes, we have AJAX components too, and, as we always do, we're making them easy for the developer to use rather than wrapping them in a ton of extraneous "component" stuff just to create a white-paper architecture.

    If you really think that you should base the architecture of your web app framework on the 1-5% of pages where a web component design might make things a little easier (and I'm not even sure that's true), then by all means go for it... On the other hand, if you think it's better to be dead-simple to do the 95%+ of the pages and not only possible but still pretty simple to do the 1-5%, then come check out WebWork. Reuse doesn't have to mean tool-driven, overly-complex and over-specified component development.
    And JSF is a standard with adoption by a lot more vendors than Webwork, and that will matter to an IT manager. But Webwork came in a close 3rd.Now, if you want to make your case as to why Webwork deserves a higher category, our readers will certainly be interested. But copy and paste, we did not.

    Yeah, JSP is a standard too, and yet I'm seeing more and more Velocity and FreeMarker... The problem with standards is that once it's a standard then survival of the fittest doesn't take hold quite as strongly. Poor standards survive long past their due for the trash heap...
     Our ratings were very carefully weighed and measured. :)

    Like I said above, I just missed the day 4 coverage and didn't see it there...
  8. Yes, we have AJAX components too, and, as we always do, we're making them easy for the developer to use rather than wrapping them in a ton of extraneous "component" stuff just to create a white-paper architecture. If you really think that you should base the architecture of your web app framework on the 1-5% of pages where a web component design might make things a little easier (and I'm not even sure that's true), then by all means go for it... On the other hand, if you think it's better to be dead-simple to do the 95%+ of the pages and not only possible but still pretty simple to do the 1-5%, then come check out WebWork. Reuse doesn't have to mean tool-driven, overly-complex and over-specified component development.

    I have to disagree with you here. Writing JSF applications shouldn't mean writing components new components for everything. JSF is founded on the idea of composition where I can just use objects readily available online within my applications. There are lots of open source projects starting up that provide JSF components, so they really can't be that hard to write...

    Being able to drop in an XML tag doesn't require a vendor tool, so I wish people would get off that soap crate-- *that* is dead simple, especially when JSF is backed by POJO JavaBeans. Those tools are there for MS developers, not Java developers ;-)

    -- Jacob Hookom
  9. I have to disagree with you here. Writing JSF applications shouldn't mean writing components new components for everything. JSF is founded on the idea of composition where I can just use objects readily available online within my applications. There are lots of open source projects starting up that provide JSF components, so they really can't be that hard to write...Being able to drop in an XML tag doesn't require a vendor tool, so I wish people would get off that soap crate-- *that* is dead simple, especially when JSF is backed by POJO JavaBeans. Those tools are there for MS developers, not Java developers ;-)-- Jacob Hookom

    The point was that for the vast majority of pages, the overhead and complexity introduced by JSF is RIDICULOUS. To add that for EVERY page just to accomodate the 1-5% of actually complex pages is absurd. Especially when you can go for a much lighter request/response model and handle those pages simply, and also be able to handle the more complex pages without much fuss...
  10. The point was that for the vast majority of pages, the overhead and complexity introduced by JSF is RIDICULOUS. To add that for EVERY page just to accomodate the 1-5% of actually complex pages is absurd. Especially when you can go for a much lighter request/response model and handle those pages simply, and also be able to handle the more complex pages without much fuss...

    I will give you that. The overhead isn't that substantial though. Felipe Leme gave a talk on MVC bottlenecks and the throughput of JSF vs Struts only differed by about 5%. They said they expected there to be a bigger difference, but their really wasn't. Since coming back from JavaOne, I've been working on lots of short circuiting within the JSF-API/Impl guts to remove a good deal of memory overhead. I believe these upcoming releases should show a much smaller gap between JSF and Struts/WebWork. As for JSP and JSF, there are alternatives that have a smaller memory footprint like velocity <plug>Facelets</plug>.
  11. I will give you that. The overhead isn't that substantial though. Felipe Leme gave a talk on MVC bottlenecks and the throughput of JSF vs Struts only differed by about 5%. They said they expected there to be a bigger difference, but their really wasn't. Since coming back from JavaOne, I've been working on lots of short circuiting within the JSF-API/Impl guts to remove a good deal of memory overhead. I believe these upcoming releases should show a much smaller gap between JSF and Struts/WebWork. As for JSP and JSF, there are alternatives that have a smaller memory footprint like velocity <plug>Facelets</plug>.

    There's processing overhead and then there's the conceptual overhead from framework complexity and over-engineering. Just because a tool lets you get it set up easily the first time doesn't mean your abstraction won't leak and you won't end up having to look under the covers...
  12. Spell Check[ Go to top ]

    I think you better spell check your articles before posting them. For a respected site as TSS, it does not go very well to have lots of typos in there.....

    Peace \/ .....
  13. the smackdown was great[ Go to top ]

    I attended the smackdown and thought it was fantastic. I've been really impressed with Tapestry and Wicket. But especially with Wicket since it strives to allow you to write just simple java code with no JSP. If you are not big on JSP and have done event driven GUI programming, and are not stoked on a zillion config files, you are pretty likely to enjoy wicket programming. the dowsnide of course is that it is so new.
  14. Component frameworks are the next generation (they should have been the first generation). Now waiting for really rich web clients (like flash or similar) to become the norm.

    Wanted to replace our Struts standard. Webwork is a natural improvement over Struts but still not a component framework which I have always believed is the natural way to build any UI.

    First went for JSF to replace our Struts standard - its got some great concepts but a beast to work with - had to drop it.

    With much hesitation (cause: HLS @ my BOF) I am now investigating Tapestry. I have to admit its got all the right ideas. Had trouble with little things that the docs don't seem to cover but the concepts overall are easy and straightforward. It seems to have everyting including templates (like Tiles) built under the single unifying concept of a Component - very elegant - and the components seem very easy to create. I have a feeling HLS has the next big hit. Still trying to do a complex usecase before a decision.
  15. JSF Complex?[ Go to top ]

    I must admit, I find the statements that JSF is "complex" or a "beast" really puzzling. From my experience, I have found it very straight forward and simple. POJOs for view-helpers, powerful yet simple components, easy to use validation, and straight forward navigation.

    The places where I find a bit of complexity really is in some of the example components people have written. But those are components people have written, not JSF. So I come back to the question... where are people finding JSF to be a beast to work with? Is it just the learning curve or is there more to it that's truely complex?
  16. JSF Complex?[ Go to top ]

    The component framework itself is nice. The page authoring is really the beast. Not easy to take a piece of HTML and quickly make it reuseable e.g. a border or a login form. Not easy to mix HTML in with the JSF tags and not easy to work with HTML wysiwig editors or preview your pages as you create them.
  17. JSF Complex?[ Go to top ]

    The component framework itself is nice. The page authoring is really the beast. Not easy to take a piece of HTML and quickly make it reuseable e.g. a border or a login form. Not easy to mix HTML in with the JSF tags and not easy to work with HTML wysiwig editors or preview your pages as you create them.

    http://facelets.dev.java.net
  18. oh is it over?[ Go to top ]

    Maybe it’s me, maybe its Java maturing, but it seems to me that the JavaOne, that I used to look forward to all year, has passed this year without raising much interest at all?