Ignacio Coloma

+1 to the fork. Actually I feel like I am witnessing a train wreck in slow motion.

Agree, it seems FUD. From the article: "I believe it is likely that Oracle will axe its support for OpenOffice.org, preferring instead to focus on technologies such as StarOffice that bring in new revenues." For no other reason than monetizing the community? Sun moved from StarOffice to OpenOffice because it was not catching enough attention, and suddenly Oracle has a secret plan to fix everything? It may be possible (and unlikely), but the article does not give any explanation for this.

Say you have a hierarchy of classes, C extends B, B extends A. Put an attribute in B. If you later move that attribute to A (even if it's the same attribute), you will have to recompile C. This doesn't happen with getters and setters, which is a major concern for library designers (source: the Practical API Design book).

Say you have a hierarchy of classes, C extends B, B extends A. Put an attribute in B. If you later move that attribute to A (even if it's the same attribute), you will have to recompile C. This doesn't happen with getters and setters, which is a major concern for library designers (source: the Practical API Design book).

Not one single comment supporting the point of view of the author. The article seems to suggest that GAE and Android respond to a political strategy, where all evidence seem to suggest technical issues (like not supporting the File API in GAE). Similar to JEE and multithreading.

The point never was that you cannot do creative things with flash.

Too much groovy propaganda. I don't think it's valid to extrapolate his experience with a web framework to the entire java stack. If he was comparing with a modern REST framework (jersey/spring mvc3) and the latest annotation-based spring configuration, then it would be apples to apples. Otherwise it's skewed. I still think it has some valid points, though.

There are plenty of themes for ExtJS out there, and sure you can extend or modify current widgets with your own. They use a class-alike component structure including inheritance mechanisms. They also include Model, View and Event classes. Having said this, I am not an ExtJS expert or anything.

"Im no JS guru but I dont know any JS library which let you build rich-client like web applications like GWT does. GWT enables you to build web application in the same (or similar) way like you would build rich-client desktops apps." ExtJS does (it is mentioned in the article). They also include a designer tool: http://www.extjs.com/blog/2009/10/08/ext-js-designer-preview/ About user input validation, you are right that every web framework should include a way to avoid replicating validation code. Not all frameworks come with an embedded solution out of the box. Your point about GWT is entirely reasonable, and I agree it's a great tool for developing rich apps. It's just that I don't see the reason for so many voters against the article.

The article still has a valid point. The typical most common arguments pro-GWT are not exactly set in stone: - cross browser compilation: the ajax library of your choice will tackle this. For the 1% cases that fall out of these, there is the jresig book. - code reuse on client AND server: this is a valid point, but how often do you need this? - nice JUnit support for client side code: there are plenty of junit-like libraries for javascript. - one language fits most for client AND server: these days I am seeing articles on the two extremes of pro and against polyglot programming. For me, javascript makes me more productive than Grails. I am not saying that GWT does not have good things, but I still think the article gives some fresh perspective to the matter.

@anewhope: the spring testing module relies on @RunWith, so hey better do not remove this in the short term :)

@anewhope: the spring testing module relies on @RunWith, so hey better do not remove this in the short term :)

@anewhope: the spring testing module relies on @RunWith, so hey better do not remove this in the short term :)

@anewhope: the spring testing module relies on @RunWith, so hey better do not remove this in the short term :)

@anewhope: the spring testing module relies on @RunWith, so hey better do not remove this in the short term :)

@anewhope: the spring testing module relies on @RunWith, so hey better do not remove this in the short term :)

Me too. Really... "What are important ApplicationContext implementations in spring framework?" Exactly how does that make you a better developer?

Sorry but I have problems getting your point. You are saying that this article is outdated because the problems are resolved in Seam. Then, JSF is still a valid standard, just take care to avoid your vendor lock-in. Isn't this a contradiction? Avoid Seam to keep vendor-independent, then use Seam because the standard is screwed? Sorry, it's just that I never got how this "JSF is standard" thing works. Have you ever looked at Oracle ADF? The point above related is true, it's impossible to port a real-world JSF application between different frameworks.

I think we are talking about modifying sources while debugging. It's the only case I have to redeploy when I am not using JavaRebel.

Not that I know much about this, but The Ones That Know are saying that it's java that keeps sun in the market, and it should have closed its hardware industry long time ago: http://www.forbes.com/2009/04/06/sun-microsystems-enterprise-technology-enterprise-tech-sun.html

Disagree. This kind of proposal waste everybody's time. The community has spoken and the single most requested feature are closures. Now they are shipping Java 7 without them. I fail to see how diverting resources for these features can be seen as anything else but a waste of time. It gives only a partial solution for the problem while bloating the compiler with Yet Another Feature.

I still think the author has a valid point. To me, a release without closures does not make any sense. Everybody writes loops, every day. Since the advent of spring, really few people open files by hand. I think the JDK team needs some focus.

I disagree. There are some valid points in this article. The comparison could be better, but it certainly was not _that_ shallow.

It's true that Loom was inspired by stripes. To avoid repeating the details, here is the post exchanged with Gregg one year ago: http://groups.google.com/group/loom-users/browse_thread/thread/fd120cc70120c87f Only the part about "lots of its initial code base" is wrong. Loom never adopted a single line of code from stripes, the implementation was done entirely from scratch.

The article itself references Calendar, which is a bad election since jodatime (for example) would have been much more expressive. They are choosing what has been reported as the worst designed API in the JDK. Back to the real subject of discussion, "with" has been supported by other languages before Rails (something about history repeating itself), and was systematically reported as an antipattern because it harms maintenability.

I don't think a IO library is something that anybody can achieve on his own outside the JDK team. The ideas of the post seem valid, and I wouldn't require every valid criticism to come coupled with a suitable implementation.

I don't see this article raising any valid point. It connects the financial crisis with java for no particular reason.

"I think maintenance is improved when the cognitive distance between the language and the app is reduced, which is often easier in dynamic languages."

This is a theoretical point that contradicts Brooks' Mythical Man-Month: dynamic languages attack the 'accident' of software development, not the 'essence'. I still have to resolve the business problem, and that's what takes most of the time (meetings with the customer, testing, debugging, testing again, understanding the business model, rewrite and test again). I write new code only 25% of my better days.

To my taste, Rails penalize the debugging process and improves the writing of new code, which just doesn't suit my use case.

"I think maintenance is improved when the cognitive distance between the language and the app is reduced, which is often easier in dynamic languages."

This is a theoretical point that contradicts Brooks' Mythical Man-Month: dynamic languages attack the 'accident' of software development, not the 'essence'. I still have to resolve the business problem, and that's what takes most of the time (meetings with the customer, testing, debugging, testing again, understanding the business model, rewrite and test again). I write new code only 25% of my better days.

To my taste, Rails penalize the debugging process and improves the writing of new code, which just doesn't suit my use case.

Nick, when writing even the simplest SQL code into java, you will end up copying the strings from your SQL tool of choice and spend the next ten minutes formatting into the multistring thing (putting " + in place, indenting, etc). What they are asking is that the compiler does all the work. It only happens if you work with big strings, but when it does, it's a major issue.

I hate when people obfuscate their code just to keep some should-be secret sauce recipe to themselves. Most of the time they just put things in the way to debugging their own framework.

Last week I had to debug a NPE in a framework where the stack trace only included 'a', 'b' and 'c' methods. It's paranoid, if you are going to obfuscate your code, at least make it bug-free.

I hate when people obfuscate their code just to keep some should-be secret sauce recipe to themselves. Most of the time they just put things in the way to debugging their own framework.

Last week I had to debug a NPE in a framework where the stack trace only included 'a', 'b' and 'c' methods. It's paranoid, if you are going to obfuscate your code, at least make it bug-free.

I'm also voting down. This has been discussed countless times, google trends stats must be taken with a grain of salt. Your analysis includes JSF, which a little googling will show that includes Joint Strike Fighter more than Java Server Faces. Same thing applies to struts. "So... you voted the story down because you weren't sure about how Google Trends worked, but there wasn't necessarily anything wrong with the article?" Apparently, you don't understand how it works either. Dhananjay is right here, job trends are harder to misinterpret.

If you want support for java 1.4 for a few more years, you could switch to IBM JDK, which has a longer lifespan. Finding it is tricky, though.

OTOH, switching to java 5 is not hard at all, and you have the best of arguments to convince the PHB.

If you want support for java 1.4 for a few more years, you could switch to IBM JDK, which has a longer lifespan. Finding it is tricky, though.

OTOH, switching to java 5 is not hard at all, and you have the best of arguments to convince the PHB.

Bit shifts instead of multiplication is also an old-old-old technique that is dubiously applicable to modern microprocessors.

You also should not compare RIA and REST frameworks, they do not respond to the same criteria. I mean, how can you compare GWT and JSPs? They are not used for the same type of applications.

After examining LOTS of source code from every open source (and some not-so-open) project you can imagine, the SpringSource team wins hands down even when some of their projects do not reach the same quality level.

The only other contenders in the field are glassfish and the JDK (if we leave Swing out, please :), both from Sun.

After examining LOTS of source code from every open source (and some not-so-open) project you can imagine, the SpringSource team wins hands down even when some of their projects do not reach the same quality level.

The only other contenders in the field are glassfish and the JDK (if we leave Swing out, please :), both from Sun.

Modern log frameworks (not log4j) use varargs to avoid converting to String and String concatenation prematurely. This is old news.

A mixture between what is already there in stripes and loom Log classes. I like the idea of keeping it as a separate framework, but I don't quite like the printf format or keeping it hard-wired to log4j. With so many options (commons-logging, logback, slf4j, JDK logging) why are they forcing users to stick with log4j? (Not my case, I use log4j, but I know there are people out there who don't)

Maven has a good dependencies repository. That's the main (sometimes only) reason people keep using it. The rest of the ideas are questionable (crappy websites coming from default maven installs) and the implementation is just plain bad.

There is no chance of creating a competing repository, as the ivy guys learned some time ago. I like the ivy dependency system (it's quite superior to maven), but it should have been planned as a pom.xml embrace-and-extend instead of a from-the-ground-up effort. Currently, ivy users must understand ivy.xml AND pom.xml when something fails.

I always recall the same example: if you are a simple framework with several dependencies, maven will do fine. But ivy offers reasonable solutions for the spring framework that maven does not, and that has driven them to their current pom-hell.

Maven has a good dependencies repository. That's the main (sometimes only) reason people keep using it. The rest of the ideas are questionable (crappy websites coming from default maven installs) and the implementation is just plain bad.

There is no chance of creating a competing repository, as the ivy guys learned some time ago. I like the ivy dependency system (it's quite superior to maven), but it should have been planned as a pom.xml embrace-and-extend instead of a from-the-ground-up effort. Currently, ivy users must understand ivy.xml AND pom.xml when something fails.

I always recall the same example: if you are a simple framework with several dependencies, maven will do fine. But ivy offers reasonable solutions for the spring framework that maven does not, and that has driven them to their current pom-hell.

It makes some sense to me, since many frameworks are approximately equivalent.

People with experience in more than one or two frameworks are scarce. Since there is not enough time to assimilate the wealth of information, you select one with a big enough user community and stick to it. Learning another framework which does not have reported enormous productivity gains is not worth the effort. Imperfect knowledge, as applied to software economics.

There is a funny lesson about ecosystems I learned like ten years ago: if you leave a superior species inside an ecosystem (say, a lion in Australia), it may get a bigger share but the other species will not disappear. Call it imperfect knowledge, ecological niche, whatever.

For now, I think people who is happy enough will not try other options. They do not get payed for it. And the first try (and this is the important thing) is driven by personal taste.

It makes some sense to me, since many frameworks are approximately equivalent.

People with experience in more than one or two frameworks are scarce. Since there is not enough time to assimilate the wealth of information, you select one with a big enough user community and stick to it. Learning another framework which does not have reported enormous productivity gains is not worth the effort. Imperfect knowledge, as applied to software economics.

There is a funny lesson about ecosystems I learned like ten years ago: if you leave a superior species inside an ecosystem (say, a lion in Australia), it may get a bigger share but the other species will not disappear. Call it imperfect knowledge, ecological niche, whatever.

For now, I think people who is happy enough will not try other options. They do not get payed for it. And the first try (and this is the important thing) is driven by personal taste.

Hi Guillaume,

> Have you had the opportunity to work on a large project using a dynamically typed language to be able to come to this conclusion? I initially had the same a priori as you, but in practice, I’ve noticed that this was not the case.

I've developed with quite a bunch of javascript code, and I must say that not knowing the type of each parameter is a hell on the long term. If you take a look at Ext code you will see that a lot of comments are spent on specifying argument types. I am also grateful to generics for documenting the expected type of collection items.

OTOH, great article! I have also enjoyed it very much.

Hi Guillaume,

> Have you had the opportunity to work on a large project using a dynamically typed language to be able to come to this conclusion? I initially had the same a priori as you, but in practice, I’ve noticed that this was not the case.

I've developed with quite a bunch of javascript code, and I must say that not knowing the type of each parameter is a hell on the long term. If you take a look at Ext code you will see that a lot of comments are spent on specifying argument types. I am also grateful to generics for documenting the expected type of collection items.

OTOH, great article! I have also enjoyed it very much.

My case (loom): annotation-based, supports Spring, core taglib and ajax taglib, JSPs, etc. From scratch, it has been one year, six months working as a pet project and another six working mostly full-time. It would have required _much_more time if I had to coordinate with other people, and you are going to learn _a_helluva_lot_ in the process (one thing is to use a framework, and an entirely different one is to develop one).

I rely very little on third party libraries, and only when the quality of them has been well-proven. The parts that you will have to keep in mind are:

• property binding (HttpServletRequest-to-java and viceversa): I developed my own from scratch after seeing how much fun did the struts2 guys have with OGNL (well, that and because I wanted to fine-tune validations).
• workflow: where and how to configure interceptors. Nobody is helping you here.
• validation and conversion: You can spare some ideas from everybody else, but unless you pretend to use hibernate validations and the like (which I don't recommend) you will again have to roll your own.
• javascript support: This is a hell of a thing. There are so many options in constant motion that just choosing your bread-and-butter basement (ext, prototype, jquery, mootools, gwt) is a headache. Keeping your framework bare bones (no javascript helpers) is an option, I suppose - it's just not my case. On the other extreme is ExtTLD.
• security: keeping the bad guys out of injecting illegal values into your model objects or scripts into your HTML.
• reading your config: wether it's annotations, XML or spring support, it will not be magically developed.
• You _have_ to support injections.
• i18n all the way down.
• JSON support. Probably there will be some libraries here to help you.
• Flow control and conversation scope: I would seriously think SWF here.

Having said that, if I understood the question be sure that the world really needs it. You more than anyone else know that there are plenty of web frameworks out there. You will also get it easier if you have real requirements (real people in need of your framework) as soon as possible. They make great beta testers :)

My case (loom): annotation-based, supports Spring, core taglib and ajax taglib, JSPs, etc. From scratch, it has been one year, six months working as a pet project and another six working mostly full-time. It would have required _much_more time if I had to coordinate with other people, and you are going to learn _a_helluva_lot_ in the process (one thing is to use a framework, and an entirely different one is to develop one).

I rely very little on third party libraries, and only when the quality of them has been well-proven. The parts that you will have to keep in mind are:

• property binding (HttpServletRequest-to-java and viceversa): I developed my own from scratch after seeing how much fun did the struts2 guys have with OGNL (well, that and because I wanted to fine-tune validations).
• workflow: where and how to configure interceptors. Nobody is helping you here.
• validation and conversion: You can spare some ideas from everybody else, but unless you pretend to use hibernate validations and the like (which I don't recommend) you will again have to roll your own.
• javascript support: This is a hell of a thing. There are so many options in constant motion that just choosing your bread-and-butter basement (ext, prototype, jquery, mootools, gwt) is a headache. Keeping your framework bare bones (no javascript helpers) is an option, I suppose - it's just not my case. On the other extreme is ExtTLD.
• security: keeping the bad guys out of injecting illegal values into your model objects or scripts into your HTML.
• reading your config: wether it's annotations, XML or spring support, it will not be magically developed.
• You _have_ to support injections.
• i18n all the way down.
• JSON support. Probably there will be some libraries here to help you.
• Flow control and conversation scope: I would seriously think SWF here.

Having said that, if I understood the question be sure that the world really needs it. You more than anyone else know that there are plenty of web frameworks out there. You will also get it easier if you have real requirements (real people in need of your framework) as soon as possible. They make great beta testers :)

If you ever try a refactor hell that affects +100 classes, you will find @Override useful. After that, you even feel good when you see it around.

IMHO the problem with JSF is that every opinion fits one of these categories: * You hate it. * You have not tasted anything else (wicket, stripes, struts 2). * You sell JSF books or JSF products. Arguments like "If the author didn't bother to learn about those, then that's his own mistake" are not uncommon at all. ,