Carlos Perez: Top Five Java Technologies to Learn in 2008

Home

News: Carlos Perez: Top Five Java Technologies to Learn in 2008

  1. Carlos Perez has posted his list of the top five Java-based technologies to learn in 2008. They are:
    • OSGi (a specification for dynamic modules for Java)
    • The Java Content Repository spec, first appearing in the JCP in February 2002
    • Google Web Toolkit (first released in May, 2006)
    • Groovy (first released in May, 2004)
    • Cloud computing (a concept designed around the use of virtual servers, or distributed computing without the use of EJB)
    It's interesting that these are older technologies that are, perhaps, "coming of age" and have now matured to the point where they're recommended. Certainly, all of these technologies are useful: OSGi is the module system behind Eclipse, Groovy is gaining acceptance with its formal specification and continually improved releases, GWT is also fairly mature and stable, and cloud computing is becoming more accepted in the wider marketplace. JCR and cloud computing are probably the least-accepted of these technologies, and vendors in both spaces are trying to address that, with competitions to spur awareness or active community involvement (see GridGain, Gigaspaces, or Terracotta), or plans for them (watch TSS for an announcement around JCR at TSSJS 2008.) It's an interesting list. What would you put on your own list of the top five Java technologies to learn for 2008? What technologies are emerging right now that you think will appear on a future version of this list?

    Threaded Messages (132)

  2. Any RIA (Rich Internet Application) I like GWT as it gives you strongly typed Javascript like Java gave us managed code Prereqs: Spring Maven Hibernate
  3. I wrote about how I used it to make a message bus. It's holding up well in our preliminary testing. The best part about it is the pure POJO model. We can run the whole "grid" in our IDE during development, then TC can run it on a whole cluster without a single line of code changing. POJOs go wide with Terracotta. Read about it here: http://blog.markturansky.com/archives/26
  4. GWT. I don't disagree with the other entries of the list. They are nice. But GWT is truly ground braking and disruptive technology. I'm betting my career on GWT, and guessing that 5 years from now vast majority of front end development is done in GWT, or it's imitations, while server side web frameworks are only a Dark Memory, and a healthy reminder how our mind was limited and we did not Understand. /Henri Karapuu
  5. GWT Server Side[ Go to top ]

    Is there any solution yet to ease the server side coding of GWT, or still we have to write servlets ...?
  6. What's so difficult about writing server side code for GWT. It leaves the options pretty much open for you. You can use RPC or web services with JSON... am I missing something in the complexity department?
  7. Re: GWT Server Side[ Go to top ]

    Is there any solution yet to ease the server side coding of GWT, or still we have to write servlets ...?
    Yes, the server side of RPC was opened up, and currently numerous ready made integrations, including direct bridging to Spring exists. /Henri Karapuu
  8. Re: GWT Server Side[ Go to top ]

    Is there any solution yet to ease the server side coding of GWT, or still we have to write servlets ...?
    Did you check gwt-sl library? If not go and get it here . Once you extract the library, go to docs folder and read the reference. You can expose a POJO as RPC service, the nuances will be taken care by gwt-sl library. Adi
  9. Bad luck[ Go to top ]

    Bad luck Henri Echo 2 pans GWT goodstyle ;) Most people I know lost interest in Groovy last year Was this the just out of fashion list cheers Rob
  10. Best Of Luck![ Go to top ]

    Best Of Luck!
  11. Paul Beckford[ Go to top ]

    Hi, I'm Paul Beckford and I think the top 5 Java Technologies in 2008 should be: 1) Ruby 2) Ruby on Rails 3) Ruby 4) Ruby on Rails 5) Ruby
  12. Re: Paul Beckford[ Go to top ]

    Hi, I'm Paul Beckford and I think the top 5 Java Technologies in 2008 should be:

    1) Ruby
    2) Ruby on Rails
    3) Ruby
    4) Ruby on Rails
    5) Ruby
    you can try Grails. It's Groovy, it's Java and its inspired by RoR
  13. Re: Paul Beckford[ Go to top ]

    Hi, I'm Paul Beckford and I think the top 5 Java Technologies in 2008 should be:

    1) Ruby
    2) Ruby on Rails
    3) Ruby
    4) Ruby on Rails
    5) Ruby
    That's soooooooo 2007. The real Paul Beckford can't support any technology that actually has any level of real adoption, and thus Ruby is now popular enough to have joined the "it must suck because it's popular" category. ;-) Peace, Cameron Purdy Oracle Coherence: The Java Data Grid
  14. ROTF[ Go to top ]

    oh man, that gave me a good laugh. Thanks for the humor.
  15. 2008 Wishlist[ Go to top ]

    Mine is more a wishlist for 2008 :) - Scala - Terracota - OSGi
  16. Re: Paul Beckford[ Go to top ]

    Hi, I'm Paul Beckford and I think the top 5 Java Technologies in 2008 should be:

    1) Ruby
    2) Ruby on Rails
    3) Ruby
    4) Ruby on Rails
    5) Ruby


    That's soooooooo 2007. The real Paul Beckford can't support any technology that actually has any level of real adoption, and thus Ruby is now popular enough to have joined the "it must suck because it's popular" category. ;-)

    Peace,

    Cameron Purdy
    Oracle Coherence: The Java Data Grid
    How did you guys guess? I hope to make 2008 a Java free zone :). I didn't realise I was famous, I guess must have touched a nerve. Seriously I've been posting on TSS about the advantages of dynamic languages long before Rails. If you guys check my first posts complained about the lack of OO understanding amongst Java developers and that Smalltalk is a much better OO language. I taught myself Smalltalk back in 1992 because I was struggling to understand OO with C++. I have never looked back and it has made me a much better Java programmer. I still think that even today most Java programmers don't get OO and I think the hybrid nature of the language is partially to blame for this. Anyway, I don't mind the fame, but I would much prefer you guys debate the ideas. Believe me, the ideas are a lot more interesting! Chow P.
  17. Re: Paul Beckford[ Go to top ]

    Anyway, I don't mind the fame, but I would much prefer you guys debate the ideas. Believe me, the ideas are a lot more interesting!

    Chow

    P.
    I'm just joking around. I find many of your posts come from an interesting point of view, and I enjoy different points of view. That said I guess sometimes I do get a little annoyed sometimes with the amount of Ruby rings you wear on your fingers, and the fact that you do seem to genuinely not like Java or companies develop Java products. I personally enjoy developing in many different languages, Ruby being one of them, and participate in many different forums. But for example I dislike Visual Basic, and on that note you wont see me in VB forums trying to non constructively compare VB's weak points other languages. To each his own...
  18. Re: Paul Beckford[ Go to top ]

    But for example I dislike Visual Basic, and on that note you wont see me in VB forums trying to non constructively compare VB's weak points other languages.

    To each his own...
    Fair point. I don't think I dislike Java per se. After about 11 years doing not much else but Java, I'm a bit board of it. The thing I dislike though is not having a choice. Java is "MAINSTREAM" (in capitals). And a long with mainstream comes a certain culture. Most Java shops would not consider using anything other than Java. We have a perfectly working Perl App (a customized Bugzilla Application actually) and Strategy are insisting that we re-write it in Java. This is what I hate. Java as eclipsed many good languages such as Smalltalk, Beta, Eiffel and Delphi. Meaning that many people from these backgrounds find themselves writing Java applications not by choice but through necessity. Years of building 3-tier, Application Server based (Weblogic), Web Apps. Using Struts, EJB, JDBC whether the application merited the use of all this or not, this is what I hate. Now the answer to everything seems to be Spring/Hibernate whether it merits it or not. I guess its the culture that I have grown to dislike. It wasn't like this at the beginning (1997). Java was fresh and new and new ideas were welcomed (remember the JavaStation, JINI, and JavaSpaces?). Now though it is all about marketing, products, strategy, pseudo standards, backward-compatibility at all costs and commercial open source pretending to be "community spirited". Ruby is new and fresh (and old at the same time), built on better fundamentals and has all the zeal Java use to have. In my opinion it also has a healthier community which has learnt from the mistakes of earlier communities such as Smalltalk and Java. With any luck it will stay that way and not succumb to the same fate. I guess you are right, mainstream doesn't suite me. Paul.
  19. Re: Paul Beckford[ Go to top ]

    Maybe I have cut you to the quick. I agree with a lot of what you just said. I too frown when I have to spend time rewriting an app in Java that is supportable and works perfectly fine as is, just because the powers at be demand everything Java. I also have running joke with one of my fellow programmer where we set a timer and see how long it takes for one of the other devs to say "spring/hiberate" when our group starts talking about the design of a new application. So far the timer has never ran more then one minute, and Spring/Hibernate is almost always the default assumption, no matter what the problem is. Oh and I just love deploying a 30mb war with 200+ lines of xml, 30 java classes, 40 unit tests just to provide a CRUD web front end for 5 tables. Sometimes I feel that I will never be able to wash off the blood of the thousand goats I have sacrificed to the Gods of Java Architecture. On the other hand I do feel like Java is a very good general purpose language, and there are some problems I feel it solves very well. I also think the Java community is still a great community to be a part of. Sure things are slowing down, but I'm fine with that. When it comes down to it I get my satisfaction from completing applications, as opposed to learning 5 new frameworks every month. I have also had my share of issues in the Ruby community. I was looking into taking a Ruby side job the other day, but was told after the interview that even though they were very happy with my skills and experience I was not "a believer". This was based on the fact that I was bringing up area's where JRuby and java could used leverage the existing Java business logic that they already had. I would have rewritten the app in Ruby if that is what they wanted, but just by pointing out that it was not necessary my consideration was removed. My feeling is that religious people are religious irregardless of the religion. I wish there were more technical atheists out there.
  20. Re: Paul Beckford[ Go to top ]

    Oh and I just love deploying a 30mb war with 200+ lines of xml, 30 java classes, 40 unit tests just to provide a CRUD web front end for 5 tables. Sometimes I feel that I will never be able to wash off the blood of the thousand goats I have sacrificed to the Gods of Java Architecture.
    You can rid yourself of the xml, the unit tests and some of the classes. It is hard to par down the jars. I use NHibernate and jar (dll) wise it is much lighter. Even for a 5 table app, I can crank it out pretty quick with this setup. I've done plenty of SQL by hand so I have lots to compare it against. On the other hand, if you use Ruby (or any DL) you had better have TONS more unit tests than that.
  21. Re: Paul Beckford[ Go to top ]

    On the other hand I do feel like Java is a very good general purpose language, and there are some problems I feel it solves very well. I also think the Java community is still a great community to be a part of. Sure things are slowing down, but I'm fine with that.
    There are a lot of "Java developers" that don't know how to write an Java outside of a particular framework. I've interviewed so many who couldn't describe the basic features of the language. These frameworks have overshadowed the language. First it was EJB, now it's Spring and Hibernate. I don't think that Java is a perfect language by a long shot but it's practical and knowing it pays the bills. But it's definitely frustrating to work with so many people who don't know how to connect to a DB without a JNDI bound pool or can't test their code without deploying it in WebSphere etc. I had a rookie who wanted to take his first Java course on SAAJ, JAXB and all of those extra chromosomes. If I had a lighter I might have set the catalog on fire.
  22. Re: Paul Beckford[ Go to top ]

    How did you guys guess? I hope to make 2008 a Java free zone :).
    I personally think that the people in the Java community that challenge common beliefs in a constructive way make it a lot stronger. I could be wrong but I would be surprised if there were Perl developers constantly touting the value of static typing on Perl discussion boards. I don't always agree with you but you definitely made me think about my assumptions.
  23. Re: Paul Beckford[ Go to top ]

    The real Paul Beckford can't support any technology that actually has any level of real adoption, and thus Ruby is now popular enough to have joined the "it must suck because it's popular" category. ;-)

    Peace,

    Cameron Purdy
    Oracle Coherence: The Java Data Grid
    Oh, I fear I will need to have a good look at coherence now that you mention it :-).
  24. Re: Paul Beckford[ Go to top ]

    The real Paul Beckford can't support any technology that actually has any level of real adoption, and thus Ruby is now popular enough to have joined the "it must suck because it's popular" category. ;-)

    Peace,

    Cameron Purdy
    Oracle Coherence: The Java Data Grid


    Oh, I fear I will need to have a good look at coherence now that you mention it :-).
    Wait for the Ruby version ;-) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  25. Beckford[ Go to top ]

    Lol, so so true.
  26. I dont agree with you.[ Go to top ]

    This are techs to be learned in 2005 ... you should know them by heart right now. ;) anyway this is Java techs post, so you should have said jruby and jruby on rails... :) regards.
  27. Re: Paul Beckford[ Go to top ]

    Do you like a FULL-STACK solution like Rails? Really easy, don't make me think about anything? Try Mentawai! http://www.mentaframework.org http://book.mentaframework.org http://recipes.mentaframework.org
  28. On JCR and Sling[ Go to top ]

    Joe, my take on the JCR bit: you are right that JCR has been around for a while. However, I think that there is a good reason for Carlos putting it onto his list. Java Content Repositories allow for ad-hoc storage of unstructured content. Not having to structure your content up-front is something that is getting interest just recently (see Amazon's SimpleDB or CouchDB - I wrote a bit about this on our blog). Cheers Michael (Disclaimer: I work for Day software) http://dev.day.com
  29. Re: On JCR and Sling[ Go to top ]

    Joe, my take on the JCR bit: you are right that JCR has been around for a while. However, I think that there is a good reason for Carlos putting it onto his list. Java Content Repositories allow for ad-hoc storage of unstructured content. Not having to structure your content up-front is something that is getting interest just recently (see Amazon's SimpleDB or CouchDB - I wrote a bit about this on our blog).

    Cheers
    Michael (Disclaimer: I work for Day software)
    http://dev.day.com
    I think I have a project for JCR. Still trying to wrap my head around how it will fit in. Been using databases for too long. :) Do you have some good links to examples? I've read most of what I can find (jackrabbit site). I think I need to use both the database (for lists of values, security, etc) and the jcr so i that is what I am working through.
  30. Re: On JCR and Sling[ Go to top ]

    Mark, I am just about to set up a wiki on this (find the link collection below to get you started). It takes a bit of "forgetting what you know" if you move from relational modeling to a JCR approach. I find "David's Model" helpful for structuring content. Also: if you find yourself mentally translating db tables into a JCR data model you are probably not leveraging what a JCR can do for you. I cannot comment on your specific project, but the example reasons you give for using a db (lists of values, security) are quite well covered in a JCR. In fact, you can have granular access rights for each node in a JCR (having this in a db on row-level is not so common). A good place to ask questions about modeling or architecture is the Jackrabbit mailing list. If you want to contact me directly find my mail address in the footer of http://dev.day.com. Finally, I find Day's CRX easier to use for newbies than Jackrabbit. Reason: there is a web-based Explorer app included in the distribution so you can see what goes on in your repository or play around without having to set up anything (sorry, if this sounds like blatant marketing. It is my honest opinion) Cheers Michael Overview articles JCR Overview by Tom Wheeler (7/10/2007) JCR:A practicioner's perspective on TheServerSide What's the point of JCR? by Florent Guillaume (18/10/2006) Catching up with the Java Content Repository on InfoQ JSR 170: A standard content repository on Introducing the Java Content Repository API on developerWorks Catch Jackrabbit and the Java Content Repository API on Artima JSR-170: What's in it for me? JSR 170: Overview - Standardizing the Content Repository Interface by Roy Fielding Tutorial articles Advanced Java Content Repository API What is Java Content Repository Introductory videos Java Content Repository TheServerSide Tech Brief (13/6/2007) JCR screencast Presentations JCR in Action Content Management with Apache Jackrabbit by Jukka Zitting Intoduction Jackrabbit by Jukka Zitting
  31. Re: On JCR and Sling[ Go to top ]

    I cannot comment on your specific project, but the example reasons you give for using a db (lists of values, security) are quite well covered in a JCR. In fact, you can have granular access rights for each node in a JCR (having this in a db on row-level is not so common).
    Is it possible to build a JCR repository backed by SVN or CVS or does that just not make any sense? I can't seem to find information about whether this is something that could be done or is a known dumb idea.
  32. Re: On JCR and Sling[ Go to top ]

    James, have a look here: http://www.mail-archive.com/jackrabbit-dev at incubator dot apache dot org/msg03251.html My understanding is that: JCR on top of SVN would be doable but has not been done, JCR on CVS would not be doable (due to the way versioning works) and that the most sensible thing seems to be SVN on top of JCR (but has not been done to my knowledge). (but if you want to get a more reliable answer to this I suggest to ask on the Jackrabbit list) Why do you want to do this? Cheers Michael
  33. Re: On JCR and Sling[ Go to top ]

    James,

    have a look here:

    http://www.mail-archive.com/jackrabbit-dev at incubator dot apache dot org/msg03251.html

    My understanding is that: JCR on top of SVN would be doable but has not been done, JCR on CVS would not be doable (due to the way versioning works) and that the most sensible thing seems to be SVN on top of JCR (but has not been done to my knowledge).
    (but if you want to get a more reliable answer to this I suggest to ask on the Jackrabbit list)

    Why do you want to do this?

    Cheers
    Michael
    Honestly, I just seems like the right thing to do but it's absolutely possible that it's just that I don't 'get it'. I'm looking at Mule Galaxy and a lot the stuff that we would put in the repository are resources that are part of deployed applications (like schemata, for example). We require that all parts of an application are in source control. It seems to me that some of the capabilities of JCR overlap with source control, such as versioning. But there are a lot of other things that we need to put in Source Control that I would not put in Galaxy. Instead of trying to come up with some klunky way of keeping these in sync or having two separate respositories, it seems to me that it would be optimal to just use a single backend repository for our source and Galaxy (or similar system.) Maybe I'm just viewing JCR through the lens of my previous experience and not understanding something. If that's the case, anything you do to clear that up would be appreciated.
  34. James,

    have a look here:

    http://www.mail-archive.com/jackrabbit-dev at incubator dot apache dot org/msg03251.html

    My understanding is that: JCR on top of SVN would be doable but has not been done, JCR on CVS would not be doable (due to the way versioning works) and that the most sensible thing seems to be SVN on top of JCR (but has not been done to my knowledge).
    (but if you want to get a more reliable answer to this I suggest to ask on the Jackrabbit list)

    Why do you want to do this?

    Cheers
    Michael


    Honestly, I just seems like the right thing to do but it's absolutely possible that it's just that I don't 'get it'.

    I'm looking at Mule Galaxy and a lot the stuff that we would put in the repository are resources that are part of deployed applications (like schemata, for example). We require that all parts of an application are in source control. It seems to me that some of the capabilities of JCR overlap with source control, such as versioning. But there are a lot of other things that we need to put in Source Control that I would not put in Galaxy. Instead of trying to come up with some klunky way of keeping these in sync or having two separate respositories, it seems to me that it would be optimal to just use a single backend repository for our source and Galaxy (or similar system.)

    Maybe I'm just viewing JCR through the lens of my previous experience and not understanding something. If that's the case, anything you do to clear that up would be appreciated.
    Actually security is very easy to set up using SpringAcegi. Our SOA has two main conceptual entry points: One is BlazeDS servlet and the other is a Spring controller (for conventional HTTP POST/GET/PUT interactions). Of course could establish multiple controllers via Spring. SpringAcegi security guards the front side via an HTTP filter and URL patterns. This guards both Spring controllers and BlazeDS servlet. Then on the backside, where Spring POJO beans are dispatch to from BlazeDS or the Spring controller, method granularity security is applied by SpringAcegi (there's typically a many-to-one relationship of methods to URL patterns on the front-side). It's clean, AOP-based, and quite straightforward to set up.
  35. Re: On JCR and Sling[ Go to top ]

    James, your requirements are just fine. Putting all application resources into version control makes a lot of sense. This is actually what we do with our JCR-based CMS product Communique (since a couple of years already). All code (e.g. templates) and content is in the same repository. The same approach is used in Apache Sling (a web framework for JCR backends). All scripts are stored in the repository along with the content. However, in oder to access the scripts with e.g. an editor at the moment WebDAV needs to be used. This means that you do not have the classic svn/cvs workflow check-out/local-workspace/commit. We are currently working on a product that allows to do this but there is nothing released yet. Therefore, so far there are certainly setups where you cannot really get around having to put some data in svn and some in a JCR. Unfortunately. (I should say that I do not Mule Galaxy well enough - maybe they got some other solution) HTH Michael
  36. Re: On JCR and Sling[ Go to top ]

    I cannot comment on your specific project, but the example reasons you give for using a db (lists of values, security) are quite well covered in a JCR. In fact, you can have granular access rights for each node in a JCR (having this in a db on row-level is not so common).
    Thanks Michael. That helps answer some questions. I will need very granular security. What i mean about lists and security where just Pick List values and authentication (groups etc) - basically Metadata about how to use the JCR or what to apply it. The actual info would be in the JCR. I'll look the links and your CRX. I certainly don't mind paying for good products that add value. I am sort of building a field of dreams though right now though. The products that currently do what i am working on use RDBMS 100%. And they don't function that great.
  37. Re: On JCR and Sling[ Go to top ]

    Mark, if you put your content/data and your access rights into the repository you can take full advantage of the infrastructure it provides. For example, searches take into account user read rights. This does not necessarily mean that you manage user, groups and rights in the repository itself. It might well be an LDAP server connected to the repository. The separation between data and meta data is somewhat artificial. After all, everything is content. Cheers Michael
  38. Re: On JCR and Sling[ Go to top ]

    Mark,

    if you put your content/data and your access rights into the repository you can take full advantage of the infrastructure it provides. For example, searches take into account user read rights.

    This does not necessarily mean that you manage user, groups and rights in the repository itself. It might well be an LDAP server connected to the repository.

    The separation between data and meta data is somewhat artificial. After all, everything is content.

    Cheers
    Michael
    Ok. Thx. We probably should talk offline. I think i am not making myself clear. :) Or just missing something.
  39. Re: On JCR and Sling[ Go to top ]

    sure. you can reach me at mmarth (at) day (dot) com. Cheers Michael
  40. Re: On JCR and Sling[ Go to top ]

    sure. you can reach me at mmarth (at) day (dot) com.
    Cheers
    Michael
    I will be. I was trying to read more last night. Not sure things got much clearer. Thx!
  41. JBoss Seam[ Go to top ]

    "What technologies are emerging right now that you think will appear on a future version of this list?" JBoss Seam of course. It's the most interesting web application/integration framework in the Java world right now.
  42. Re: JBoss Seam (YES)[ Go to top ]

    +1 JBoss Seam is number 'UNO' (together with EJB3/JPA/Hibernate, JSF and AJAX).
  43. 2008 for me...[ Go to top ]

    • Wicket (!!)
    • Terracotta
    • Spring Dynamic Modules
    I really prefer using Wicket over GWT currently. But as a sidenote, I'm also going to study GWT more, because my experience with it are pretty slim, so I can't really judge/compare yet.
  44. All but GWT are on my list. My "replacement" for that is RAP. I have started on all these last year so maybe I need to pick another 5. :)
  45. All but GWT are on my list.
    Just curious, what is wrong with GWT? /Henri Karapuu
  46. All but GWT are on my list.


    Just curious, what is wrong with GWT?

    /Henri Karapuu
    One item that I haven't come up with a good solution for yet is bridging the Hibernate lazy instantiation gap with GWT. I've tried hibernate4gwt, but it isn't quite what I want. Also, if you want to display a table with hundreds of row, the client-side rendering is a problem. We had a customer who didn't want pagination. Server-side JSPs could handled the same thing without issues. Drag and Drop really needs to be moved up the priority list and made a first class available object. And Generic support in the client. For the most part, the technology is awesome.
  47. All but GWT are on my list.


    Just curious, what is wrong with GWT?

    /Henri Karapuu


    One item that I haven't come up with a good solution for yet is bridging the Hibernate lazy instantiation gap with GWT. I've tried hibernate4gwt, but it isn't quite what I want.

    Also, if you want to display a table with hundreds of row, the client-side rendering is a problem. We had a customer who didn't want pagination. Server-side JSPs could handled the same thing without issues.

    Drag and Drop really needs to be moved up the priority list and made a first class available object.

    And Generic support in the client.

    For the most part, the technology is awesome.
    You can still use a HTML() Widget and put a "big table" in that. In general, we COULD have 20,000,000 rows, so we have to institute paging. There a hard limit on when any browser would do with tens of thousands of rows in a table. They mostly DIE. ;-)
  48. Being a RIA developer I prefer going with any RIA technology like Nexaweb, Adobe Flex, Echo 2. I am not completely against GWT because it some how maps to coding in Java Swing. Hope they will able to break out of the browser dependency issues they have. I have seen few GWT projects where UI developers struggle to fix these Browser dependencies issues like focus management etc... If someone is thinking GWT is completely browser independent, God save them :) / Google save them?? ;) At least with RIA tools we have to just worry about the UI L&F and functionality, not much (none) about which browser its running on.
  49. One item that I haven't come up with a good solution for yet is bridging the Hibernate lazy instantiation gap with GWT. I've tried hibernate4gwt, but it isn't quite what I want.
    Agreed. As Javascript is single threaded and RPC requests to server are asynchronous the transparent lazy loading of properties is AFAIK simply not possible. Actually I'm working right now to bring data binding framework to GWT, which can handle also lazy loading in common situations. This should help a bit.
    Also, if you want to display a table with hundreds of row, the client-side rendering is a problem. We had a customer who didn't want pagination.
    Yes, this is another major deficiency of GWT -- Javascript is couple of orders of magnitude slower, and DOM manipulation in particular is butt slow. Not because of GWT, but because of how things are beneath the hood.
    Drag and Drop really needs to be moved up the priority list and made a first class available object.
    There is very nice 3rd party drag and drop project, which i believe is making it's way to core GWT. See http://code.google.com/p/gwt-dnd/
    And Generic support in the client.
    SVN trunk contains full support for JDK 1.5, my guess is that public milestone release with JDK 1.5 support is coming in a week or two. /Henri Karapuu
  50. All but GWT are on my list.


    Just curious, what is wrong with GWT?

    /Henri Karapuu
    Nothing. But of the 3 billion java web app frameworks others fit better with what I plan on doing this year. Not saying it won't end up on my list by EOY. Or next Year. :)
  51. GWT is the EASIEST thing I have ever programmed 'Web Applications' in, and a would HATE to have to go back to Struts, JSF, Echo2, Wicket, etc... and GWT has GWT-RPC, which is very low overhead/bandwidth. It's slick beyond slick. And have been doing this kinda thing for, well, since we first used .shtml and CGI. Blech. Using more Groovy on the server side now tho ( Compiled ), which is nice. Definitely looking at GigaSpaces. And it will be a cold day in "H E Double Chopsticks" when the major financial institution I work for lets us deploy a RAILS app.
  52. GWT is the EASIEST thing I have ever programmed 'Web Applications' in, and a would HATE to have to go back to Struts, JSF, Echo2, Wicket, etc...
    You didn't even try Echo 2 and Wicket or they wouldn't be in your same list.
  53. In all fairness gwt is way easier to pick up than wicket is. Though i realy like both frameworks.
  54. In all fairness gwt is way easier to pick up than wicket is. Though i realy like both frameworks.
    I think there is difference between "able to pick it up" and "able to make exactly what designer/business requires and in a way that does not want you to vomit"
  55. In all fairness gwt is way easier to pick up than wicket is. Though i realy like both frameworks.


    I think there is difference between "able to pick it up" and "able to make exactly what designer/business requires and in a way that does not want you to vomit"
    I would say so. In fact, for our first app, I took over the design. The person was too used to web design. We put in Horizonalsplitters, menus, pop-up dialogs(for things like settings), autofill, the works...
  56. my 5 coins[ Go to top ]

    promising Java Technologies: Hibernate (ORM persistence) Spring (DI, clue and more) GWT (web) AspectJ (for AOP) Maven (build system) waist of time of Java Technologies: Portlets (aka JSR 168) - seems it's dead EJB - I wounder who will believe to those who managed to create such ugly thing three times in a row? JPA - because it is cut version of Hibernate or TopLink (depends on what you prefer) JSF - because it's complex, over engineered and doesn't fit web2.0 needs SEAM - because it's based on JSF, EJB and JPA ;-) Regards, Vitaliy S
  57. Re: my 5 coins[ Go to top ]

    waist of time of Java Technologies:
    ...
    SEAM - because it's based on JSF, EJB and JPA ;-)
    This hasn't been true for a while - you can deploy Seam to Tomcat (no EJB at all); we've had support for hibernate without JPA since Seam 1.1; and Seam is independent of JSF as of Seam 2.0 - as Eelco mentions we are currently working on examples of using Wicket as the presentation layer. (and yes, of course I'm biased as I work on Seam)
  58. Re: my 2 cents[ Go to top ]

    waste of time Java Technologies of the year:
    ...
    SEAM - because it's based on JSF, EJB and JPA ;-)


    This hasn't been true for a while - you can deploy Seam to Tomcat (no EJB at all); we've had support for hibernate without JPA since Seam 1.1; and Seam is independent of JSF as of Seam 2.0 - as Eelco mentions we are currently working on examples of using Wicket as the presentation layer.
    Can you use SEAM in Tomcat or Jetty without JBoss Embedded(If not, what is the difference between using JBoss with Tomcat or Tomcat with JBoss ;-) )? Can you use bijections and conversations inside Tomcat (without JBoss Embedded)? Is it possible to use JTA in SEAM on Tomcat? What are benefits of SEAM without JSF? Can you do bijection with GWT controls? any examples?
    (and yes, of course I'm biased as I work on Seam)
    It seems evident to me. Seems only SEAM developers and instructors advocate for SEAM on TSS (If you read this thread carefully you'll find out that those who tried Tomcat,Spring,GWT,Hibernate will never go to JBoss,SEAM,JSF,EJB). I hope being RedHat devision JBoss won't go back to it's old tricks.
  59. GWT vs. Wicket[ Go to top ]

    Does anyone know of a good side-by-side comparison of GWT and Wicket. These are the two Java web-frameworks I am interested in. I've worked a little with Wicket and I suppose I should look at GWT now.
  60. Re: GWT vs. Wicket[ Go to top ]

    Does anyone know of a good side-by-side comparison of GWT and Wicket. These are the two Java web-frameworks I am interested in. I've worked a little with Wicket and I suppose I should look at GWT now.
    I'm not sure if it is really valid to compare GWT to any of the HTML mark-up frameworks. The approaches are simply add odds, IMO. If you want to do any mark-up, jsf, wicket, struts2, spring mvc, or say stripes would be a like comparison. But if you want to code in java, then GWT or Echo2 would be more an interesting comparison. The biggies to me in GWT is you do it in java. Right now, I'm doing some work on an app that has a fairly heavy Javascript front-end. I basically drew the short straw. I've never done this much JS before and I don't really enjoy it. All the benefits of Idea, refactoring, navigation, DEBUGGING(having to use FF and Venkman isn't the same) are gone. In fact, take a look at Instantiations GWT Designer. I don't care for Eclipse,but this is an excellent plugin. I did our entire front-end via Drag-and-drop and just then had Java code that I could manipulate it in Idea to my sense of asthetics. The code is usable, but not clean. Being able to debug the app from GWT front-end to deep in the business objects, throught AOP interceptors, all the way to Hibernate POJOs is unbeatable. And try making a component in GWT...simply put THEY GOT IT RIGHT! I had one of my junior guys create a EditableLabel, a label that when clicked, becomes a text box. Extend Composite, add Label and TextBox as fields, a couple of listeners and done. Quickly. It is very easy to put together all manner of interesting things. Give it a look.
  61. Re: GWT vs. Wicket[ Go to top ]

    Does anyone know of a good side-by-side comparison of GWT and Wicket. These are the two Java web-frameworks I am interested in. I've worked a little with Wicket and I suppose I should look at GWT now.


    I'm not sure if it is really valid to compare GWT to any of the HTML mark-up frameworks. The approaches are simply add odds, IMO.

    If you want to do any mark-up, jsf, wicket, struts2, spring mvc, or say stripes would be a like comparison.

    But if you want to code in java, then GWT or Echo2 would be more an interesting comparison.
    You may be absolutely correct in your assertion for all I know but are you familiar with Wicket? It does involve HTML markup but this is very minimal. It seems to me that the main purpose for the HTML is to allow a web-designer make things pretty while knowing almost nothing about Java or Wicket. GWT compiles into client-side Javascript, correct? Doesn't that mean you need to be careful about what you put in your code? Not that this is a deal-breaker, it just occurred to me in reading this thread.
  62. Re: GWT vs. Wicket[ Go to top ]

    Does anyone know of a good side-by-side comparison of GWT and Wicket. These are the two Java web-frameworks I am interested in. I've worked a little with Wicket and I suppose I should look at GWT now.


    I'm not sure if it is really valid to compare GWT to any of the HTML mark-up frameworks. The approaches are simply add odds, IMO.

    If you want to do any mark-up, jsf, wicket, struts2, spring mvc, or say stripes would be a like comparison.

    But if you want to code in java, then GWT or Echo2 would be more an interesting comparison.


    You may be absolutely correct in your assertion for all I know but are you familiar with Wicket? It does involve HTML markup but this is very minimal. It seems to me that the main purpose for the HTML is to allow a web-designer make things pretty while knowing almost nothing about Java or Wicket.

    GWT compiles into client-side Javascript, correct? Doesn't that mean you need to be careful about what you put in your code? Not that this is a deal-breaker, it just occurred to me in reading this thread.
    I'm not saying that one is better than the other and no, I haven't tried Wicket. I have read about it, however, I feel pretty confident in saying it is similar to a variety of mark-up frameworks ala, JSF, Stripes, etc in basic usage. GWT is different. Radically different. I'm not sure what you mean by "careful." GWT is used for the presentation tier only. It provides a subset of Java 1.4 and that subset is directly debugging, refactorable, inherit-able(?) in all the ways that even minimal mark-up isn't. I was able to easily turn a Struts/Spring/Hibernate app into a GWT/Spring/Hibernate application. If your app is designed with a separate presentation tier, you wouldn't have to be careful about much in GWT, IMO. If you know Swing, or the be frank, done any gui development(or event driven), GWT poses little technical hurdles, again, IMO. GWT is used to create web apps that look like desktop apps. In this system, a web designer is as useful as he is in a desktop application.
  63. Re: GWT vs. Wicket[ Go to top ]

    I feel pretty confident in saying it is similar to a variety of mark-up frameworks ala, JSF, Stripes, etc in basic usage.
    Wicket is different. Radically different. ;-) Seriously, developing with Wicket is closer to GWT than it is to JSF or Stripes.
    If you know Swing, or the be frank, done any gui development(or event driven), GWT poses little technical hurdles, again, IMO.

    GWT is used to create web apps that look like desktop apps.
    And that's where Wicket is a good choice as well.
    In this system, a web designer is as useful as he is in a desktop application.
    How many Swing developers actually like layout managers? Not many that I know. What they like is program in an object oriented fashion, use static typing, etc.
  64. Re: GWT vs. Wicket[ Go to top ]

    How many Swing developers actually like layout managers? Not many that I know. What they like is program in an object oriented fashion, use static typing, etc.
    I like them. Well most of them. :) I guess it is all about perspective. Do a complex UI in VB6. Then slap on resizing. Then make the UI dynamic. Layout managers are FANTASTIC. :)
  65. Re: GWT vs. Wicket[ Go to top ]

    How many Swing developers actually like layout managers? Not many that I know. What they like is program in an object oriented fashion, use static typing, etc.

    I like them. Well most of them. :) I guess it is all about perspective. Do a complex UI in VB6. Then slap on resizing. Then make the UI dynamic. Layout managers are FANTASTIC. :)
    SpringLayout really made a big difference and of course making the layout managers behave the way they are supposed to in 1.6 really helps.
  66. Re: GWT vs. Wicket[ Go to top ]

    How many Swing developers actually like layout managers? Not many that I know. What they like is program in an object oriented fashion, use static typing, etc.

    I like them. Well most of them. :) I guess it is all about perspective. Do a complex UI in VB6. Then slap on resizing. Then make the UI dynamic. Layout managers are FANTASTIC. :)
    I personally don't dislike the idea of layout managers for desktop applications. Just saying that many Swing devs I know hate the way it was implemented for Java. Also, personally I think HTML/ CSS does a fine job with this, so I never felt we need to build in an abstraction for that.
  67. Re: GWT vs. Wicket[ Go to top ]

    Also, personally I think HTML/ CSS does a fine job with this
    ... for UIs that run in a browser...
  68. Re: GWT vs. Wicket[ Go to top ]

    How many Swing developers actually like layout managers? Not many that I know. What they like is program in an object oriented fashion, use static typing, etc.

    I like them. Well most of them. :) I guess it is all about perspective. Do a complex UI in VB6. Then slap on resizing. Then make the UI dynamic. Layout managers are FANTASTIC. :)


    I personally don't dislike the idea of layout managers for desktop applications. Just saying that many Swing devs I know hate the way it was implemented for Java. Also, personally I think HTML/ CSS does a fine job with this, so I never felt we need to build in an abstraction for that.
    See, I *hate* html. It is a necesary evil, but painful to use for front-ends. Trying to do any really sophistocated front-end is tedious and uninteresting. That being said, the GWT Designer was what made GWT practical. The only thing I would have hated more than HTML would have been doing a GUI-front end in code.
  69. Re: GWT vs. Wicket[ Go to top ]

    See, I *hate* html. It is a necesary evil, but painful to use for front-ends.
    That's why I prefer a designer to work on it, or at least work on mockups he/ she produces :-) But I hear ya. I'm not completely in love with HTML either. I'm torn between the flexibility of using HTML and the convenience of using a layout manager. My point is that there is - imvho - something to say for both. Neither idea is completely insane, and hurray, users have some choice here ;-)
  70. Re: GWT vs. Wicket[ Go to top ]

    See, I *hate* html. It is a necesary evil, but painful to use for front-ends.


    That's why I prefer a designer to work on it, or at least work on mockups he/ she produces :-)

    But I hear ya. I'm not completely in love with HTML either. I'm torn between the flexibility of using HTML and the convenience of using a layout manager. My point is that there is - imvho - something to say for both. Neither idea is completely insane, and hurray, users have some choice here ;-)
    Here's one thing in addition. Desktop apps don't have this concern. At least they didn't the last time I worked on one, back in 1998. Assuming this is still the case, desktop apps don't have to have something where the person working on the front-end doesn't have to be concerned with the programming language. At Apple, graphic guys gave you the design for Aqua, but the developers implemented. Wicket, Struts, all the web based frameworks *had* to separate because HTML, CSS, etc were such a pain. GWT has restored the balance to web development. Graphic guys can give me a picture and graphics, but I can put it together.
  71. Re: GWT vs. Wicket[ Go to top ]

    Wicket, Struts, all the web based frameworks *had* to separate because HTML, CSS, etc were such a pain.
    I don't agree with this. Whether it concerns desktop applications or web applications, it is a waste to not be able to directly use designs/ mockups, or let designers work on your end-product without requiring them to use an IDE. In the case of desktop applications - especially those from back in 1998 - I'd argue that the looks aren't as important. You'd hope the design is mainly functional and the look and feel follows the platform. This of course is very different from web applications, where the look and feel of individual products often make the whole difference in their success.
    GWT has restored the balance to web development. Graphic guys can give me a picture and graphics, but I can put it together.
    If that means that you're not spending much of your time fine-tuning the layout manager, that's great. I'm not convinced it would work better for my situation, but I'd love to give it a try some day.
  72. Re: GWT vs. Wicket[ Go to top ]

    Wicket, Struts, all the web based frameworks *had* to separate because HTML, CSS, etc were such a pain.


    I don't agree with this. Whether it concerns desktop applications or web applications, it is a waste to not be able to directly use designs/ mockups, or let designers work on your end-product without requiring them to use an IDE. In the case of desktop applications - especially those from back in 1998 - I'd argue that the looks aren't as important. You'd hope the design is mainly functional and the look and feel follows the platform. This of course is very different from web applications, where the look and feel of individual products often make the whole difference in their success.

    GWT has restored the balance to web development. Graphic guys can give me a picture and graphics, but I can put it together.


    If that means that you're not spending much of your time fine-tuning the layout manager, that's great. I'm not convinced it would work better for my situation, but I'd love to give it a try some day.
    Well, we have fundamental disagreement if you think that even in 1998 the look and feel of applications weren't important. It wasn't the dark ages. The best designs regardless of the era will be trump if the users don't want to use the applications. Mispellings imply deeper issues, Amateurish graphics implies an amateur product. Users don't know about elegant design. They cannot see it. In fact, I would say the opposite of what you said. Web apps get alway with murder *because* people didn't expect something that evolved from a simple form to exhibit any kind of real usability. This is only beginning to change thanks to the resurgences of what we all know is old technology - Ajax.
  73. Re: GWT vs. Wicket[ Go to top ]

    How many Swing developers actually like layout managers? Not many that I know. What they like is program in an object oriented fashion, use static typing, etc.

    I like them. Well most of them. :) I guess it is all about perspective. Do a complex UI in VB6. Then slap on resizing. Then make the UI dynamic. Layout managers are FANTASTIC. :)


    I personally don't dislike the idea of layout managers for desktop applications. Just saying that many Swing devs I know hate the way it was implemented for Java. Also, personally I think HTML/ CSS does a fine job with this, so I never felt we need to build in an abstraction for that.


    See, I *hate* html. It is a necesary evil, but painful to use for front-ends. Trying to do any really sophistocated front-end is tedious and uninteresting.

    That being said, the GWT Designer was what made GWT practical. The only thing I would have hated more than HTML would have been doing a GUI-front end in code.
    Check out Eclipse RAP for building browser based desktop-application UIs. The visual editor from Instantiations is great for this.
  74. Re: GWT vs. Wicket[ Go to top ]

    Does anyone know of a good side-by-side comparison of GWT and Wicket. These are the two Java web-frameworks I am interested in. I've worked a little with Wicket and I suppose I should look at GWT now.


    I'm not sure if it is really valid to compare GWT to any of the HTML mark-up frameworks. The approaches are simply add odds, IMO.

    If you want to do any mark-up, jsf, wicket, struts2, spring mvc, or say stripes would be a like comparison.

    But if you want to code in java, then GWT or Echo2 would be more an interesting comparison.


    You may be absolutely correct in your assertion for all I know but are you familiar with Wicket? It does involve HTML markup but this is very minimal. It seems to me that the main purpose for the HTML is to allow a web-designer make things pretty while knowing almost nothing about Java or Wicket.

    GWT compiles into client-side Javascript, correct? Doesn't that mean you need to be careful about what you put in your code? Not that this is a deal-breaker, it just occurred to me in reading this thread.
    Oh, take a look at the Instantiations GWT Designer. This is what I used to create our GWT app front-end. All drag and drop. Then I modified the code in Idea. And look at say, mygwt.net. This guy put some interesting stuff together. You can have the web designer handled graphics and css. Even that is cool, the use of stylesheets, BWT. You can apply those dynamically in GWT. I had, for example, a requiredField tag that was this kind of yellow. When you entered data, it removed the style, making it while, while of course, doing all validation client side. The customers were impressed at this visual indication of required fields. Something else I did was to eschew the submit for a menu. Enter in your data, select "Save" from the menu. I even found a toolbar later, but didn't have time to get it in. The effect was a GUI, desktop like app that felt very familiar to the users. And it was fun. Very fun.
  75. Re: GWT vs. Wicket[ Go to top ]

    Does anyone know of a good side-by-side comparison of GWT and Wicket. These are the two Java web-frameworks I am interested in. I've worked a little with Wicket and I suppose I should look at GWT now.
    First of all, I feel the frameworks or close to each other because they are good options for scaling your development effort. They both focus on providing a pure OO Java programing model. Imho, both are a good choice, and you should look what works best for your particular situation. GWT is Ajax only, keeps state on the client and works with layout managers. Wicket supports both Ajax and a traditional model (mix however you like), keeps state on the server and works with templates rather than layout managers (though you could completely abstract this and hide the markup if you really wanted). Plenty of pros and cons to both. For instance, keeping state on the client obviously makes clustering easier. But you won't take advantage of locality, run into problems (or at least inefficiencies) when using ORM tools like Hibernate, and you'll have to very thoroughly think through the security implications of having state on the client and communicating that with the server. Layout managers... On the one hand it is nice to have that ugly HTML and CSS abstracted for you. On the other hand, your design mockups are more removed from your end-code, and it will be more difficult to hire separate designers to do the layout part for you. Also, customizing layout managers may be more painful than just writing straightforward markup yourself. You have to decide whether Ajax-only works for you. For the site that I'm building, which targets tens of thousands of users in very diverse environments, we choose not to take the risk of running into problems with old browser versions, zealous administrators, etc. Also, if you need your site to be indexed and have parts of it bookmarkable, Wicket is a better choice. But if you're going Ajax all the way, GWT might be better at certain things. Another thing Wicket is very good at - better than any other framework I know - is support for localization. In GWT this was implemented as an afterthought, though it might be good by now (I haven't looked at GWT for over a year). This comparison can go on for a while, but I'm out of time :-) Like I said, I think both frameworks are good choices, so if you have time to look at them both, you should (buy GWT In Action and Wicket In Action :-) ). And don't forget to ask around for people who actually worked with the frameworks and ask how they liked it.
  76. Wicket Rules!!![ Go to top ]

    I've worked with both, GWT and Wicket and i think Wicket is definitively the winner if you want to see clean code and be able to work together with web designers. The Ajax support in Wicket is very good also. I've build an online job board called openjobs here in brazil using Wicket, Hibernate and MySQL, the experience couldn't be better... http://openjobs.com.br
  77. GWT rules[ Go to top ]

    I worked with Wicket and GWT and must say that I like GWT better. First of all GWT is much easier to get into than Wicket. Once you get the hang of it it's ok. I think one of the mayor disadvantage of Wicket is that you have templates. Some say that it's a good thing and it would make it easier for other web designers to do the actual layout etc. This is also possible with GWT since there are some very nice WYSIWYG designers out there where the web designers could work with very easy without having separate files like in Wicket. Having separate files makes having bugs more likely and you have to maintain more files which quite annoys me. In GWT you just have one Java file where you build up your GUI in instead of having 2 for every screen you create. GWT 1.5 is coming and has Java 5 syntax handling so that should not be an issue any more. Wicket uses a lot of memory if you compare it to GWT or other frameworks. At my current employer we have a small Wicket admin application that uses much memory than if you would have build it with Spring MVC or something else. GWT has also the ability to use the Javascript libraries of EXT called GWT-ext which makes your application look very slick and that library already has a lot of components you can use out of the box. Think in general building a web app with GWT costs less effort and time if you compare it to Wicket. Developing with GWT is almost like developing an rich client application in Swing/SWT. The same principals with event handlers etc. Using the GWT designer makes it even more easier. You actually don't need to learn a lot more to create an application with GWT :-). GWT Designer: http://www.instantiations.com/gwtdesigner/index.html GWT ext: http://code.google.com/p/gwt-ext/
  78. Hi there, Could someone throw light on how will cloud computing impact from a java developer's perspective.
  79. Neci list[ Go to top ]

    For my experience I agree with 3. Exception made for GWT and Groovy, I couldn't agree more with you. I'm seeing this techs more and more used in enterprises computing. GWT I would also expect to grow as opposed to FLEX. Which i believe will be the biggest two web frameworks in the nearest future. But I would leave it for last as a to be learned tech ... :)
  80. No Seam?[ Go to top ]

    Seam should have definitely been included in this list. Seam will also help alleviate the historical fears people get when they hear anything containing EJB mentioned. EJB 3.0 improved things dramatically and 3.1 is going to make it better.
  81. Re: No Seam?[ Go to top ]

    Seam should have definitely been included in this list. Seam will also help alleviate the historical fears people get when they hear anything containing EJB mentioned. EJB 3.0 improved things dramatically and 3.1 is going to make it better.
    I don't know... Certain techs fundamentally changed how we work. Struts did it. For good or bad it brought MVC to the masses and jumped started the web framework market in Java. Hibernate did it. Affordable ORM. Spring did it. Gave us full J2EE in Tomcat. Popularized POJO-containers and DI. Made AOP approachable. I think GWT will do it. Desktop apps on the web. Full debug/refactoring/OOD in web development. I don't think Seam will. Seam is a good, perhaps even great refinement, but not a game changer, IMO. Struts, Hibernate, and Spring basically buried tons of in-house projects that did similar things and allowed people to jump from job to job without learning "in-house" tools. GWT, I think, so far ahead of everything else in terms of approach, that it will do something similar.
  82. Re: No Seam?[ Go to top ]

    I was moving from JEE to RoR. But once I saw how RoR made programming fun again, I got Seam. The heaping pile of cobbled together components in JEE without Seam turn into Rails like wholeness with Seam. I wrote off EJBs and JSF years ago, now I'm back.
  83. Re: No Seam?[ Go to top ]

    Seam should have definitely been included in this list.
    Nah. Seam is only a nice glue between two half-failures. I personally like Seam, but it is not a project that would fundamentally change anything. Also, while Seam has great strengths there are also massive drawbacks for many use scenarios, so it really isn't a balanced 'all nice' framework like i.e. wicket is. For example Seam is a 100mb download with more dependencies than any junkie. It requires 8-9 config files to get running. It's a bitch to setup for different app servers, and for the development environments of junior programmers. It's programming model is annotation based 'magic' and doesn't resemble normal java that much. And when you combine the annotation/byte code/interception stuff with the two heavy technologies used underneath (JSF and EJB) the result is a system that is nice when it works, but when there is a problem the machine is so complex that fixing / debugging it is a nightmare for any, and practically impossible for junior programmers. /Henri Karapuu
  84. Re: No Seam?[ Go to top ]

    It's a bitch to setup for different app servers,
    We've been expending a lot of effort trying to improve this - take a look the Seam 2.0.1.GA reference docs, we have chapters on deploying to OC4J, WebLogic and WebSphere (with Glassfish and Tomcat to come in the next few weeks).
    and for the development environments of junior programmers.
    Have you tried JBoss Tools?
    two heavy technologies used underneath (JSF and EJB)
    Umm, Seam has been free of EJB3 since Seam 1.1 and JSF since Seam 2.0 (and we're actively working on examples using other view layers). So I don't think this is a fair criticism.
  85. Re: No Seam?[ Go to top ]

    Have you tried JBoss Tools?
    No, i haven't. Firstly, i'm IDEA user. Secondly, i don't believe tools are good solution to complexity. I.e. EJB2 was supposed to simplify development, but the technology itself was so complex that tools were needed to make it usable. I'd much prefer simple technologies and use whatever development environment i wish, instead of vendor mandated bundle. That brings me flashbacks :)
    Umm, Seam has been free of EJB3 since Seam 1.1 and JSF since Seam 2.0 (and we're actively working on examples using other view layers). So I don't think this is a fair criticism.
    Re EJB: You can run Seam without app server only if you use embedded jboss or microcontainer inside tomcat, right? To me, it does not make much difference if app server embeds tomcat, or tomcat embeds app server. Re JSF: as of today, the independence from JSF may exist in theory, but because there are no other view technologies currently available this has zero practical relevance. I believe my criticism remains valid, but i also appreciate that steps are being taken to the right direction. /Henri Karapuu
  86. Re: No Seam?[ Go to top ]

    Have you tried JBoss Tools?


    No, i haven't. Firstly, i'm IDEA user. Secondly, i don't believe tools are good solution to complexity. I.e. EJB2 was supposed to simplify development, but the technology itself was so complex that tools were needed to make it usable. I'd much prefer simple technologies and use whatever development environment i wish, instead of vendor mandated bundle. That brings me flashbacks :)
    Sure. I wasn't offering it as an answer to complexity - but rather as a way of bootstrapping a new developer quickly. Each to their own :) We're very aware of the complexity issue and even today were discussing ways to try to improve.
    Umm, Seam has been free of EJB3 since Seam 1.1 and JSF since Seam 2.0 (and we're actively working on examples using other view layers). So I don't think this is a fair criticism.


    Re EJB: You can run Seam without app server only if you use embedded jboss or microcontainer inside tomcat, right? To me, it does not make much difference if app server embeds tomcat, or tomcat embeds app server.
    Wrong. You can use Seam in *plain Tomcat* - no Microcontainer, no Embedded JBoss. You can do this with either JPA or plain Hibernate, or use the Spring integration module.

    Re JSF: as of today, the independence from JSF may exist in theory, but because there are no other view technologies currently available this has zero practical relevance.
    I agree. Watch this space :)
  87. Re: No Seam?[ Go to top ]

    You can use Seam in *plain Tomcat* - no Microcontainer, no Embedded JBoss. You can do this with either JPA or plain Hibernate, or use the Spring integration module.
    I stand corrected. When i last used Seam this was not possible. This is imho a very significant improvement, and gives lot of credibility to talks about simplifying things. And how about GWT as view technology? Has there been any integration efforts? /Henri Karapuu
  88. Seam is the way[ Go to top ]

    Seam/WebBeans should definitely be on the list. I've given many of the current web frameworks (GWT, Tapestry, Wicket, et al) legitimate tries over the past year, but IMHO none of them can match Seam's combination of ease-of-use, power, and standards-compliance. Support for conversations alone makes Seam a winner. Same goes for hot-redeployment of actions, which makes the debug/edit cycle fly. The list of built-in features just goes on and on: facelets, templated email, PDF generation, role-based authentication, tag-based AJAX, JPA, RoR-style CRUD app generation, etc. Seam just works.
  89. Re: Seam is the way[ Go to top ]

    Seam/WebBeans should definitely be on the list.

    I've given many of the current web frameworks (GWT, Tapestry, Wicket, et al) legitimate tries over the past year, but IMHO none of them can match Seam's combination of ease-of-use, power, and standards-compliance.
    SEAM gets called either a web framework or a business component framework whatever seems to be more convenient in any situation. Both are true depending on what part you look at, but it doesn't help in discussions two have these two hats. The business component framework is independent from the web framework that is used. For instance Wicket has two competing SEAM integration projects, and people from SEAM are working on official Wicket integration behind the scenes.
    Support for conversations alone makes Seam a winner.
    That really depends where you're coming from. Wicket for instance doesn't need 'conversation scoping' to start with, because with Wicket scoping depends on the reachability of objects. Just like regular Java coding. Imho, 'scoping' is a hack and distraction.
    Same goes for hot-redeployment of actions, which makes the debug/edit cycle fly. The list of built-in features just goes on and on: facelets, templated email, PDF generation, role-based authentication, tag-based AJAX, JPA, RoR-style CRUD app generation, etc.
    All of this is available in one way or the other for Wicket as well. All of it. And that's probably true for many of the competing frameworks. SEAM the business component framework is nice. I have high hopes that webbeans will be good, especially because Guice is also serving as input for it. SEAM the web framework is not my style. I don't like it's heavy dependence on (magical, global) strings. It probably does make JSF a lot better to work with, and probably helps you set up stuff quickly initially, but I can't imagine that it scales well for development.
  90. Re: Seam is the way[ Go to top ]

    For instance Wicket has two competing SEAM integration projects, and people from SEAM are working on official Wicket integration behind the scenes.
    I'm progressing fairly well, hopefully I should have some stuff in SVN over the next couple of days. I'm looking forward to seeing what you think Eelco :)
  91. What's wrong with JSF?[ Go to top ]

    Ya. I admit that GWT takes web development to a new level. But I feel Seam should not be compared with GWT, because Seam is more of a application framework and Seam 2.0 does not force anyone to use JSF or EJB. Also, I would like to know what's wrong with JSF? Is it hated because it inherited concepts from Struts? Or because of lack of component suite? I really enjoyed reading this thread and learnt a lot. Especially i love the GWT vs Wicket comparision. Can someone elaborate how Wicket differentiates itself from JSF?
  92. Seam/WebBeans should definitely be on the list. I've given many of the current web frameworks (GWT, Tapestry, Wicket, et al) legitimate tries over the past year, but IMHO none of them can match Seam's combination of ease-of-use, power, and standards-compliance.
    I cut all marketing buzz Stern and JBoss guys spreads here... I respond only because I'm tied of lies about SEAM and aggressive marketing buz. Sternn advocated Seam because of this https://www.cs.sbcc.edu/strenn/cs129/CS129%20CourseInfo%20F07.htm He claims he tried GWT and Tapestry but I failed to find a single question from him on mailing lists and user groups related to it. He teaches SEAM. I develop applications. (One of application I wrote took 2 honorable mentions on JBoss World 2006, so you know the my rate) You decide whom to believe. Now the story. SEAM is based on EJB and JSF and both technology failed because of their complexity, poor design and over engineering. SEAM adds it's own complexity to it. Guess what developer have to deal with?! No? continue to read the story. A year ago in our company (we develop for Dell, Boeing, Deutsche Bank and others) several architects were asked (god knows why client insisted on it) to use SEAM in several new projects. They obeyed. Same time I started two new projects and I have only junior developers in my team. I insisted that we should take only simple mature technologies (Spring,GWT). Customer and it's "architect" insisted on SEAM. Customer asked me and his "architect" to develop a prototype. Mine was ready in 2 days, their architect failed to develop it in a week (because it was to hard to implement all this AJAX stuff client wanted in JSF). That saved my projects from SEAM. A year has passed. All SEAM based projects failed. One probably will be closed, one another will be moved to Spring (I'm the guy who helps with it). So why triad (EJB,JSF,SEAM) is so ugly? JSF doesn't meets web2.0 needs. Too hard to craft, or even extend components, because declarative languages doesn't feet dynamic UI. Too complex life circle and each component vendor place it's own "hacks" to life circle so IceFaces won't work with Infragestis and so on. SEAM affects life circle as well, so half of your jsf ajax libs you have won't work anyway. EJB needs heavy container, hard to test, work only with JTA, and AGAIN OVER-Engineered. It's ORM part is quite poor comparing to Hibernate or TopLink. SEAM is the way to make it even complex. The learning curve for this technologies is steepest the benefit is smallest. Solution. Replace JSF with GWT. You will spend 2 day to learn GWT in comparison to 2 week on JSF. And you will be able to write complex ajax components in 1 day while JSF developer will probably fail to write it in a week. Replace EJB with Spring and Hibernate/TopLink, it will give you much more than EJB dreams of. AND ONE MORE TIME-DON'T BELIEVE IN COMPLEX SOLUTION, BELIEVE IN SIMPLE SOLUTION KISS (Keep it Simple, Stupid)
  93. Precisely[ Go to top ]

    He teaches SEAM.
    Thanks for the plug :) But seriously, The name of the course is Java EE Server Programming. In its out-of-the-box configuration, Seam uses a lot of standard JEE technologies, so I selected it as the framework for the course.
    Replace JSF with GWT.
    Replace EJB with Spring and Hibernate/TopLink, it will give you much more than EJB dreams of.
    I have to admit, I'm a little confused, by your comment. Seam uses Hibernate out of the box, and allows you to use functionality that Hibernate has that EJB does not. Seam also lets you use GWT instead of JSF. Also, I'm not sure if Spring/GWT (as you "insist") is simpler than Seam/GWT.
  94. He teaches SEAM.

    Thanks for the plug :)
    Welcome ;-)
    But seriously, The name of the course is Java EE Server Programming. In its out-of-the-box configuration, Seam uses a lot of standard JEE technologies, so I selected it as the framework for the course.
    You speak so much about standards in JEE world as if it's valuable. 5 years ago I had to tell people don't use BMP/CMB beans and half of them were telling me It's a standard, now I hear same song, the world doesn't changes. I suggest you to choose Spring for your course. Spring will allow you to teach not only standard but also good technologies. Spring will allow your students to switch between JSF/Struts/SpringMVC/GWT for WEB layer and Hibernate/TopLink/IBatis/JDO/PlainJDBC for Persistence layer. SEAM will nail down your students to JSF/JPA (Unless they start develop a real project).
    Replace JSF with GWT.

    Replace EJB with Spring and Hibernate/TopLink, it will give you much more than EJB dreams of.


    I have to admit, I'm a little confused, by your comment. Seam uses Hibernate out of the box, and allows you to use functionality that Hibernate has that EJB does not.
    It seems the only missing funtionality of EJB comparing to spring approach you know is that JPA is cut version of Toplink/Hibernate. Well, there are others, you can't get transaction demorcation outside container with EJB, you can't use not JTA transactions, the exception handling model dealing with transaction is poor (comparing to Spring), EJB doesn't provide easy AOP integration with pure java compiler, etc.
    Seam also lets you use GWT instead of JSF.

    Also, I'm not sure if Spring/GWT (as you "insist") is simpler than Seam/GWT.
    It's better to say Seam does not prevents me to use GWT. It does nothing to help. While Spring allows you to made GWT Service a Spring bean. That means that you can do transaction management right on it, you can use AOP on it, you can inject any dependency you like into it. Regards, Vitaliy S
  95. great post[ Go to top ]

    you hit the bullet on the spot (right in center). I tried to do something in JSF e.g. simple interface and comes AJAX into it. I had to leave JSF after wasting one week and move to GWT. I knew GWT before JSF but due to client pressure pursue JSF. I am happy with GWT but need more from Google. They don't have module level communication and HTML separation is pain but you can find workaround. I am now on to Flex as some part in GWT isn't mature like datagrid and charting. I think following combo rocks for small to large applications (never work on too big apps) 1. GWT or Flex 2. Spring/Hibernate/Acce for auth users 3. Tomcat or JBoss 4. MySQL or Oracle 5. Eclipse for IDE 6. Junit or your choice (possible with GWT right away)
  96. Re: Seam is the way[ Go to top ]

    Seam/WebBeans should definitely be on the list.

    I've given many of the current web frameworks (GWT, Tapestry, Wicket, et al) legitimate tries over the past year, but IMHO none of them can match Seam's combination of ease-of-use, power, and standards-compliance.

    Support for conversations alone makes Seam a winner. Same goes for hot-redeployment of actions, which makes the debug/edit cycle fly. The list of built-in features just goes on and on: facelets, templated email, PDF generation, role-based authentication, tag-based AJAX, JPA, RoR-style CRUD app generation, etc.

    Seam just works.
    Well, GWT isn't a web framework. It doesn't do PDF generation or CRUD app generation. If you went in expecting this, you would have been disappointed. Again, I submit that Seam may integrate several items, but it doesn't change the game. I can(and have) turned a Struts/Spring/Hibernate app into a GWT/Spring/Hibernate app. Seam wouldn't be a good fit(I don't think) if you want to upgrade the presentation tier(which is all GWT aspires to). In addition, it doesn't really bring anything new to the table. All the stuff you mention already existed before Seam. GWT, however, is a game changer. It is fundametally different in form and function than any web-framework.
  97. Re: Seam is the way[ Go to top ]

    Again, I submit that Seam may integrate several items, but it doesn't change the game.
    Agreed.

    Seam wouldn't be a good fit(I don't think) if you want to upgrade the presentation tier(which is all GWT aspires to).
    As I mentioned in a post above, Seam can use GWT as its presentation tier. In fact, it can use straight HTML/Javascript as its front end via Remoting.

    In addition, it doesn't really bring anything new to the table. All the stuff you mention already existed before Seam.
    Mostly agreed. Correct me if I am wrong, but I have never seen Conversations in another Java framework. Actually, I haven't seen them in non-Java frameworks either (e.g. PHP, .NET, python).
  98. Re: Seam is the way[ Go to top ]

    Again, I submit that Seam may integrate several items, but it doesn't change the game.


    Agreed.




    Seam wouldn't be a good fit(I don't think) if you want to upgrade the presentation tier(which is all GWT aspires to).


    As I mentioned in a post above, Seam can use GWT as its presentation tier. In fact, it can use straight HTML/Javascript as its front end via Remoting.




    In addition, it doesn't really bring anything new to the table. All the stuff you mention already existed before Seam.


    Mostly agreed. Correct me if I am wrong, but I have never seen Conversations in another Java framework. Actually, I haven't seen them in non-Java frameworks either (e.g. PHP, .NET, python).
    Sorry. I didn't mean that Seam couldn't use GWT. The nature of GWT means that just about anything can use it. What I mean was that if you had an existing app and wanted to change the presentation tier, you probably wouldn't consider Seam. The two really don't overlap. As for converstations, perhaps I'm missing something(having not used Seam), but isn't that just state. Seam, if I understand, does some things to better(and automatically) maintain state between requests. What if you don't use request/response? I don't know...there are ways to do this, I don't think that is a fundamental biggie. Does it fundamentally have a solution that will fundamentally change how you design and implement your system? Again, I don't know.
  99. Re: Seam is the way[ Go to top ]

    Correct me if I am wrong, but I have never seen Conversations in another Java framework.
    Spring Web Flow has similar scope. /Henri Karapuu
  100. Re: Seam is the way[ Go to top ]

    Spring Web Flow has similar scope.
    I see. Here it is from the webflow site.
    Have memory you allocate during flow execution automatically clean itself up when execution ends or expires.
  101. I put RIA's on the list[ Go to top ]

    I bet that within 5 years a significant percentage of all new web-based apps will be build with a RIA. (Flex, Silverlight, FX or open-souce variants). At the same time SAAS companies will break through, if they are able to deliver desktop qualilty web apps. In order to that (IMO) you need something like a Delphi IDE for the client development, and that is exactly what these RIA's do. gr
  102. I think JSR-170 should receive more focus because it yields a very nice promise - the ability to develop applications with dynamically structure data. Read dynamically structure data as: USER GENERATED CONTENT, :) - Portlets should either Die or er, well, Die. Too much complexity, too little benefit for end-users Most portal implementors are looking for web content management and the presentation integration idea behind portlets wasn't implemented either in good quality or open enough for people to actually do what they want. - JSF in 2008: Make or break. If Components aren't good enough this year (very very, very customizable, open and flexible) it would mean that JSF remains a nice theoretical model. Components are still far from being something fun to work with (myfaces, richfaces are the ones I know). - Facelets: If your using JSF, then Facelets is an important framework you should consider to make some templating order in your views. My 2cs.
  103. Evaluated GWT along side Flex for a few months, but went with Flex. GWT is okay if Flex didn't exist - but Flex is way, way better than GWT for building next gen RIA web apps. Would drop any and all server-side MVC web frameworks from such a list - complete waste of time. When one shifts over to building RIA web apps, then becomes a matter of building relatively simple SOA services on the server-side. The higher complexity/overhead of MVC web frameworks on the server-side then become totally unnecessary and undesirable.
  104. Evaluated GWT along side Flex for a few months, but went with Flex. GWT is okay if Flex didn't exist - but Flex is way, way better than GWT for building next gen RIA web apps.

    Would drop any and all server-side MVC web frameworks from such a list - complete waste of time.

    When one shifts over to building RIA web apps, then becomes a matter of building relatively simple SOA services on the server-side. The higher complexity/overhead of MVC web frameworks on the server-side then become totally unnecessary and undesirable.
    What a complete lack of nuance. With a RIA framework/ all business logic exposed as a service, securing your application becomes a major effort again (a strong feature of using Wicket or Lift for instance is that your app is secure by default). Also, server side frameworks can take advantage of locality, and you can directly access any object you want without having to translate it to a web service. With RIA, you can end up with quite a bit of code duplication, for instance, you'll copy most of your domain model. Not to mention that refactoring is more painful as you'll cut across multiple technologies now. And another thing your setup doesn't give us is general site management for things like indexing and bookmarking. There's a lot to say in favor of techs like Flex (the project I'm working on actually uses both Wicket and Flex), but it's not to end of all things. Your way of discussing - Flex is better than GWT without even trying to explain why - isn't helpful at all.
  105. What a complete lack of nuance. With a RIA framework/ all business logic exposed as a service, securing your application becomes a major effort again (a strong feature of using Wicket or Lift for instance is that your app is secure by default). Also, server side frameworks can take advantage of locality, and you can directly access any object you want without having to translate it to a web service. With RIA, you can end up with quite a bit of code duplication, for instance, you'll copy most of your domain model. Not to mention that refactoring is more painful as you'll cut across multiple technologies now. And another thing your setup doesn't give us is general site management for things like indexing and bookmarking.

    There's a lot to say in favor of techs like Flex (the project I'm working on actually uses both Wicket and Flex), but it's not to end of all things. Your way of discussing - Flex is better than GWT without even trying to explain why - isn't helpful at all.
    Actually security is very easy to set up using SpringAcegi. Our SOA has two main conceptual entry points: One is BlazeDS servlet and the other is a Spring controller (for conventional HTTP POST/GET/PUT interactions). Of course could establish multiple controllers via Spring. SpringAcegi security guards the front side via an HTTP filter and URL patterns. This guards both Spring controllers and BlazeDS servlet. Then on the backside, where Spring POJO beans are dispatched to from BlazeDS or the Spring controller, method granularity security is applied by SpringAcegi (there's typically a many-to-one relationship of methods to URL patterns on the front-side). It's clean, AOP-based, and quite straightforward to set up.
  106. Actually security is very easy to set up using SpringAcegi. Our SOA has two main conceptual entry points: One is BlazeDS servlet and the other is a Spring controller (for conventional HTTP POST/GET/PUT interactions). Of course could establish multiple controllers via Spring.

    SpringAcegi security guards the front side via an HTTP filter and URL patterns. This guards both Spring controllers and BlazeDS servlet. Then on the backside, where Spring POJO beans are dispatched to from BlazeDS or the Spring controller, method granularity security is applied by SpringAcegi (there's typically a many-to-one relationship of methods to URL patterns on the front-side).

    It's clean, AOP-based, and quite straightforward to set up.
    My point wasn't that it isn't possible to protect your services. Of course it is. However, it is an explicit task now, while when you develop with Wicket, it is often implicit. To give an example, the app I'm working on has a sophisticated authorization model with organizations which have 'workspaces' (functional units), which have groups, and users can be members of these groups. Membership of workspaces determines the availability of functionality for specific users. For instance, there is a function to maintain user accounts for organizations which is only available for users who are members of an administrator group that is coupled to an administrator workspace of an organization. We don't have to check whether clients of the services that back this functionality are authorized, as we know these calls are local. The services that we explicitly expose to the outside world have their own protection, and these services are generally courser grained and far fewer than the services for application use. As Wicket does not expose state to the client, and the only way to get to non-bookmarkable functionality is to navigate there, there is no way for clients to directly access this functionality. Now, would we adopt a RIA framework and expose all of our services (hundreds, and most aren't really interesting for clients other than our web app) as WS or REST, maintaining authorization enforcement would be *a very big pita*. Sure, not everyone has to deal with sophisticated authorization models like we do - though most of the systems I worked on during my career actually did - but it is certainly something to consider.
  107. To give an example, the app I'm working on has a sophisticated authorization model with organizations which have 'workspaces' (functional units), which have groups, and users can be members of these groups. Membership of workspaces determines the availability of functionality for specific users. For instance, there is a function to maintain user accounts for organizations which is only available for users who are members of an administrator group that is coupled to an administrator workspace of an organization.

    We don't have to check whether clients of the services that back this functionality are authorized, as we know these calls are local.
    We have same kind of deal. Using SpringAcegi, we use aspect-oriented programming (which is declarative) to apply authorization. So security authorization is a separate concern and nothing explicit is programmed into the code. But of course we use the Acegi configuration of declarative security to change things up so can readily adapt as things evolve over time. So takes burden off of developers writing the business processing code yet retains ability to shift and apply as/where necessary.
  108. To give an example, the app I'm working on has a sophisticated authorization model with organizations which have 'workspaces' (functional units), which have groups, and users can be members of these groups. Membership of workspaces determines the availability of functionality for specific users. For instance, there is a function to maintain user accounts for organizations which is only available for users who are members of an administrator group that is coupled to an administrator workspace of an organization.

    We don't have to check whether clients of the services that back this functionality are authorized, as we know these calls are local.


    We have same kind of deal. Using SpringAcegi, we use aspect-oriented programming (which is declarative) to apply authorization. So security authorization is a separate concern and nothing explicit is programmed into the code.

    But of course we use the Acegi configuration of declarative security to change things up so can readily adapt as things evolve over time.

    So takes burden off of developers writing the business processing code yet retains ability to shift and apply as/where necessary.
    Your separate concern is no concern for me at all, since I don't have to maintain any such code/ configuration. Only for the services I choose to expose, and those are far fewer than the number of services available for the web app.
  109. Your way of discussing - Flex is better than GWT without even trying to explain why - isn't helpful at all.
    Well, it was born of seeing how frustrating it was for the developers to try to do things in GWT that was border-line trivial to do in Flex. The Flex datagrid is awesome. With GWT - there are some things out there that you can mess around with, but you'll spend days and have just a pathetic facsimile of what can be done using the Flex datagrid. If you need to do any biz intelligence data visualization, then the Flex charting is superb (especially how Flash transitions/animations can be applied to Flex charts and how well Flex CSS can be used to customize them in myriad declarative ways). Flex has vector graphics so is possible to make very nice, professional looking custom widgets. The general ability to use transition effects and other special Flash/Flex visual animation enhancements in the UI is very nice. Sliding panels work extremely well. You can make tabbed panels that actually look aesthetically pleasing. GWT lets you do async RPC. Well, with Flex one can do: async HTTP POST/GET using HttpSerivce, async SOAP, async WS* web service calls, XmlSocket bi-directional messaging (which means can do server-side push), plain TCP/IP socket. Then with BlazeDS there is bi-directional messaging using Comet Pattern (here again can do server-side push) and async remote method invocation. This supports object serialization between ActionScript3 and Java. If doing XML, then there's the E4X feature in ActionScript3 that makes accessing XML data very simple and clean. Unlike GWT, where a form is coded procedurally with Java, in Flex a form is declaratively coded in MXML. This is more concise, clearer, and efficient productivity-wise. ActionScript3 can be static type enforced (the compiler does this by default), so is comparable to Java in that regard. However, AS3 has very nice closures implementation. Closures are a very natural way to program the asynchronous i/o mechanisms that Flex provides. ActionScript3 has properties (nicer than C# properties), events, and declarative data binding. Is a powerful way to implement MVC - such as the Cairngorm MVC pattern - with good decoupling between the layers. (Is possible to make resusable Flex components because of these features.) So due to declarative MXML and ActionScript3, Flex is a more pleasurable coding experience than GWT Java imperative coding. The Flex Builder is a decent visual designer for forms - works better than ones we tried for GWT. Has gotten better in Flex 3. A biggie for us is that we found areas that GWT just wasn't able to deliver a uniform experience across browsers and OS platforms. Flash Player 9 for Flex apps has given us a very wonderful, consistent experience across browsers and OS platforms. You truly can develop on one particular browser/OS and expect a Flex app to look and behave the same on other combos. I could keep going and going about how Flex exceeds GWT, but I really don't want to rub it in. I admire GWT for what it is.
  110. I fully agree that Flex is stronger for pure RIA development. GWT on the other hand is stronger for most general purpose and enterprise development; generally loads faster, runs in larger percentage of browsers, stays close to standards and supports normal web paradigms (back buttoning, bookmarking etc.). For these reasons, and because of general dislike/FUD against flash and flex, using GWT is possible for probably 10x wider range of projects. I also agree that GWT's progamming model has still significant issues, including lack of data binding and declarative UI definition, but these are all being addressed. Finally, i have very difficult time understanding your opinion that programming in action script would be superior to using Java and Java's first class, mature development tools, but to each his own i guess.. /Henri Karapuu
  111. I could keep going and going about how Flex exceeds GWT, but I really don't want to rub it in. I admire GWT for what it is.
    Thanks. Explaining why you like Flex better is helpful to at least me. I like the little that I've done with Flex, and I think Air is a great idea. Air isn't new, but with Adobe I think we can be confident that installation across platforms will be relatively painless. On one thing we disagree. I prefer the flexibility imperative coding gives you over declarative coding when it comes to developing UIs. So I expect to like GWT better in that respect.
  112. On one thing we disagree. I prefer the flexibility imperative coding gives you over declarative coding when it comes to developing UIs. So I expect to like GWT better in that respect.
    MXML gets compiled into ActionScript3 so has a direct correspondence without any tricky mental hurdles. Is just that MXML enables describing GUI structure in a more visibly cleaner manner and a single line of MXML declarative code can equate into a number of lines of equivalent AS3. But app UIs tend to be dynamic and morph a lot, so is typical to broadstroke the GUI structure in MXML and of course couple it to imperative ActionScript3. One could actually code a Flex app using entirely AS3 and an imperative approach 100% of the time. No one ever does that, though, as the advantages of MXML in combo to AS3 become readily apparent once one gets into it a bit. JavaFX has a declarative scripting approach and Silverlight has XAML. It's a powerful way to deal with GUI construction.
  113. Your way of discussing - Flex is better than GWT without even trying to explain why - isn't helpful at all.


    Well, it was born of seeing how frustrating ....
    Roger, How about duplication of domain objects? Or any code, for that matter? Or can my POJOs just be used with Flex? I think this was one of Eelco's concerns. Also, the datagrid - I had posted something on another forum asking how that dealt with complex objects. How does it with something like: Person String: lastName Address: homeAddress
  114. Java FX[ Go to top ]

    What do you think about java FX technology??
  115. fast,fast,fast.....[ Go to top ]

    I have been working with microsoft .net tech last year and now....i am starting one java project with "Struts" and looks...jurasic to me Everything that dont allow you to write one basic UI in 10 minutes is ....primitive... I wonder why people dont use things like Oracle ADF or SEAM.. Java need things easy, power and fast to build....not arcan technologies.... In the while one java team argue about the best technology....one microsoft developer have the half of the things done...This is the top one that have to change for me in 2008
  116. Re: fast,fast,fast.....[ Go to top ]

    I have been working with microsoft .net tech last year and now....i am starting one java project with "Struts" and looks...jurasic to me

    Everything that dont allow you to write one basic UI in 10 minutes is ....primitive...

    I wonder why people dont use things like Oracle ADF or SEAM..

    Java need things easy, power and fast to build....not arcan technologies....

    In the while one java team argue about the best technology....one microsoft developer have the half of the things done...This is the top one that have to change for me in 2008
    I would argue that MS stuff is not necessarily faster. But your post is a great example of why speed isn't everything. What's the point of putting out something quickly if it is a mess? I would submit that just about every customer wants their software as quickly as possible. If MS was both the fastest and highest quality, why doesn't isn't everything .Net?
  117. Re: fast,fast,fast.....[ Go to top ]

    I have been working with microsoft .net tech last year and now....i am starting one java project with "Struts" and looks...jurasic to me

    Everything that dont allow you to write one basic UI in 10 minutes is ....primitive...

    I wonder why people dont use things like Oracle ADF or SEAM..

    Java need things easy, power and fast to build....not arcan technologies....

    In the while one java team argue about the best technology....one microsoft developer have the half of the things done...This is the top one that have to change for me in 2008


    I would argue that MS stuff is not necessarily faster. But your post is a great example of why speed isn't everything.

    What's the point of putting out something quickly if it is a mess?

    I would submit that just about every customer wants their software as quickly as possible. If MS was both the fastest and highest quality, why doesn't isn't everything .Net?
    David, I believe he was saying that since there is one framework for ASP.Net (Webforms) - While Java developers are trying to decide which framework to use, the .Net developer can just start coding. Of course, there are other frameworks for ASP.Net. A few of them are Java Ports. They are just overshadowed. This brings up the issue of choice (and we know everything is not a nail). And there are other issues, but no need to go there now.
  118. Re: fast,fast,fast.....[ Go to top ]

    In the while one java team argue about the best technology....one microsoft developer have the half of the things done...This is the top one that have to change for me in 2008
    I hate to say it, because I'm often a big MS critic, but that kind of sums it up, doesn't it? In the .Net world, for better or worse, you have ASP.Net for web apps, and ADO.Net for persistence (with ORM-ish DataSets as abstractions on top of ADO.Net), and that's about it. There is Spring.Net, NHibernate, ActiveRecord, etc. But most .Net devs just get on with it with regular ol' ASP.Net and ADO.Net, and don't worry about this framework or that framework, are writing reams of XML configuration. That said, ASP.Net and ADO.Net are certainly not perfect, nor do projects using .Net lend themselves to great design and perfect architecture (all that auot-generation and point-n-click stuff makes overlooking good design principles easy). But there are usually good enough to "get the job done", and do it well enough for most production environments. Choice is good, but too much choice, in the tech field, can really lead to chaos. There are so many Java web frameworks, and persistence frameworks, that it can make your head spin. I'd like to jump on the "standards" bandwagon, and full adopt JSF and EJB3. But JSF is over complicated, and EJB3 is really good when compared to EJB2.x, but it's not as good as Spring and Hibernate. I'd like to see highly simplified standards, that keep the easy, smaller projects, easy, and make the big, complicated projects possible. I find that in the Java EE world, everything is oriented towards solving the biggest and most complicated problems, and so much so that the existing standards and frameworks cause the small, simple problems to suddenly become hard. A previous poster talked about a 30meg War, with 200+ lines of XML config, 30 classes, and 40 unit tests, all for a simple CRUD app that was fronting 5 tables. This is so typical in Java EE. I want to see the day where a simple CRUD app fronting 5 tables done in Java involves zero or very little XML configuration, maybe 5-10 classes, little or no unit tests and can be hacked up in a day of work.
  119. standard or good?[ Go to top ]

    Hello Jeff,
    I'd like to jump on the "standards" bandwagon, and full adopt JSF and EJB3. But JSF is over complicated, and EJB3 is really good when compared to EJB2.x, but it's not as good as Spring and Hibernate. I'd like to see highly simplified standards, that keep the easy, smaller projects, easy, and make the big, complicated projects possible. I find that in the Java EE world, everything is oriented towards solving the biggest and most complicated problems, and so much so that the existing standards and frameworks cause the small, simple problems to suddenly become hard.
    I believe in standards for interaction, security, component distribution, etc... But, I do not believe in standards for software frameworks. J2EE World demonstrates it perfect: In the age of ejb 2.0 entity beans we had Hibernate 2, Toplink. "standard" (ejb) solution was the worst of all. Now we have standard JPA and it is still the far behind Hibernate. We have "standard" EJB containers and we have Spring. We have "standard" web framework JSF, and we have GWT. Still "standard" framework is far behind. Why do you want to relay on standard solutions and which way a "standard" framework developed by Sun,Oracle and IBM is better than "non standard" framework developed by company N?
    I want to see the day where a simple CRUD app fronting 5 tables done in Java involves zero or very little XML configuration, maybe 5-10 classes, little or no unit tests and can be hacked up in a day of work.
    Try Spring 2.5 with Hiaberate and Hibernate Annotations if you want to get rid of XML. Take GWT for web. I can't understand why you don't want to have unit tests. (one of the thing I like GWT for is the ability to unit test my web application). Regards, Vitaliy S
  120. Yes, Indeed an architecture like this: GWT-Spring 2.5.1-Hibernate-Derby and junitCreator for tests is what I really want to apply for one of our future small-size project. Vitaliy, your similar opinion enforces my decision. Thank you!
  121. You are always welcome Ionel. Can I ask why you chose derby? For unit tests I use HSQL or H2. PS For production I'd choose postgresql, but our customer loves oracle ;-) Regards, Vitaliy S
  122. why Derby?[ Go to top ]

    I choose derby because this application will be distributable over internet (and intranet, vpn of our customers) and we have to integrate all the components in one single bundle which must be simple and self installable (tomcat, derby, java 1.5 or 1.6, ...all installable probably via NSIS Install System). So also because the data will not be huge, i think derby is a good solution. But if you can advice me to evaluate another solution which is freely distributable and easy to bundle, please let me know. By the way, I prefer Oracle too :), and almost all of our projects are Oracle based.
  123. Re: why Derby?[ Go to top ]

    I'm not an expert in embedded db on production. I use hsql and h2 because they are speed enough to run unit tests (10sec for 200 tests in comparison 4min on oracle and 2mins on postgresql). Derby is much slower than hsql and h2. For production I prefer postgresql because it's free,fast(comparing to oracle it's almost twice faster on my projects), easy to use and distribute and quite powerful. I don't like oracle because it is not free, quite hard to distribute and maintain comparing to postgresql. Of course oracle has features postgresql can only dream of but in 99.9 of projects I know there is know need for these features. Regards, Vitaliy S
  124. Re: fast,fast,fast.....[ Go to top ]

    I wonder why people dont use things like Oracle ADF or SEAM
    I think it is because JSF is declarative programming - it is not applicable for Web2.0 applications. On the other hand it might be because JSF is too complicated and SEAM makes it even worst because it's based on EJB and affects JSF life circle (making it even more complicated). People like simple solutions like Spring. Web2.0 application are build on GWT these days.
  125. GWT for mobile browsers[ Go to top ]

    I haven't really used GWT. But can it be used to support both desktop browsers and mobile browsers used in Blackberries and Windows smartphones?
  126. Are we all missing the point?[ Go to top ]

    I think the article was a good read, and my list might differ a little than Carlos's list, but it is good for us to take some perspective on where we are and where we are going. I would add Integration Solutions, like JBI/B-PEL/ESB as a technology not fully explored or utilized by our community. I think we can celebrate the fact that now we have many good choices for developing software. The posts here are mainly Web based application, but the topic is bigger and the problems are more diverse, and the solutions all have their benefits and drawbacks. I am happy we have good choices. Only a few Issues #1. The bickering over whose framework is better is childish, but entertaining. Each framework has a different design principals. All by smart people and communities. I match the problem I am trying to solve with the solution that is in line with tools purpose, and when there are more than one choice - GREAT.. I get to choose the best. I personally don't like the idea that one solution fits all y problems?? Sounds like Microsoft. #2. Java + J2EE, JSF, Servlets and many more from the JCP (Java Community Process) based solutions are not complete enterprise solutions. They are an agreed upon standard to start the conversation. It's really about an agreed upon standard way to address solutions for a particular domain, and the choices the market makes to differentiate the products. This is why clustering was left out of the JEE Specification so each vendor may implement their own solution to differentiate itself from the competition. Anyone may start with a freely available standard implementation for learning the technology, than stay with that implementation or upgrade to implementation that has more bells and whistles that you need. I see so much hatred about Hibernate and JPA/Toplink. We should thank the people from Redhat and Hibernate for contributing so much to a standard, but because so many companies participated their interface changed to become standard and now we as a community is mad about it? I am happy I can use Hibernate, Toplink, KODO, Open JPA or any implementation I choose. And as most architects know.. it's not always the developers or architect's choice. 3. Replacing one container with another? Nobody said that JEE is the only container model available. So I welcome Spring as a full solution. I actually criticize IBM, Rehat, and every other JEE container for not implementing a container that is complaint with the current JEE 5 version. We all hated those silly XML files and XDOC and all the madness needed to make EJB 2.X work. I am an old timer, I coded in EJB 1.0 and 1.1. EJB 3 and EJB 3.1 is the strongest business logic development methodology that I know. And one of the easiest! That's right one of the easiest pending you can a server that implements the full Specification. With the addition of WebBeans (inspired from JBoss Seam) and Dependency Injection (Inspired from Google's Guice) and JSF this will be a powerful solution no matter what JSF implementation you have. The partial solutions such as the inability to use the JEE dependency Injection in Jboss lead to the need to really use Seam. And many other silly combinations. Webshere users use Spring, because the IBM ejb 3.0 implementation arrived so late and was not complete. We all disliked J2EE 1.4, but it is looking very very positive, because we complained so much for JEE 6, EJB 3.X and beyond. I have not seen 36 Clusters of Spring containers co or tri-located with Session replication and management yet. I am sure it is comming at this pace, but not today. 4. Try these new Tools! GWT, Wicket, Flex, Java FX, Struts 2, all the Faces implementations (My, Rich, Ice, ..) and be flexible when trying to solve a solution. I know we want quick productivity, but having the right tool for the right job, goes much further than just developing the application. reading the posts...we are a sensitive group so .... PLEASE DON't CRITIZE A FRAMEWORK IF YOU HAVE NOT USED IT OR TRIED TO LEARN IT. We all see through the marketing stuff.. and the posturing, in favor for a particular framework or another. Personally I love to reach when people and contrast the tools/frameworks/technologies so I will have better insight on which one would suit my needs better. All of us (I hope) are Java Developers. We should be able to learn any one of these tools or frameworks. With so many choices we can choose the ones that we are most interested in, or have some value to us. NOTE: I dislike to find developers that don't know the base Java language or even some of the base API's that some of these frameworks are build upon. I ask interview questions about the Servlet API and web.xml as a base test.
  127. #1. The bickering over whose framework is better is childish
    We've been discussing pros and cons. This a forum, so imho we've exactly been doing what we're supposed to do here. I thought it was a reasonable discussion.
    I match the problem I am trying to solve with the solution that is in line with tools purpose, and when there are more than one choice - GREAT.. I get to choose the best.
    Exactly. I hope most people here agree.
  128. #1. The bickering over whose framework is better is childish
    We've been discussing pros and cons. This a forum, so imho we've exactly been doing what we're supposed to do here. I thought it was a reasonable discussion.
    +1

  129. I actually criticize IBM, Rehat, and every other JEE container for not implementing a container that is complaint with the current JEE 5 version.
    Actually JBoss EJB3 implementation is far more decent than, for example, BEA's. Weblogic EJB3 simply don't work, Period. It's unfair to put JBoss in the same band of shame as weblogic. Really unfair.
  130. Mentawai, Scala, Rest[ Go to top ]

    Mentawai: programmatic configuration, decoupled frameworks with no annotations http://recipes.mentaframework.org/posts/list/52.page Scala: more dynamism brought to Java http://recipes.mentaframework.org/posts/list/41.page Rest: the way a WS is supposed to be http://www.peej.co.uk/articles/restfully-delicious.html
  131. To those who advocate Flex[ Go to top ]

    To those who advocate Flex: If you customers allow heavy modules on pages why Flex and not Applets And/Or JavaFX? PS I've recently come across JavaFX Builder and it looks quite promissing, does anybody uses JavaFX already in real projects, can we see the result?
  132. Re: To those who advocate Flex[ Go to top ]

    To those who advocate Flex:
    If you customers allow heavy modules on pages why Flex and not Applets And/Or JavaFX?

    PS I've recently come across JavaFX Builder and it looks quite promissing,
    does anybody uses JavaFX already in real projects, can we see the result?
    I am looking to use JavaFX in a desktop project. Either that, or I will just go with Swing. Flex (and AIR) is out because I need to use existing Java code and components. If the app would always have a server available, then it might be different - well not for this app.
  133. ReallyusefulNewFeatures.jee[ Go to top ]

    I make bold to say EJB/JEE is heading towards the bus stop MS left years back(yes you read that right). As a long time .Net/COM+ developer who had to migrate to J2EE because of the EJB hype, I find it funny that most developers on the J2EE platform can't just see that the current J2EE spec sucks!A test of the ease of use of any product/frameworks/whatever is the relative ease with which a new user can get an app up and running.The whole array of confusing specs,frameworks,APIs that one has to learn to implement the simplest functionality in J2EE is at best annoying.My current impression of a J2EE project now is it really gives you the feel of an academic exercise.What with over-engineered APIs and frameworks in the name of OOP purism, ardent refusal to implement complementary technologies from competitors(why were the JSR guys afraid of including the .Net style delegate in the specs when they picked on annotations?),proliferation of crappy specs and a mountain of frameworks/APIs/specs to learn just to get one single thing done. The good news for me is that SpringSource has finally caught the hint-I don't have to know the raw details before I use it- and hopefully they are on the right track.The real trick is the container does the plumbing and I do my bizlogic. The current offers by SpringSource as of release 2.5 are on the right track(IMO), but what is lacking is a managed host container- an appserver/container for hosting managed services that a managed bean subscribes to at runtime or programmatically. MS got AOP-style development right a long time ago thru COM+, it's all about context and interception. Think of a scenario where JDBC connections,JMS resources,or about any resource to be used in application code can be configured for use by ALL apps running in the container without using local XML descriptors for each app or at worst minimal declarative resource acquisition thru DI via annonations.And this can even be done from a management console-u should be able to manage services used by a deployed bean thru a console! The only dependency would be on the service client libraries referenced in the calling code-which can either be 1.auto-generated( by the container) JARs containing service interface definitions and the necessary proxy/stub pairs 2.auto-generated( by the container) WSDL files that can be run thru a tool to generate the necessary proxy/stub pairs 3. Or even better- a service-invocation framework(can't elaborate on this now) All this if u have'nt guessed it requires a managed framework or a managed container not a suite of over-engineered specs that only looks good on paper. PS: If u have'nt realised it, MS has done it again-LINQ.It's called "ORM for the real world". Long live entity beans and JPA!