Fernando Lozano's Blog

The real motives why industry analysts love to predict Java fall... and why they will spend another 10+ years being proven wrong.

The real motives why industry analysts love to predict Java fall... and why they will spend another 10+ years being proven wrong.

When I found a YAAPJF (Yet Another Article Predicting Java Fall) featured on Java.Net, I though it would, for a change, provide useful insights on the problems we Java developers would have to deal with during the next years, as technology creates new opportunities, big corporations devise new strategies to achieve total market dominance and marketing hype diverts decision-makers from the real issues that makes dependable IT. But what I found was just another biased and badly-informed rant that adds nothing new on similar articles I've read during the latest 10 years.

The article repeats the old sayings about Java failure for desktop applications and Flash dominance as a web multimedia tool. But if you visit Dice.com, Google Trends or O'Reilly for a reality check, you'll see that Java still generates twice as much "market share" as the second-runner. As if web development were just about the browser, and enteprise or embedded development didn't matter.

I wonder why, after so many years of failed predictions, the so-called "industry experts" still insist that Java is doomed. My conclusion is that they (1) are serving their own interests (2) are being mislead by parallels with technologies that are from both a marketing and from a technology point of view radically different from Java.

1. We all know media and consulting firms needs new hypes to sell articles, conferences and reinventions of the wheel posing as new applications. A mature, stable and robust technology like Java limits their opportunities to cash. The web looked like the golden mine, with the promise for a complete revolution each year and a half, but no corporation can rebuild all its IS at such a pace. And fortunately they don't need to, thanks to Java. (To be fair, there are other web technologies, like PHP, that allows companies to build web applications and keep then running for a long time span. I have applications created for PHP/FI that still runs with PHP 5).

2. The IS arena was for a long time crowded with technologies that promised everything but world peace, but were replaced in just a few years by the next hype. Remember the 4GL languages, RAD IDEs and WAP? When I was at college, about fifteen years ago, Clipper was still the way to get a well-paid developer job; soon everybody was coding using VB under Windows 3.x; them PowerBuilder, Centura and Delphi were "the" solutions for IS development; but all they were left into oblivion by the web.

Enter the web era, there was a rush to learn Perl and CGI programming, which were quickly displaced by server-side scripting engines such as Cold Fusion, PHP and ASP. Even Java entered the wave with JSP. But only multiple-tiered development could deliver the reliability web applications needed, and soon everybody was talking about design patterns, MVC and frameworks like Struts. MS .NET did not had the impact they hoped for, and now the "market" seems to be in a quest to elect the new "must-use" development tool, with Ruby and Rails topping the bets.

Nothing against Ruby and .NET -- except the fact they are not Java ;-). I myself still develop lots of stuff using PHP, and I am also a good SQL Server DBA. But Java development is not about marketing hype. It's about building applications that stand the test of time and that can evolve to meet changing business needs.

The crazy state IS development was before Java was very convenient to lots of professionals and consulting firms that could not (or did *not wanted* to) deliver dependable applications. Their incompetence in building reliable software was masked by new looks, incompatible upgrades from development tools themselves, OSes and databases, and the novelty of each technology hype. Every customer was willing to live with a few reboots and lock downs to use the latest technology. Every one was eager to buy that networks and applications that would solve all their problems. And those professional / firms incompetency at building maintainable software was hidden by the need to re-create everything using the next cool technology. IS was the realization of the "motto continuum", the engine that feeds itself.

Now those professionals and firms are scared about the prospect of getting another 10 year of stability from the Java arena. I was at once reading articles and course material I wrote about Servlet development almost 10 years ago, and every word of them still applies. I took applications I developed 10 years ago for IBM Websphere (at the time named Lotus Domino Webserver) and run then under the latest JBoss release. Of course nowadays I want to use Datasources, JMX management, Hibernate and Struts/WebWorks. But the fact I didn't had to change any of those applications just to stay current with system software is remarkable by itself

For the most part, Java evolution was not revolutionary. It was additive (and adictive). There were few times new JVMs and APIs broke production applications (and programming mistakes accounted for most of them), and it was easy to solve the eventual incompatibilities. I can't imagine having this stability from my dark years as a Windows developer.

So the parallel between Java and previous IS development "best sellers" will lead to wrong predictions about Java being at the end-of-life. Java is much more like COBOL, which still powers some of the most critical IS, but with the advantage that with Java you don't need to stay frozen with IS technology as it was 30 years ago. Rest assured during the next 10 years there will be a great demand for development of new Java applications, not just maintaining old apps like COBOL programmers do today.

I don't want to go back to the previous state of playing catch-up with each and every new cool technology. Neither do any of my customers. Nowadays IT users are much more cost-aware and concerned with ROI. I really doubt most of previous development best sellers would have had any serious market share if IT buyers were in the past half as careful as they are nowadays.

Of course there are lots of people and companies that can't see times have changed. The fact is: we aren't part of a booming market anymore. IT is now a mature market. Sad for them. Good for us Java developers.

Maybe the best parallel to Java is the now decades-old Unix system. It's heir, Linux, is at the forefront of OS and networking innovation. That's where new developments and new research happens, and where more and more companies trust their mission-critical applications.

Comments

• A job well done.

  Thank you.

  Posted by: dfoster on September 30, 2006 at 01:09 PM

• Very nice Fernando.Every major new technology goes into a frenzy of differing short-lived approaches. Inevitably, a "mindshare dominator" emerges.Congratulations are definitely in order, to Sun, and to the entire Java developer community; job very well done! It clearly required a tremendous amount of work.I am very glad the hype machine, aka the "industry experts," are looking elsewhere; much as the GNU/Linux community was finally relieved to get out of the hustlers' spotlight.Now that all the noise about Java is dying down, we can really get some great work done.

  Posted by: cajo on October 01, 2006 at 11:14 AM

• Rails is a great name for the framework. Great if you want to get between two straightforward destinations quickly - hopeless if you want to go to anywhere where the tracks haven't been prelaid.

  Posted by: bellbux on October 02, 2006 at 06:40 AM

• Despite hating trade analysts and their ivory tower analyses, I do think the Java-is-losing-steam argument has a point.

  When was the last time anything innovative happened in the Java space? Java was innovative to begin with. Be it with the applets (in those times), Servlets/JSP - using compilation for speed, fully powered language for Web development, RMI- easy Remote object invocations etc.

  Cut to the present, we're trying to play catch up with the competition - be it adding varargs, Attributes (annotations), easy for loops and closures etc. Java is definitely not dead. But has lost the leadership when it comes to innovation and pusing the boundaries

  Innovation died the day Sun put Java at the mercy of JCPs, formalizing a well-known Anti-Pattern Design By Committe to decide Java's future.

  And the fruits of these various JCPs/JSRs have been disasters. Like Java Logging (who uses it?), Entity beans ( mother of all disasters), EJB 2.x etc. The amount of boiler-plate needed to write JDK 1.3-1.4 per Sun standards is unbeliably painful. Thanks to competition from C# we now have atleast have annotations to ease the pain (a little)

  JSR death-march continues pushing Big Balls of Mud like JSF. I can't believe they spent 2 years to define that complex BBoM, which doesn't support Ajax by default, forces developers to write custom components to support latest web technologies, and -- to make matters worse -- it's impossibly painful to extend JSF. Not supporting JSP code, other tag libraries, even JSTL is the last nail in the coffin of JSF. So much for the claim of 'Compatibility' to older technologies

  Why didn't Sun bless more stable Tapestry? Heck even the latest newcomer Wicket framework beats JSF handsdown in it's simplicity. Sun's Not-Built-Here attitude in killing Java. Life would've been easier if Ant, Maven, Log4J, Jakarta Commons were distributed as part of JDK ( can't really program Java without them!). Ditto for Struts which should've been part of J2EE long time back.

  Comparisonwise, Linux is growing because of the Open-Source 'Innovation Happens Elsewhere' philosophy. Java is losing steam because of the 'Not-Built-Here' obstinacy.

  Posted by: vivekbp on October 02, 2006 at 08:08 AM

• I disagree 100% with vivekbp. What do you call "innovation"? Scientific research? That's not "language specific". Throw away all your code and start from scratch? That's more like a college student wish.

  Java is adapting quite well to the new demands of the users, we have lots of incremental improvements. That's the natural way given the maturity of the Java platform. Java would be dead if we were stuck in 1999, and that's clearly not happening.

  So you like to see radical breaking changes from version to version? Rest assured that if .Net had 90% of the market MS would do the same as they did with IE, i.e. nothing. The only reason MS and opensource projects are "free to change" the way they see fit is because they have a minor fraction of Java's adoption. So, a little quantity will care if anything breaks, and they must be quite used to it.

  God, until when people will cite EJB 2.x!? This must be a good sign, if people are stuck at that version it means they don't have much to complain about the new stuff. BTW, I use the logging API. It's a good API, you would one way or the other use one logging API. It's better if it's bundled in the JVM, so you don't depend on half of Jakarta.

  JSF is an attempt to fix the web development crapland by introducing server-side components a la ASP.Net. It's a good thing to make people's life easier. Working with a web application the same way you did with CGIs it's far from good.

  If you mean specific problems of JSF, instead of "the whole concept of componentization sucks", then, yes, I agree JSF is not good at some points, but would you expect perfection from an early version (I didn't check 1.2 yet)? Those things tend to be ironed out as the new versions come.

  PS: It seems people have standardized a group "Java rants". whenever you see someone complaining about Java, IT'S THE EXACT SAME LIST OF ARGUMENTS. Could you please leave EJB 2.x behind? It's not needed in most web applications, if someone used it either they had a very good reason or had no clue of what they were doing!!!
  

  Posted by: thiagosc on October 02, 2006 at 09:50 AM

• @thiagosc : Innovation is creating/changing something in a radical way, that makes peoples lives easier - scientific or otherwise. Innovation is not just limited to pure Science, it can be in any other field too like Art, Architecture etc.

  Java is , indeed, making improvements. Every platform does it. Even Ruby is coming up with version 2.0 It's just that the mantle of LEADING the change, that has got passed on to others.

  
  I hate to say it. But there's a stronger tendency in Javaland to stay COMPATIBILE with the Obsolete, than in changing to break new frontiers in computing.

  COMPATIBILITY has become the favorite bogeyman of Java apologists, whenever Java gets flogged for slobbishness. They conveniently forget thousands odd warnings the old 1.4 List, Map uses cause with 1.5. Or hundreds of real bugs that remain unfixed lest they break someone's Compatibility somewhere.

  Compatibility to a certain limit is good. But beyond that it simply sucks. It is sensible to remain compatible with minor releases. I don't see breaking compatibility with major releases, if the benefits are significants. Also compatibility versions can be maintained till the changes become mainstream.

  I would rather fix my code that got broken with a vaild Java change, that gives me significant benefits, rather than write complex, lengthy and unnatural code to maintain compatibility with some long-obsolete way of coding. Those who don't wish to change can stick to older Java versions, till they get ready,, while the rest of us can move forward and enjoy the benefits of these changes

  
  To give a real world example - Dinosaurs remained compatible, and ended with the Jurassic age. Humans broke compatibility with the Apes, by walking on two legs (instead of four) and dominated Earth in less than 20,000 years. So much for Compatibility vs. breaking compatibility

  EJB3 is out doesn't mean 2.x suddenly became dead all over. EJB 2.x is still a reality in most J2EE servers that run production code. EJB3 is yet to become the mainstream norm.

  I don't think you read my comments on JSF with a clear mind. I am not against 'Componentization'. Componentization is good (otherwise I wouldn't mention Tapestry, Wicket - both first class Component based frameworks). It's just the way it's been over-engineered in JSF, that sucks. It took 2 YEARS to implement JSF - it's like Eons in Internet Time.

  For all the War-cry and Chest-thumping of Compatibility that I hear, JSF isn't compatible with JSTL (a J2EE standard). For something that took like 2 years, has innumerable quirks and limitations and simply-too-complex for average Joe programmer.

  OK, JSF will come with all nice features in the next 2 Years ( given the time it took to implement first release). What are, we, Java programmers supposed to do till then? Resign our jobs and stay at home to raise children, while the competition laughs all the way to the bank with latest Web 2.0 features.

  And by that time technology would've moved to Web 3.0 or 4.0, and Java programmers (if not already extinct by then) would be coding Web 2.0 version of JSF like Neanderthals. Can there be a better-than-this vision of JSF dystopia?

  True, EJB is not needed in most Web application. What afterall is EJB, but RMI with a few bells and whistles?. But wasn't it Sun that pushed EJB technology as the platform to implement the so called 'Business Layer' and created countless so-called architects who -- used to -- swear by it. So they deserve a good portion of the flogging they receive
  

  Posted by: vivekbp on October 02, 2006 at 02:54 PM

• First, what nonsense is that of "Dinosaurs"!? What does it have to do with technology!? In order to see the picture clearly first we need to speak sense by using the thing that differs us from the rest of the animal kingdom, the reason.

  So, if Java is "leading" the change or not is a matter of opinion, purely opinion. There're no numbers to that. You may have got enamorated of competitors solutions, but that's no ground for making such broad claims. Besides, as I stated earlier, and I believe every thinking person would agree with me, is that MS is updating .Net like crazy because they are in the confortable second place and want to supercede Java, if they were #1 we could forget any updates, just like IE. Opensource? hahahaha. Linux is perfect example of opensource anti-design.

  What's fun is that most of "innovation" that is done somewhere else is that they are things older than myself. So DSLs are innovation? Ok, let's wait until your environment turns into a nightmarish Unix-sendmail-conf-file land. Closures are innovation? I bet half of people that talk about it didn't know what it was until a weeks ago, and that's yet another way of doing abstraction. Web frameworks? Java has a huge amount of it. So, what's new in this so-called innovation?.

  The compatibility commitment is one of the reasons of the popularity of Java, and it's the difference between life or death in facing competition from Microsoft. History has shown that a fragmented platform is doomed to lose. (Unix anyone?)

  Incremental improvements is by no means blocking evolution, IT IS EVOLUTION. But instead of throwing everything away, it's done in a more realistic way. The truth is that reinventing the wheel somewhere else is convenient for some consultants and firms.

  Please move on from the "EJB argument". What kind of people use whatever the marketing guys say? If someone is stupid enough to use something he doesn't need, just because someone said so, then that person deserves what it gets. The argument of "marketing from Sun" is not an excuse for stupidity . EJB is by no means an indicator of Java web development tools. Period.

  BTW, do you really know JSF? Do you have any experience with it?

  PS: I have the impression the people the most eager to break compatibility aren't decision makers or architects whose job is in the line. Talking is cheap, kids.

  Posted by: thiagosc on October 02, 2006 at 05:08 PM

• If all it took to stay the market leader is always following every hype Cobol would have been dead 20 years ago, yet last I heard over 50% of the planet's codebase (and most of it the stuff that runs mission critical systems at major corporations and government departments, so the systems without which our economies would instantly collapse) is still built in Cobol and you can make a good income with a very steady job writing Cobol. In contrast, all the massively hyped things like php and ruby are fringe items.
  And yes, most of the "java is dead" articles and books are indeed marketing for something else. Most striking example today is Bruce Tate. Once one of the leading Java advocates, from one day to the next he publishes several books completely dissing Java and hailing the glory of Ruby. Few months later it's revealed he's a leading figure in a Ruby focussed company. Most other, similar, articles and books have a similar origin no doubt, when not the writers themselves then their sources.
  Of course Java won't last forever. Nothing does. And maybe it will sooner rather than later stop being the preferred tool for new people to put on their list of skills and for hype sensitive project managers to choose for their projects, but that might actually be a good thing as it may at last bring to an end the mad rush to add everything and the kitchen sink to the platform in order to keep the Ruby, Python, and C++ coders happy who scream that "Java is crap" because "it doesn't have XXXXX" where XXXXX is some favourite feature they may not even understand the consequences of.

  Posted by: jwenting on October 02, 2006 at 08:47 PM

• 
  Following the advice of the Pragmatic Programmers, I've tried learning a new language every year for the past few years. It's expanded my view of the limited universe of Java in a few ways, but on the other hand made me appreciate the core simplicity of Java.

  
  There's pretty much only one way to do something in Java, and it's all there in front of your face, right where it's happening. Sure there's AspectJ and Spring Aspects, but people rarely use those. In Ruby (particularly Rails), there's tons of filtering that you do with the before_filter, after_initialize, after_create, before_create, etc. Everything that's going to happen in a method happens right in that method, not off in a complete other module, class, etc.

  
  Nothing is hidden or happening magically in the background. There's CGLIB, ASM, and the like, but developers tend to use just a dabble here and there, mostly to avoid some reflection. In Ruby and Lisp, you can pretty much rewrite the language. C++ lets you change the meaning of operators. In Java, a + is a + is a +.

  
  There's almost no "syntactic sugar" to make your life easy in Java. Sure, we've got the new for loop in Java 5, but there's nothing like closures or inline conditionals. In Ruby, you can have the following statement:

  
  dog = (found_dog && dog_object) || Dog.new

  
  where if found_dog returns true, dog is set to dog_object, otherwise a new Dog object is created. This makes for some incredibly powerful, concise code, if you know what you're doing. Things like closures really make your life easy, unlike anonymous inner classes. Not quite as elegant.

  
  Finally (for this little post, not necessarily this discussion), Java is Java. Developers don't tend to extend the library with calls to C, Ruby, Python, etc. I've seen little scripting used in Java, such as Jython or LuaJava. There's also very few times I've seen anyone use JNI to bridge to a C library. Python and Ruby do it all the time, especially in areas like XML.

  
  While it may sound like I prefer Java, these days the opposite tends to be true. It's too verbose, too limited, too constrained to a single pattern. There's a tendency to let Java do everything. I think this comes from its simplicity. Java is the new BASIC, or maybe Visual Basic: it's easy to learn, straightforward, and there's little room for error. With tools like Idea and Eclipse out there, it's hard to mess things up. My Java apps tend to always compile right out of the box--which can be misleading.

  
  Sure Java is consistent and easy to maintain, but it's also not very powerful as a language. It's fast, yes, but it takes a lot of typing to get things done. It doesn't really help the developer along, it really just stops the developer from doing anything creative (or crazy, I'll admit). I think of Java as a good introductory language and powerful server platform, Python as a language you do the day to day tedious, data-processing stuff in, and Ruby as a language you build web apps quickly with.

  
  And that brings me to my big problem with the Java community: do everything in Java. It wasn't until I got away from Java that I really saw how entrenched the "silver bullet" theorists are in the Java community. Here's some areas of Java I have problems with these days (sure to cause a firestorm):

  
  Instead of SQL, a tried and true query language, let's write our own and call it Hibernate. Sure, SQL's been around forever, and it's pretty standard now (MySQL, PostgreSQL and Oracle at least seem to be pretty similar). Hibernate will bind everything together for you too! That is, once you've worked out the hbm.xml. (For any SQL gurus sick of Hibernate, try iBatis; much better.)
  Let Java cache your SQL objects in memory! Sure, Oracle and PostgreSQL have great query caches, but don't use those. Waste your JVM heap instead! I'm sure Java is faster than Oracle at this kind of thing anyway.
  Don't use stored procedures; they're bad and lock you into a single database solution Of course, I can count the number of times on one hand in the last ten years have I ever deployed to more than one database server, and that was PostgreSQL and Oracle, which are pretty much identical for my needs anyway. Along the way, ignore the nice speed increase for complex query processes you'll get from compile procedures.
  Don't write Java in your JSPs: create a new set of HTML tags that are completely redundant instead! That way you can pretend you're not writing code in your page, even though you are (JSTL anyone?). As opposed to Ruby, which just uses Ruby in the template and tells you don't get carried away with code in your page. To be fair, I just use Java in JSPs and ignore all the gurus who tell me I'm doing a "bad thing".
  Ignore every other language on the planet and write it in Java. Great C library? Translate it to Java and just run it in the JVM. Need help from an existing Python or Ruby app? You've got a better change there with Jython and JRuby, but I've rarely seen those embraced seriously, at least not at any company I've worked with.
  There's no best tool for the job mentality; it's all one size fits all. Perl is better at string parsing (Java's regexp is a joke). Ruby/Rails is better at building web frontends. I'd bet Python-XML is probably a little better that Java at parsing XML, just because it's using the libxml C library instead of a Java library. Even in the Java community SWT is better than Swing, in my opinion, but that's because I come from a traditional X-Windows and MSVC/Win32 background.
  Finally--and this is a big one--let XML run rampant over your application. Don't code in Java anymore, let Spring and dependency injection integrate your app. Who knows when you'll want to change out a bean (never would be my guess, but your mileage may vary). Not that anyone else but a Java/Spring developer could modify a context XML file. XML is for talking between disparate systems, not programming an application.

  
  I think Java just has a nice low barrier to entry that appeals to developers. There's also a simplicity there that keeps maintainability high. That's a good thing, I admit. I just wish some of these bad ideas I've mentioned could work their way out of the community and open up Java to be a truly advance member of a greater programming community. I think it's the reason you see developers moving away from Java to other languages: they want to expand beyond a single horizon and see other skies that are just as beautiful, each in their own way.

  
  One final thought: I read an interesting article online recently about Java versus Ruby, and one point that really hit home is that most Java developers these days use an advance IDE like Idea or Eclipse to help them code all the redundant, repetitive bits of Java, whereas most Python or Ruby developers use simple text editors. What does that say about Java?
  

  Posted by: pico303 on October 03, 2006 at 01:23 AM

• Ok, a few thoughts:

  - I have been using Perl for some time now and I can guarantee that crap isn't good for anything! Saying that Java is limited and we should use "other languages" such as Perl is only a demonstration of ignorance;

  - The example you gave (this || that) is doable even in Bash. That's what I find ridiculous, people arguing over such meaningless syntactic sugar. What does it add in the big picture? Nothing

  - We are in the XXI century. It takes more than a language and "vi" to accomplish something, languages alone are useless. Developers, us, don't develop everything from scratch. A complete platform with library, IDE, language and specific solutions is needed. So stop comparing languages, it's not realistic. I have learned a few only to learn that the most complete platform is Java;

  - multi-language codebase is bad for maintenance;

  - The amount of users of Hibernate and Spring is a minority of all Java developers;

  - XML was abused, as well all the current hype will be, the main offenders are EJB 2.x and Spring. But you aren't required to use them;

  - Mixture code in the view leads to maintenance problems. I think everyone should know it by now. I believe a componentized (VB-like) interface is what we need for developing for the web;

  - Your last example (Java + IDEs) shows that we are in the XXI century, some other people still believe to be in the 80s by writing every piece of code by hand. We should look forward not look back! I don't see an artist complaining about the use computers in animation and arguing that doing everything by hand is better! So why do we have such ludites in IT? IDEs do far more than just code-completion and auto-generate getters/setters.

  Frankly, as a developer I expect a minimum level of quality of the tools I use. Java has it. .Net has it. Ruby doesn't have it. Python doesn't have it.

  Suggesting that we should go back to the dark ages of Unix, with a huge number of conf files readable and writable by hand (DSL anyone?), using "vi" for everything, and living in a mess of a platform is crazy. Java has risen the bar of "the minimum a platform must have". We need to make it every time higher not lower. I wouldn't object to change to another platform that were more complete than the Java, but moving a crappier platform? For Christ sake, why to reinvent the wheel?.

  Posted by: thiagosc on October 03, 2006 at 06:32 AM

• @thiagosc: Don't want to get into perception arguments as, I can see, we differ in our views. We can argue forever without convincing the other party.

  Coming to your specific query about my JSF knowledge, I did try to use JSF in my recent project based on Architect recommendation - it was a Sun Java standard and part of J2EE ( a la EJB). Too put it mildly ,it was a horrible experience. For a technology that aims to be VB-for-the-Web there was no tool support (GUI builder). No JSTL support. No Tree, TreeTable components.

  Since Sun RI doesn't provide much beef, we decided to use "MyFaces" based on architect recommendation. It was a hellish experience. Of course, we could've gone for something commercial too. But in the Fortune 500 company, that I work for, it would take 5 years to get approval for anything that needs a Commercial Licence. And we had delivery dates like yesterday!

  MyFaces is the most undocumented and quirky piece of software, I've ever seen. I had to extend TreeRenderer to support 'Drag & Drop' (using scriptaculous). It gave me the glimpse of JSF guts that average joe programmer isn't - normally - supposed to see. Lesson Learnt - It's highly painful to extend a Component in JSF. You need to extend the UI Component derivative, provide a Renderer, handle the 5 phases correctly etc. Then you need to provide a Tag library to expose your component! You can't have a Renderer per component ( JSF allows only one per Component type). I had two trees with different needs ( drag-source and drop-target). So had to define two components.

  Pain didn't end here! For every node click, the whole page gets refreshed. Form submission is the only available mechansim in JSF, even for simple Links ( JSF demands every component to be the nested inside a Form). Routing node-clicks through AJAX to Myfaces was night-marish (to say the least).

  That's just part of the story. In the next page, I had to flatten the tree into a Table, with subgrouping and subtotals (per department), with User configurable visibility of columns, ordering of columns etc. In a Nut shell - dynamic "Rendered" attribute ( there was , but some columns draw differently) , and Nested tables ( no way to do this in JSF except implement a brand new component from the scratch).

  It took me a month of rigorous coding and immense pain, to reach the conclusion that JSF doesn't meet the challenges of ever changing user requirements.

  Instead of re-inventing the wheel, and thanks to Java.net, I found Wicket, which already did support Ajax-based Tree. And despite being an absloute Wicket-nube (but an experienced programmer), I could implement all these features -- and much more -- in a week's time.

  It was not just the Wicket vs MyFaces feature difference, the whole architecture of Wicket is so simple, I could grasp the concepts easily and turn it into code in no time. Sure, Wicket has it's quirks, but nothing comparable to JSF in magintude.

  It made me question the premise that Component-orient frameworks need to be Complex like JSF. If Wicket can keep it so simple and powerful, why JSF needs to be so complex? (except that it got over-engineered?)

  Coming back to the main story, my Project Manager was happy that we could meet the deadline. Everyone ,except the 'Standards-Standards' architect. The solution was easy. I asked him to prototype the features in JSF *himself*, and prove me wrong.

  In no time, he made a U-turn and supported me. As I've read, here, in Java.Net - There are Coders, and then there are BSers. It's mostly the BS'ers who keep pushing for Complexity, be it EJB or JSF, where as, it's us, coders who try to KISS things ( we've to get home early too!)

  Gist of the story - my frustrations with JSF are based on my own real-life experience with it, and other Component-oriented frameworks. Of course YMMV.

  
  

  Posted by: vivekbp on October 03, 2006 at 07:15 AM

• @ thiagosc :

  You said -

  
  The amount of users of Hibernate and Spring is a minority of all Java developers

  Please, take a look at the recent Java.Net poll to correct your misconception

  Posted by: vivekbp on October 03, 2006 at 07:24 AM

• Your mistake was try to use JSF without an IDE (and there're a few of them around). It was made to be used by tools. JSF has a component model just like Swing, it's just a matter of learning how it works. You may think that it's too much overhead, but I believe this is part of the learning curve, after that you can be faster. The same way you'd take some time to learn how to customize Swing components.

  So a MyFaces is quircky and you are complaining of JSF? If this project in specfic is crappy then it has nothing to do with JSF.

  BTW, I am using a different implementation of JSF than Sun's and I had no problems so far. I think it is simpler than Struts for example, and Struts, for good or bad, it's a kind of "industry standard".
  

  Posted by: thiagosc on October 03, 2006 at 07:28 AM

• @vivekbp:

  You said:

      Please, take a look at the recent Java.Net poll to correct your misconception.

  I believe the Java market is bigger than java.net. Usually the people around here is of the "blog reader - hype follower" type. I am still to see a single project using Spring, despite of all the hype. In the other hand I have found a huge number of projects using Struts, just to name an opensource framework.

  Posted by: thiagosc on October 03, 2006 at 07:34 AM

• @thiagosc:

  I use an IDE IRAD(Eclipse) which does provide rudimentary JSF support. IDE support was of not much value to me as it didn't help. It would've been, if JSF had a standard Tree Control, standard Drag-and-Drop support etc.These features are considered standard these days in a Web 2.0 application, whether the so-called "standard" Java framework supports it or not

  I repeat - I'm not blaimg JSF for all MyFaces problems. Some of them have to do with the crappy MyFaces implementation. Others (major ones) are due to the JSF way of implementing and extending components.

  JSF may be state-of-the-art compared to Struts. But comes nowhere near Tapestry, Wicket or Echo in supporting features considered standard these days in a modern web application.

  Apropos comparison to Swing, IMO JSF is philosophically more closer to VB, PowerBuilder, ActiveX etc. i.e. more suited to drag-and-drop style development. I do like Swing as it supports both drag-and-drop development as well as easy extensibility of components. In fact Wicket has a component model very similar to Swing. If you know Swing, you can learn Wicket in no time.

  I am not a Wicket developer or part of the Core Team. If today, I, feel so passionate about it, it's due to it's simplicity, extensibility and richness (batteries included). I love a framework which doesn't get in my way, lets me do my job fast and easily, without requiring me to deal with the messy cruft.

  It's the same freakin' job, whether I do it in Struts, JSF or Wicket. Standard or no-standard, why should I sacrifice precious moments of personal life, working around complexities created and left unsolved by some maniacal, egotistic, Fascist Framework architect/designer?

  Success of a tool/framework depends on it's ability in creating Passionate Users ,and not in it's ability of scaring way potential users , likeme, by it's complexity.
  

  Posted by: vivekbp on October 03, 2006 at 08:33 AM

• i have used JSF in the real world (i.e. a real contract that pays my bills)
  it was the most crap-tastic POS i have ever had the displeasure to use.
  it was so bad, i now refuse contracts for projects that are considering JSF.

  Posted by: ofuckit on October 03, 2006 at 09:44 AM

• I believe people tend to get too emotional about such things, for no reason. I will check out JSF despite of the disencouragement before getting to any conclusion because, frankly, the "open-sores" community if full of "passionate" opinions that has less to do with reason than with ideology or consultant "reinvent the wheel" scheme.

  Posted by: thiagosc on October 03, 2006 at 11:23 AM

• 
  thiagosc, you kind of missed my point with the IDE question. It's not that you want an IDE to be productive, it's that you NEED it to be productive. I'm no Ruby or Python guru by any means, though I do know Java backwards and forwards, and I can be more productive with Ruby and a text editor than I can be with Java. It's cleaner, more concise, and as a bonus, flows more naturally, e.g. 7.days.from_now, 3.times { |index| index += 1 }, etc. Check out:

  attr_accessor :name, :street, :city, :state, :postal_code

  to see what I mean. In that one line of Ruby, I just did the equivalent of:

  private String name;
  private String street;
  private String city;
  private String state;
  private String postal_code;

  public void setName(String value) {
  this.name = value;
  }

  public String getName() {
  return name;
  }
  ...

  This and most other syntactic sugar doesn't add anything; it just takes it away. Why do you have to have a bloated IDE to fill in the pieces that could just as easily be built into the language? Why not make it easier for others to read your code? What's wrong, are you paid by the line or something? Personally I'd just like to get things done quickly and efficiently.

  As for using other technologies, again, there is no silver bullet! There is no one tool for every job. If the guy who built your house only used a hammer, you'd be in trouble. Talk about uneven corners! I was talking with friends today--other Java developers--about the "bubble" of Java development. Don't stray from the bubble, everything stays in the bubble.

  Say I need to parse a CSV file into a database. Java developers will tell you to do it in Java, which will probably take about an hour of typing, compiling, executing, typing, compiling, executing, usw. Or just do it in Python, which will probably take you about 15 minutes, thanks to better CSV parsing, regular expressions, and string handling--not to mention your despised "syntactic sugar". Don't use JDBC, Hibernate is much easier for OO. Don't forget to tweak those HBM configuration files! That should double your development time...

  Want to run it nightly? I'm sure you'll probably suggest I use QuartzTimer, instead of the far simpler, more stable, less resource-intensive crontab. Is QuartzTimer painful to setup? Well, use Spring, it has a nice wrapper for it! And if you built your application right you should already be using Spring for dependency injection. I don't know why, but that's what the Spring guys tell me: the only way to code is dependency injection! Now I've gone from a short script and a line in /etc/crontab running once every 24 hours to a 50 MB app running constantly. Do I do it all in Java, or just pick the best tools for the job and get it done in a tenth of the time with fewer bugs cropping up?

  Most companies you'll find out there use a multitude of languages. Coming from a CS background, you're exposed to a wealth of tools, some good, some bad. Some good at one thing, others good at many things. I'm not saying Java doesn't have its place, just that its place isn't spread out over the entire map of software development. Map Reduce (of Google fame) is kind of painful in Java. Sure, it can be done, but there are better languages to do it in. If you look at Google, Yahoo, IBM, Amazon, even Microsoft, there are many languages used in those companies to get the job done: C++, C, C#, Java, Python, PHP, Ruby, Perl, Lisp. Do perhaps they know something you don't?

  Sure, standardize on a few things. Just don't put Sun-built blinders on.

  Anyway, I hope your arguments don't mean that you don't know another language or care to. It sounds like you know bash, at least. I found looking outside the bubble really cleared my head and helped me when I had to get back in. Yes I still program in Java, yes it's a great language. I think most of my problem comes from the direction of the community and perhaps the Sun influence in the direction the language has grown up. I'd like to take it out of the hands of academics (JSF, J2EE, Rhino, Swing) and put it into the hands of people who depend on it to get a job done.

  
  

  Posted by: pico303 on October 04, 2006 at 09:25 PM

• pico303. An IDE is not an option in the XXI century, when will proponents of other languages realize that? IDEs aren't only for code-completion, you integrate a bunch of tools in it. Some help coding, such as refactoring, some others help with specific types of software, such as DBs, webservice testers, version control systems, documentation, etc.

  Your example is meaningless. It doesn't do the code less or more readable, and it's not an excuse for not having an IDE. A platform for software development must include besides the language, the library, the IDE, the docs and specific tools (such as Java EE in Java).

  Besides your Spring example illustrates perfectly what is wrong with Java-bashers, THERE'S ABSOLUTELY NO NEED TO USE SPRING. DI is a flawed concept, you can't eliminate dependencies, Spring just obfuscates it, hides it.

  There's absolutely no problem in using JDBC and populate beans automatically with something like DBUtils. Hibernate is not a requirement.

  About your examples about CSV parsers and small apps, I know what you mean and I know how this story ends. It ends in a sea of small scripts, code duplication, and maintenance problems.

  In big enough companies each department is like a different company, and they will use whatever they need. What's the point of citing "multitude of languages"??? They aren't bound to a single project and a single architecture, they use them in many different systems, and when integration is needed they work on it. Many languages in a single achitecture is a mistake and leads to code duplication.

  "crontab" is just an application, what does it have to do with development environments? And why it would be a problem?

  Conclusion: An IDE nowadays is not an option, it's a requirement for any development environment. It doesn't matter how "easy" a language is, a complex enough system will be a pain to work with in notepad!!!

  BTW, this Spring malware is the #1 way of scaring people away from Java, and it's an utter nonsense.

  Posted by: thiagosc on October 05, 2006 at 10:35 AM

This work is licensed under a Creative Commons License.