Home

News: "Java is losing the battle for the modern web"...

  1. On a mailing list known for "straight talking," Simon MacDonald pointed out a blog post from Andi Gutman, with the title "Java is losing the battle for the modern Web. Can the JVM save the vendors?" It's an interesting and challenging post from one of the founders of Zend Technologies. Why is this post relevant? Well, for one thing, as one of the authors of PHP, Andi can be described as being someone with influence – look at how many MySQL errors people can describe with Andi's work product. More seriously, Andi makes a lot of points about dynamic languages on the JVM, now getting a lot of traction from nearly all quarters.
    ... Lack of strict typing, scripting performance, and other reasons were given for why Java would persevere as the language of choice. This was the typical reaction dynamic languages would get from the Java community. There were many believable reasons for why these languages, especially the ones gaining fame on top of the LAMP stack, would not last. However, one thing which the Java community ignored for many years was the radical shift to the Web, not only for media and e-commerce Web sites but for a large majority of business applications including CRM, ERP, reporting, document management, etc… As a result Java EE (then called J2EE) was not built with the Web in mind but rather focused on enterprise integration, transaction management and other back-end processing. While Java EE has long supported Web development with servlets and JSP the companies driving the standards ignored the RESTful nature of the Web and rather continued to drive a general purpose platform. In parallel, the LAMP-like architecture built on top of the C language's eco-system of libraries and tools started becoming the most popular platform for developing Web applications.
    The response to this by the Java community was to standardize:
    When it became apparent to the large Java vendors that the Web paradigm was being built and innovated without Java they started backing a variety of both standards and non-standards driven Java Web application frameworks which promised to adapt Java to the Web. Such frameworks included Java Server Faces, Struts, Spring MVC and others. Some of these frameworks have been more successful than others but in general none of them managed to resolve one of Java’s main pain points on the Web. The strict typing and overly complex architecture of Java applications meant longer development times and a need for more skilled engineers in order to push Java applications into the market, i.e. Java's TCO on the Web was unsatisfactory.
    Andi makes a few references to Java "holding the stick at both ends" - wanting to be part of a paradigm shift and wanting to protect their business, not supporting dynamic languages until Microsoft emerged with the CLR. One can assume the languages supported on the JVM before the CLR existed were mere figments of the imagination, I suppose... but there's also little argument that they weren't largely suitable for "real deployments" at the time. Wanting to hold his stick at both ends himself, Andi continues:
    the LAMP deployment paradigm has significant advantages. By featuring a multi-process architecture, faults in the Web Server and dynamic language software will typically not lead to sites going down. While one process may crash all other processes serving Web requests will continue running. This is in contrast to multi-threaded environments like the JVM (Java Virtual Machine, Java's execution environment) where software faults including crashes and deadlocks will typically lead to system down situations. In addition, the ability to recycle processes after a set time will prevent memory leaks and memory fragmentation, two common software memory problems, from degrading the system efficiency over time. Another key advantage LAMP developers enjoy is the easy deployment paradigm. Software updates can easily and incrementally be pushed out to LAMP servers without requiring prolonged build and packaging processes. While this may lead to unorthodox and sometimes too lax of a process, when done correctly it makes the lives of the developers and the operations personnel much easier.
    It's a little disingenuous to say that the light nature of the LAMP processing stack is a benefit because crappy code is easier to endure... and then say that the lack of formality is a strength if you don't rely on it. The intent seems to be to say "sure, we enable crappy programmers, but they don't have to be crappy, so we can say we have good programmers too." Andi says that the question is whether the non-Microsoft development environments will "buy into" the JVM implementations of dynamic languages or whether they will "move to the LAMP stack which hosts the de-facto standards for the popular languages." He says that the majority will go with LAMP, pointing out that:
    • "The JVM ports of these languages will always lag behind the community-driven standards implementations." This is entirely safe, and not quite valid: Jruby and Jython are not fully compatible, but they're also very active in the Ruby and Python communities, and they're targeting being full-fledged members of the community. Much like Java, Python and Ruby are standards, not implementations, whether the LAMP advocates like it or not – and as pointed out elsewhere on TSS, in many ways the JVM is a much stronger platform for these languages than their C environments.
    • "The JVM was not originally designed to host dynamic languages." Hard to argue that one, because it wasn't; that said, the JVM has been known to adapt every now and then. The JRuby guys being hired by Sun was a great move; they've been helping drive changes in the JVM to give it better support for elements that dynamic languages need.
    • "The scalability requirements of the modern Web will require an increasing amount of processing density on the Web tier." C-based languages have the highest density of processing power, he says, and while that's difficult to argue, he's still holding that stick of his on both ends. The JVM is C-based, after all; his point is meant to be that PHP is directly C-based and thus has all the benefits of C, while the JVM is... not C-based and thus doesn't? Perhaps his judgement is impaired by thinking that PHP is closer to C than Java is. Or perhaps he's just confusing the heck out of me. In any event, if I need more processing power from a Java application, I'll use a compute grid like Terracotta, GigaSpaces, or Hadoop, or any other of a number of offerings, and not have to change languages unless I want to.
    • "Multi-core systems work very well with the LAMP stack’s multi-process paradigm. With the chip industry now focusing primarily on multi-core as opposed to hyper-threading technology, the benefits of multi-threaded environments such as the JVM are not substantially realized on today’s hardware. Instead the multi-process paradigm delivers more stability and reliability." Yes, it's very sad that the JVM is unable to take advantage of multicore machines.
    • "Due to its simplicity, the LAMP stack delivers a very low barrier to entry for developers while still delivering the scalability of large scale production systems such as Yahoo! and Facebook." This is probably the most valid point he makes.
    His conclusion is this:
    I believe that while the JVM approach to dynamic languages may appeal to some Java customers it will never be able to catch up with the broader open-source movement around native dynamic languages implementations. The JVM dynamic languages implementations will not be enough for the Java vendors to catch up and they will need to embrace the native de-facto standard community driven dynamic languages.
    Interesting stuff, and the mailing list to which the URL was originally posted has some very interesting content itself; that'll probably find its way to TSS in a subsequent post. What do you think?

    Threaded Messages (57)

  2. Sun should better react fast[ Go to top ]

    Java is a very good language. We do NOT need new fancy dynamically typed languages. We do NOT continously need new language features either which just increase the complexity. And most importantly, we do not need hundreds of different frameworks, most of which are inferior to ASP Net in terms of quality. What we need is simple. Quality frameworks! JSF (in combination with Seam) is much better than its reputation, but compared to ASP.NET many JSF components are still half-baked solutions and are lacking quality. And Request-based frameworks such as Spring MVC can be considered outdated now. Java FX is a joke compared to Silverlight and Flash. This idiot Jonathan Schwartz spent $1bn on the MySQL acquisition just to make some venture capital guys rich. He should have rather spent $300 million to improve Java Swing and to get something viable to really compete against Silverlight and Adobe Flex. If Sun doesn't react soon, the war is lost.
  3. And most importantly, we do not need hundreds of different frameworks, most of which are inferior to ASP Net in terms of quality.

    What qualities were you talking about?
  4. Java is a very good language. We do NOT need new fancy dynamically typed languages. We do NOT continously need new language features either which just increase the complexity. And most importantly, we do not need hundreds of different frameworks, most of which are inferior to ASP Net in terms of quality.
    Couldn't agree more. People who talks about Java being replaced by fancy and new dynamic language lives in foolish paradise. I have been trying to advocating since long long time that Java needs some thing like ASP.NET forms at their presentation tier, but alas so far they failed miserably. What MS have done 8 years ago Java is still not there. I would suggest SUN to ditch JSF adopt a framework like "Wicket" and make it part of standard J2EE API, for rest they are good to go.
  5. Java is a very good language. We do NOT need new fancy dynamically typed languages. We do NOT continously need new language features either which just increase the complexity. And most importantly, we do not need hundreds of different frameworks, most of which are inferior to ASP Net in terms of quality.


    Couldn't agree more. People who talks about Java being replaced by fancy and new dynamic language lives in foolish paradise. I have been trying to advocating since long long time that Java needs some thing like ASP.NET forms at their presentation tier, but alas so far they failed miserably. What MS have done 8 years ago Java is still not there. I would suggest SUN to ditch JSF adopt a framework like "Wicket" and make it part of standard J2EE API, for rest they are good to go.
    how about javafx? http://www.sun.com/software/javafx/index.jsp though personally, at this point i prefer flex and can see the long term value in having the technologies kept seperate. but, java is so much more than a web technology and i'm sure that's been said many many times. i would be interested to know the statistics, but i suspect that if you looked at implementations of projects using java a surprising amount of them will not even be web related.
  6. Re: Sun should better react fast[ Go to top ]

    I have been trying to advocating since long long time that Java needs some thing like ASP.NET forms at their presentation tier
    You mean like Eclipse RAP and Echo3 (and the other such frameworks)? What ASP.Net has is basically a bunch of datagrids from different vendors. I seldom use third party widgets. Try coding a complex ASP.Net application. Been there. Done that. You'll realize JSF isn't so bad. (I have not used VS.Net 2008 yet so things might have improved.)
  7. Re: Sun should better react fast[ Go to top ]

    What ASP.Net has is basically a bunch of datagrids from different vendors. I seldom use third party widgets. Try coding a complex ASP.Net application. Been there. Done that. You'll realize JSF isn't so bad. (I have not used VS.Net 2008 yet so things might have improved.)
    You are completely wrong in yous statement. ASP.NET is nothing but an awesome component model to develop web based components. Plus since it's very beginning all the HTML and server controls you can imagine are part of standard ASP.net library. Of course MS went one step further and provided all kind of fancy data grids even back then:-) Now the current state of Webforms have more but it didn't change much the basic framework, and that is it's beauty. JSF is crap, just use some common sense, MS taught ASP.NET to bunch of novice VB programmers, and that is the beauty of a framework; on the other had expert Java gurus start coughing when they see the different implementation of JSF:-) Just to quote my old CTO "A professional is one who makes a complex task easy, while an amateur makes an easy task complex" Folks who are running the JSF show are nothing but bunch of amateurs.
  8. Re: Sun should better react fast[ Go to top ]

    Folks who are running the JSF show are nothing but bunch of amateurs.
    Probably the amateur is you. JSF is designed to be extended, this should be clear. And they reached their scope: what are these RichFaces, IceFaces, Trinidad, Woodstock, Orchestra, etc...? No other framework can boat a so rich echosystem. Furthermore the best web framework in the world is born *also* thanks to JSF: Seam.
  9. Re: Sun should better react fast[ Go to top ]

    You are completely wrong in yous statement.
    It is not my statement. It is my experience.
    ASP.NET is nothing but an awesome component model to develop web based components.
    Yes, in some aspects it is good. As long as you stay on the straight and narrow. Which always seems to be the case with Microsoft Techologies. How much have you used it? How complex of applications have you built with it? For hello world apps it is wonderful. For plain ol' CRUD apps it is pretty good too. But it makes complex apps VERY complex. Better than ASP (classic)? Oh yeah. Try Echo or Eclipse RAP. You'll see the difference.
  10. Asp.Net makes apps complex?[ Go to top ]

    You are completely wrong in yous statement.

    It is not my statement. It is my experience.

    ASP.NET is nothing but an awesome component model to develop web based components.

    Yes, in some aspects it is good. As long as you stay on the straight and narrow. Which always seems to be the case with Microsoft Techologies.

    How much have you used it? How complex of applications have you built with it? For hello world apps it is wonderful. For plain ol' CRUD apps it is pretty good too. But it makes complex apps VERY complex. Better than ASP (classic)? Oh yeah. Try Echo or Eclipse RAP. You'll see the difference.
    Can you give some specific examples of issues with the ASP.Net framework that you've seen? I am working on a pretty complex Asp.Net web app: 3 mil+ page views per day, localized, skinning (more than just changing colors). While we've had our problems, it seems to be working pretty well for us so far.
  11. I beg to disagree[ Go to top ]

    How much have you used it? How complex of applications have you built with it? For hello world apps it is wonderful. For plain ol' CRUD apps it is pretty good too. But it makes complex apps VERY complex. Better than ASP (classic)? Oh yeah. Try Echo or Eclipse RAP. You'll see the difference.
    I completely disagree with the above statement.After having deployed complex business apps built on ASP.Net for the past 5 years and having done it on versions 1.1 and 2.0, I can authoritatively say ASP.Net can handle most if not all complex apps that any developer today can be tasked with.And it does so far, far better than anything called Java or J2ee or JEE(whatever)!. The combination of the WebForm abstraction,automatic ViewState management and the ability to wire handlers to server-side code from markup is awesome to say the least. Any intelligent and unbiased Java developer will agree that JSF is still trying to catch up on any of that. It seems u never really went far with ASP.Net to post comments like that, 'cos if u did, u'll discover it's a full OOP web framework,neatly architected and easy to work with. All the controls are 'server-side objects', meaning you have instant programmatic access and debugging insight into any control on your page. You can create and load controls dynamically-where u want them and how u want them to appear,manage data binding and state management programmatically, wire event handlers and handle them from simple methods all in your web page! If you had argued about the lack of true MVC implementation in ASP.Net (that is until recently), I would have agreed whole-heartedly.After my foray into the J2EE world, I'm convinced J2EE/JEE needs a complete rework, the current model is at best an exercise in prototype development. It should be tagged 'not for production environments'. Yeah, you could cite examples of banks and big sites running on J2EE- but are they not groaning under the complexity of that amalgation of crappy frameworks and over-engineered APIs?Have u noticed the trend towards dynamic languages? PHP's,Ruby's and Pythons's success over J2EE( not the Java language)? Have u not noticed that even hard-core Java developers (who are honest) are beginning to consider shifting to better platforms? J2EE could be bettered is my last word on this.Till then ... PHP gets the job done almost always better and faster , Ruby rocks and rocks, ASP.Net is simply awesome and is better than J2EE as I speak(u read that right).. Ciao!
  12. "J2EE or Spring" are losing.[ Go to top ]

    Becuse Resin app server for example takes PHP applications and runs them on JVM (compiles PHP to bytecode) to make them faster. But all the peeps doing EJB and Spring POJO beans are killing us. .V
  13. Re: "J2EE or Spring" are losing.[ Go to top ]

    But all the peeps doing EJB and Spring POJO beans are killing us.

    .V
    not doing. Doing EJB, Spring etc. is not a problem. The killing idea was declare it as a "panacea", as a "must" for every project. The main problem is not JSF itself for example (yet another non-practical stuff written by non-programmers), but the people declared it as "the only way for Java web" etc.
  14. what do you think about GWT?
  15. What is strange for me here. You can start program JSP in PHP style. Any time. It is not a problem. Forget JSF etc. and Java life will be not so bad :) So how can J2EE lost here? The hosting for PHP is cheaper, that is true. But it is only the part of the story anyway
  16. What is strange for me here. You can start program JSP in PHP style. Any time. It is not a problem. Forget JSF etc. and Java life will be not so bad :) So how can J2EE lost here? The hosting for PHP is cheaper, that is true. But it is only the part of the story anyway
  17. Duh![ Go to top ]

    Psst... Grails. Hello-oo.. Where's he been? Groovy is not a port, hence it does not lag behind a 'native implementation.' It's not trying to bridge two worlds, instead it is clearly grounded in the JVM, hence it benefits from the wealth of libraries and frameworks written for Java. And since when can't the JVM scale?
  18. Java is Simple, so is JSP.[ Go to top ]

    Java is not a complex language. Building a web application with Java is easy if you just use JSP. But there are a lot of design pattern fundamentalists in the Java world that want to shoehorn every kind of Java software projects into their grand vision, the "enterprise xxx" world. When they "enterprise" everything, they raised the level of efforts to build and deploy even the simplest applications (maybe that is the whole point). The vast majority of web applications don't need a business tier and a data tier. For example, to publish a simple form to collect some input data from the users and save it in the database, instead of writing just a JSP page, the J2EE people will have you jump through many hoops from Struts to Spring/EJB/Web Services to Hibernate. After all, thou shall not mix presentation, business, and persistence logics. While they erected these tall barriers of entry to keep out the "unworthies", the web world moves on to LAMP and Ruby. Let competition select the best from the crowd.
  19. Re: Java is Simple, so is JSP.[ Go to top ]

    Outstanding post. In the Java Web/Enterprise world, there is the instinctive habit to over-engineer, over "domain-driven-design", over OOP, over framework, over "n-tier", things, to the nth degree. Meanwhile, sooooo many web apps simply don't require all that crap, and introduction of said crap makes the development/deployment process a nightmare of of complexity, development time overruns, and cost overruns. All this, when they could just write a handful of simple JSPs and deploy them to Tomcat or Jetty or something, and be done with it. But in the LAMP world, people do just get on with it, and usually go for the simple, direct, obvious solution. If there is immediate or anticipated need to scale out, and use frameworks, divide things into tiers, use OOD, etc, then they do it. Otherwise, they just get on with it. So yeah, Java is a good, simple, easy to use (and powerful) language. And JSPs are simple, useful, and scalable. It's just that so many in the Java Enterprise world often needlessly add extra layers of complexity.
  20. Re: Java is Simple, so is JSP.[ Go to top ]

    Along with the unnecessary complexity comes the fancy titles. Everybody is a enterprise solution architect. Without the "enterprise", it's pretty hard to justify the "architect" title. I once interviewed a person for a Java developer position. The guy was throwing all kinds of buzz words at me and used the word "enterprise" at least twice in each sentence. I asked him some basic questions about Java/Servlet/JSP/database such as threads and requests, he immediately started claiming that he had been primarily in an architect role where he worked on designing "enterprise" architectural level solutions instead of actual development. Needless to say I told him I would call him back. Not. In my opinion, the Java community has become too corrupt and arrogant. I am glad new competitions are coming in to shake things up a bit.
  21. Re: Java is Simple, so is JSP.[ Go to top ]

    In my opinion, the Java community has become too corrupt and arrogant. I am glad new competitions are coming in to shake things up a bit.It don't strike you as arrogant to say that the Java community is arrogant? Plus, PHP isn't new any more than Ruby is.
  22. Re: Java is Simple, so is JSP.[ Go to top ]

    Outstanding post.

    In the Java Web/Enterprise world, there is the instinctive habit to over-engineer, over "domain-driven-design", over OOP, over framework, over "n-tier", things, to the nth degree.

    All this, when they could just write a handful of simple JSPs and deploy them to Tomcat or Jetty or something, and be done with it.

    Jeff. I agree completely. Most of the so called Java architects are architecting their job security by devising N'tier complexity bundles in enterprise systems and forcing many a delevopment managers and business to listen to their so called crap jargons about clustering/scaling/caching etc.. And the worst of all these 'God like Architects' are forcing a certain amount of thought control too.. where business requirements such as cost efficiency, quicker development cycles , ease of maintenance etc are kicked aside for some geeks deperate attempt to be the most happening thing after "Denis Ritchie".. Shoot all those architects claiming to be building so called utopian systems, where developers tend to concentrate more to cope with the technical complexities, rather havong an acute understanding of the business requirements. I have seen clusterrd N tired applications, devised by so called architects, and later patronized by another breed of 'System Architects'.. very painfully maintained by a team of about +-100 people , just to support in-house applications with a maximum user base of about 200 ;)
  23. Exactly! That is what we wrote about ... Coldtags suite http://www.servletsuite.com/jsp.htm
  24. To quote parts of different messages from above,
    I would suggest SUN to ditch JSF...
    ...but compared to ASP.NET many JSF components are still half-baked solutions and are lacking quality.
    ...Forget JSF etc. and Java life will be not so bad :)
    Cannot agree more. I used to be a big proponent of the JCP model. But, it's insistence on "Thy shalt first standardize and then innovate model" really lost me. Also, frameworks like JSF and others give a lot of importance to strong typing which in web applications is a pain rather than a pleasure. I am tending towards scripting languages & frameworks to be used for web applications (Grails)
  25. Also, frameworks like JSF and others give a lot of importance to strong typing
    Uh? Where JSF gives a lot of importance fo strong typing?
  26. What about security?[ Go to top ]

    Java is build for security from day one by introducing "send box" and, later, security managers. J2EE is secure. What about other alternatives? For example, is PHP as secure as Servlet/JSP? Wei J2EE tools
  27. Re: What about security?[ Go to top ]

    Sorry, but I have to say. J2EE is secure is a joke. security managers is a joke. If it is not secure, it is not because you are not using them. It is just because you wrote bad code. It is nothing about J2EE or security managers, when you have a cross-site script bug.
  28. "It's a little disingenuous to say that the light nature of the LAMP processing stack is a benefit because crappy code is easier to endure... and then say that the lack of formality is a strength if you don't rely on it. The intent seems to be to say "sure, we enable crappy programmers, but they don't have to be crappy, so we can say we have good programmers too." Typical statement from a snobby Java enterprise developer who seems to feel the need to justify all the needless complexity he has to deal with. It's basically saying "PHP is easy, therefore those that use it are crappy programmers", or ... "real men (developers) prefer hard, complex, non-productive tools - if your tool is not hellishly difficult, you suck", or ... "anything that has low barrier to entry sucks, and anybody that is not a complete guru developer expert, sucks". Which is all quite funny and ironic, because Java developers often cite C++ suckatude due to it's complexity and lack of garbage collection and "with C++ you have to chase down memory leaks, therefore with Java I'm much more productive". And I'm saying that as someone who really really really likes Java. But at places like TheServerSide.com, I see a lot of Java Clannish protectionism, where posters often attack C++ at one end (too hard, complex, no garbage collection, blah blah) and dynamic scripting languages at the other end bg(barrier to entry too low, no static typing, doesn't scale, bad design, blah blah blah).
  29. It's a little disingenuous to say that the light nature of the LAMP processing stack is a benefit because crappy code is easier to endure... and then say that the lack of formality is a strength if you don't rely on it. The intent seems to be to say "sure, we enable crappy programmers, but they don't have to be crappy, so we can say we have good programmers too.
    Typical statement from a snobby Java enterprise developer who seems to feel the need to justify all the needless complexity he has to deal with.

    It's basically saying

    "PHP is easy, therefore those that use it are crappy programmers", or ...

    "real men (developers) prefer hard, complex, non-productive tools - if your tool is not hellishly difficult, you suck", or ...

    "anything that has low barrier to entry sucks, and anybody that is not a complete guru developer expert, sucks".

    Which is all quite funny and ironic, because Java developers often cite C++ suckatude due to it's complexity and lack of garbage collection and "with C++ you have to chase down memory leaks, therefore with Java I'm much more productive".

    And I'm saying that as someone who really really really likes Java.

    But at places like TheServerSide.com, I see a lot of Java Clannish protectionism, where posters often attack C++ at one end (too hard, complex, no garbage collection, blah blah) and dynamic scripting languages at the other end bg(barrier to entry too low, no static typing, doesn't scale, bad design, blah blah blah).
    I disagree, Jeff. He's saying that PHP has the low end - remember, he's suggesting that it's okay if your processes screw up badly, because they can die with the rest of the system surviving. That's definitely crap, unless you're of the opinion that a service that can't stay up is okay... And he's also claiming that LAMP may have the benefit of good processes, too, because there's nothing in LAMP that prevents them. He wants his cake and he wants to eat it, too. There's no clannishness there; I'd think that was wanting it both ways no matter what language I preferred. (And I say that as a Python guy as well as a Java guy.)
  30. Yes, Joseph, I do actually take what Gutmans was saying with a huge pinch of salt. He's selling his wares. He makes some decent points, but his arguments have holes as well. But I do get riled up sometimes when people want to poopoo on languages/tools that offer low barrier to entry. Just because it makes it so inexperienced programmers, or actually non-programmers can do stuff with it, does not mean it's not a good technology for experienced, skilled programmers, and that you can't write good, maintainable, scalable, robust code with it.
  31. I disagree, Jeff. He's saying that PHP has the low end - remember, he's suggesting that it's okay if your processes screw up badly, because they can die with the rest of the system surviving. That's definitely crap, unless you're of the opinion that a service that can't stay up is okay...
    Why is that crap? This about a Java application server. It has a pool of threads, and pools of other resources, that is uses to service requests. It lives in a single process. If one of those threads goes haywire and starts sucking down all the CPU or memory, then you have to kill the entire process. You have to destroy the entire pool in order to fix a small part of it. In a multiprocess architecture you most likely have a pool of processes. If one of them goes haywire, you can kill it without adversely affecting the other processes. Some transactions may be lost, but as a whole the service stays up. Of course, there's no law that says you can't have multiple JVM processes going. In fact, a Tomcat process isn't that much more expensive in terms of memory than a Mongrel process, and Tomcat process can do a heck of a lot more. (See http://www.martin-probst.com/blog/2008/04/09/memory-usage-java-vs-rails ).
  32. Little bit of everything[ Go to top ]

    Here's the fundamental truth. When you are in complete control of your environment, Java is most likely a better choice than any of the other systems. You can use any idiom you like in Java (JSPs, JSFs, Dynamic languages, and what not). It solid, feature filled (some would argue over filled), and performant. However, it is monolithic. It's mono-culture is a blessing and a curse. You really should have a dedicated "machine" hosting your application. In a mixed hosting environment, then everything the original author talks about is true regarding server stability. The process model is far more stable than the threaded model, and much more suitable to a mixed hosting environment. And by mixed hosting I mean, basically, shared hosting providers where your application is running next to other, "stranger" and "unknown" applications. For example, someone mentioned Java Security. In JVM Java Security is designed to be able to protect code within the JVM, and the host running the JVM, from untrusted code loaded in to the JVM. Who here doesn't trust the code running in their JVM? Anyone? No, everyone pretty much tosses JVM security out the window and run wide open. Security is enforced through exclusion, not allowing untrusted code into the JVM at all. We all pretty much run our JVMs on locked down systems in locked down data centers. Java can not, and most likely will not, compete in the cheap, shared hosting market as a technology, which is basically a classic 1996 CGI world. Well, that's unfair. It COULD compete in that market, but everything we all know about Java web technology would have to be rebooted, specifically all of our frameworks would be tossed out the window. Someone could create a "mod_java" to run in process with Apache. It could load everything (save core, "safe" classes) through a custom class loader that dumps everything at the end of each request. It could (using the Java security) lock out the creation of threads. The goal being that the JVM looks as pristine at the end of a request as it does at the beginning of a request. Being "mod_java" all it would have to do is load up application classes to support the request on each invocation, which is no different than what PHP and everyone else does. That could be very competitive. The JSP/Servlet model could still prevail, even sessions. But it would appear as if your container was failing over for every request (because it is). Since more modern frameworks do a lot of one time initialization, caching a bunch of work in memory, those would have to go. You can't afford that initialization on every request. So the Java question is whether we want to write applications that way.
  33. gwt[ Go to top ]

    Yeah GWT is probably the best example of Java winning hearts and minds in the battle for the modern web... its a viable competitor in its space.... but the approach was very non Java EE like, keep it simple, implement the minimium necessary and throw it out there..... what the blog doesnt really mention is the problem has changed, people dont want large applications, they want quick mashups etc and will want to change them again in a few months.
  34. My... GOD! The only points that are true in his comments are: 1. Java(the language, not JVM) is losing the battle for the modern Web 2. LAMP simplicity 3. LAMP deployment speed All other points are just flawed due to lack of understanding what Java(platform as a whole) is. And it makes me wonder did he ever get a university degree in IT?
  35. 1- Someone above said Java is not difficult. Yes, it is. People spend 10 hours to become a PHP developer. However to become an acceptable java web developer you need to learn OOP and Java (50 hours) + Servlet and JSP (50 hours) + Persistence technologies (10-50 hours) + MVC and the like technologies and every company might ask you to learn a dozen of badly documented, difficult to learn frameworks. 2- PHP is not crapy, Look at MVC using Zend framework, CakePHP, Kohana, Code Ignitor, Symphony etc. You can use one of them and have a very good, clear, maintainable software. 3- I run 4000 concurrent users on a very complicated web application (Every page contains up to 20 queries) on a single 8 core server (MySQL + PHP 5.2 OOP + Zend Framework). I can never dream java to be able to reach even 30% of that on the same server (and with that stability). We leave the server for several days without any problem. By the way we have 100 million page views a month. 4- I have been IT manager of a bank with 300 branches in past (now back to university to do my PHD) and everywhere I have gone (now I am in grid and distributed computing lab) we have had problem finding a few average Java programmers. However you can find a PHP programmer very easily. If you can not you can train 10s of them in 15 hours. 5- For me it took 3 years until I was able to do web development using Struts, Hibernate etc. (I was chief C++ developer in a Unix/Netware software firm for years) . I am sure it takes more for normal undergraduate students looking for a job. Nowadays I do everything using Java because after you learn it you enjoy its benefits but it needs a lot of burden to reach there. Does it really worth to learn for 3 years to do a thing you can achieve with mere 50 hours of PHP education?
  36. 5- For me it took 3 years until I was able to do web development using Struts, Hibernate etc. (I was chief C++ developer in a Unix/Netware software firm for years) .
    Three years? I really hope you were doing other stuff during that time. Struts is a pain but not 3 years of pain. I am currently training a SQL/Report writer to learn Java and all the other things that we are using. I doubt it will take a year to get her productive. To be honest, I have worked with good C++ developers in the past who had transitioned to Java. Some of those have stuggled too.
    Does it really worth to learn for 3 years to do a thing you can achieve with mere 50 hours of PHP education?
    Probably not. Not if you are doing just websites. But many of us do other things than just websites. So it doesn't make sense for us to duplicate logic in PHP and Perl and Java and C# and ... . It is actually LESS effort to code once in Java (Hibernate/Spring/etc.).

  37. To be honest, I have worked with good C++ developers in the past who had transitioned to Java. Some of those have stuggled too.
    I don't think so we are talking apple to apple here. Learning Java or any other imperative language for any programmer specially a C++/Java programmer is piece of cake. But what frustrates most is learning a stupid framework on top of it, specially when they are hundreds of them and their life time is very short. I quote again Mr. Gosling, Java is learn once and apply every where, that was the gist of Java; but look at us what we have done; writing GUI's should not be a rocket science and most of us can learn any framework hardly in a week, but why we do this again and again, it defies common sense and lost a developer productivity, and that is where .NET shines because every thing is so standard (ironically a long lost promise for Java.)
  38. I don't think so we are talking apple to apple here.
    Exactly. PHP and Struts/Hibernate are not apples to apples
    Learning Java or any other imperative language for any programmer specially a C++/Java programmer is piece of cake.
    One would think so. But programming Java is not like programing C++.
    But what frustrates most is learning a stupid framework on top of it,
    Me too. Pick smart ones. :) Really part of the problem is the HTML user interface. It is such a pain.
    writing GUI's should not be a rocket science
    I know. That is why i prefer desktop UIs.
    and that is where .NET shines because every thing is so standard
    That is great as long as everything is a nail.
  39. Three years? I really hope you were doing other stuff during that time. Struts is a pain but not 3 years of pain.
    I was talking about complete transition from C to "Java + Java Web development using struts, hibernate and a few others" and yes, I was learning at the weekend. Struts specifically is pain because every minor version has changes that makes books on previous minor versions useless (none of the codes will run and you come up with strange ambiguous errors) ...
  40. I was talking about complete transition from C to "Java + Java Web development using struts, hibernate and a few others" and yes, I was learning at the weekend.
    So it wasn't three years. :)


    Struts specifically is pain because every minor version has changes that makes books on previous minor versions useless (none of the codes will run and you come up with strange ambiguous errors) ...
    I despise Struts.
  41. 1- Someone above said Java is not difficult. Yes, it is.

    People spend 10 hours to become a PHP developer. However to become an acceptable java web developer you need to learn OOP and Java (50 hours) + Servlet and JSP (50 hours) + Persistence technologies (10-50 hours) + MVC and the like technologies and every company might ask you to learn a dozen of badly documented, difficult to learn frameworks....
    Spending 10 hours to become a junky PHP programmer, is that what you want? The OOP, Persistence Technologies, MVC and frameworks are language irrelevant. Let's take a look at how you become a PHP programmer below: Q: Does a good PHP programmer need to learn OOP? A: Yes! + 50 hours for PHP programmer Q: PHP looks like JSP, you can learn JSP along with Java. So learning JSP takes 10-50 hours, it applies the same to learning PHP, right? A: Yes! + 50 hours for PHP programmer Q: Does a good PHP programmer need to learn persistence technologies instead of creating your own risky CRUD.php for an application with 10,000+ visit per month? A: Yes! + 50 hours for PHP programmer. Q: MVC is NOT a technology, it's a design pattern. Does PHP programmer need to learn design pattern to develop maintainable and scalable applications? A: Yes! + 50 hours for PHP programmer. Q: Frameworks are NOT technologies, they are abstraction toolkits for programmers to make use of some built-in design patterns and processes to enhance the application and shorten the development time. So does PHP programmer use any Framework? A: Yes! +50 hours for PHP programmer. Based on the answers above, you have to spend minimum 250 hours to become a good PHP programmer and this is at least 25 times more than what you said "10 hours".
  42. Let's take a look at how you become a PHP programmer below:
    Q: Does a good PHP programmer need to learn OOP?
    A: Yes! + 50 hours for PHP programmer
    Or no. A fully rounded modern software developer probably should learn OOP, but you can create a good solution for many problems, just as easily, without using OOP.
    Q: Does a good PHP programmer need to learn persistence technologies instead of creating your own risky CRUD.php for an application with 10,000+ visit per month?
    A: Yes! + 50 hours for PHP programmer.

    Much of the complexity of the Java persistence frameworks resolves around object/relational mapping and transparent persistence. If you get rid of objects and transparency the complexity declines dramatically.
    Q: MVC is NOT a technology, it's a design pattern. Does PHP programmer need to learn design pattern to develop maintainable and scalable applications?
    A: Yes! + 50 hours for PHP programmer.
    Many scalable, maintainable systems were created before the pattern community evolved. Patterns are something a well rounded modern software professional should learn, but the are not a prerequisite for getting something done.
    Q: Frameworks are NOT technologies, they are abstraction toolkits for programmers to make use of some built-in design patterns and processes to enhance the application and shorten the development time. So does PHP programmer use any Framework?
    A: Yes! +50 hours for PHP programmer.
    Frameworks are collections of reusable design and code. A PHP developer need only learn a framework if there is one where the cost benefit is positive for the project they are attempting.


    Based on the answers above, you have to spend minimum 250 hours to become a good PHP programmer and this is at least 25 times more than what you said "10 hours".

    To be a good (insert anything here) programmer you need more than 250 hours. However Java adds more because it has a large and complex stack.
    However to create a good program, for some problem, you may not need to be that great.
    Trying to solve some problems in PHP adds less accidental complexity and that is a good thing.

  43. Let's take a look at how you become a PHP programmer below:

    Q: Does a good PHP programmer need to learn OOP?
    A: Yes! + 50 hours for PHP programmer

    Or no. A fully rounded modern software developer probably should learn OOP, but you can create a good solution for many problems, just as easily, without using OOP.



    Q: Does a good PHP programmer need to learn persistence technologies instead of creating your own risky CRUD.php for an application with 10,000+ visit per month?
    A: Yes! + 50 hours for PHP programmer.



    Much of the complexity of the Java persistence frameworks resolves around object/relational mapping and transparent persistence. If you get rid of objects and transparency the complexity declines dramatically.



    Q: MVC is NOT a technology, it's a design pattern. Does PHP programmer need to learn design pattern to develop maintainable and scalable applications?
    A: Yes! + 50 hours for PHP programmer.

    Many scalable, maintainable systems were created before the pattern community evolved. Patterns are something a well rounded modern software professional should learn, but the are not a prerequisite for getting something done.



    Q: Frameworks are NOT technologies, they are abstraction toolkits for programmers to make use of some built-in design patterns and processes to enhance the application and shorten the development time. So does PHP programmer use any Framework?
    A: Yes! +50 hours for PHP programmer.

    Frameworks are collections of reusable design and code. A PHP developer need only learn a framework if there is one where the cost benefit is positive for the project they are attempting.





    Based on the answers above, you have to spend minimum 250 hours to become a good PHP programmer and this is at least 25 times more than what you said "10 hours".



    To be a good (insert anything here) programmer you need more than 250 hours. However Java adds more because it has a large and complex stack.


    However to create a good program, for some problem, you may not need to be that great.


    Trying to solve some problems in PHP adds less accidental complexity and that is a good thing.
    Your arguments are not working here. What my questions and answers there are referring too one single statement: It takes 10 hours to become a PHP programmer. But what's the point of being a PHP programmer who cannot create good code? And c'mon, stop arguing without a strong statement, whatever you wrote are too general and do not have practical points. I did not say programmers must learn design pattern but most of the large apps involve common problems and if programmers do not know how to use design pattern to resolve issues, these are not "acceptable" programmers as stated originally by the thread writer. You think if you get rid of frameworks you will get rid of complexity? When you need to write scalable apps with lots of business logic running behind, your persistence logic become so mission critical. Yeah, you select not to use frameworks and create persistence layer yourself and eventually you reinvent the wheel to write all the stuff that has been designed and optimized in frameworks. I never said that programmers MUST use frameworks and design patterns but these are definitely the tools for programmers to help themselves only. I don't understand why people judge the complexity of a programming language by the number of hour it takes to be mastered.

  44. 3- I run 4000 concurrent users on a very complicated web application (Every page contains up to 20 queries) on a single 8 core server (MySQL + PHP 5.2 OOP + Zend Framework).

    I can never dream java to be able to reach even 30% of that on the same server (and with that stability). We leave the server for several days without any problem.

    By the way we have 100 million page views a month.
    Show us the URL please. 4000 concurrent users visit so COMPLICATED web app with 100 million page views per month on single 8 core server? Unless you don't put firewall in front of your server and connect your server to your ISP directly with fibre optics, how do you handle the load even with Giga LAN? Stop exaggerating.

    4- I have been IT manager of a bank with 300 branches in past (now back to university to do my PHD) and everywhere I have gone (now I am in grid and distributed computing lab) we have had problem finding a few average Java programmers.

    However you can find a PHP programmer very easily. If you can not you can train 10s of them in 15 hours.
    You can definitely pull some PHP on the street to help you manage your bank, but do me a favor, can you tell us which bank you are working as the IT MANAGER? I just wanna let my friends know they should run away from that bank.

    5- For me it took 3 years until I was able to do web development using Struts, Hibernate etc. (I was chief C++ developer in a Unix/Netware software firm for years) .

    I am sure it takes more for normal undergraduate students looking for a job.

    Nowadays I do everything using Java because after you learn it you enjoy its benefits but it needs a lot of burden to reach there.

    Does it really worth to learn for 3 years to do a thing you can achieve with mere 50 hours of PHP education?
    It took you 3 years to be able to develop something using STRUTS and Hibernate and you were CHIEF C++ developer in Unix/Netware + you are pursuing your PhD? 3 years not the total time of learning I guess? If that is the case, seriously please take my humble opinion here, you should not work in IT at all.

  45. Show us the URL please. 4000 concurrent users visit so COMPLICATED web app with 100 million page views per month on single 8 core server? Unless you don't put firewall in front of your server and connect your server to your ISP directly with fibre optics, how do you handle the load even with Giga LAN? Stop exaggerating.


    You can definitely pull some PHP on the street to help you manage your bank, but do me a favor, can you tell us which bank you are working as the IT MANAGER? I just wanna let my friends know they should run away from that bank.

    It took you 3 years to be able to develop something using STRUTS and Hibernate and you were CHIEF C++ developer in Unix/Netware + you are pursuing your PhD? 3 years not the total time of learning I guess? If that is the case, seriously please take my humble opinion here, you should not work in IT at all.
    Andy Leung, I have rarely seen an impolite and rude person like you. I normally do not go into discussion with such people.
  46. I run 4000 concurrent users on a very complicated web application (Every page contains up to 20 queries) on a single 8 core server (MySQL + PHP 5.2 OOP + Zend Framework).
    OMG, you are making a site with 20 queries per page and you call it scalable? My site (actually a relatively complex web application) has 0.3 queries per page and is written in Java! Ever heard of caching the database? With domain driven design caching is much easier to add than in DAO-like procedural designs. Sure you can use any language/technology to employ domain-driven-design, like you can also use any technology or platform to build crappy over-designed, over-layered software. Domain-driven-design with caching is not over-design but design for maintainability and clarity but also for performance and scalability.
  47. I run 4000 concurrent users on a very complicated web application (Every page contains up to 20 queries) on a single 8 core server (MySQL + PHP 5.2 OOP + Zend Framework).

    OMG, you are making a site with 20 queries per page and you call it scalable? My site (actually a relatively complex web application) has 0.3 queries per page and is written in Java!
    Ever heard of caching the database? With domain driven design caching is much easier to add than in DAO-like procedural designs. Sure you can use any language/technology to employ domain-driven-design, like you can also use any technology or platform to build crappy over-designed, over-layered software.
    Domain-driven-design with caching is not over-design but design for maintainability and clarity but also for performance and scalability.
    It is a social networking website with several items on each page. We use Zend framework and we also use caching. If you look into facebook for example you will see several queries are needed on each page. Some pages need less than 4-5 queries but a few of the pages need up to 20. Most of the time you cannot cache pages or queries because you have several thousands of online users with completely different profiles and personalized web pages. Concurrent users in these websites are very high because users stay on the website for a long time. In our case it is more than 18 pages/visit in average (some users may go up to 100 pages). The website has proved to be scalable til now. If we need more process power we will move MySQL to another 8 core (in future). You can see snapshot of the traffic in January here: http://sarmadys.googlepages.com/home Some pages are not computed in above stat (we use Ajax on most of the pages and we have not added tracking code in some of them).
  48. As the title, says, there are indeed different types of "concurrent users", which makes the criteria rather a marketing figure without more info. Here, it looks like you're talking about concurrent 'user sessions' (i.e. the number of users currently executing use cases on the site) while the reply to your post was talking about concurrent requests (i.e. the number of connections waiting on response generation at any given instant).
  49. I run 4000 concurrent users on a very complicated web application (Every page contains up to 20 queries) on a single 8 core server (MySQL + PHP 5.2 OOP + Zend Framework).

    I can never dream java to be able to reach even 30% of that on the same server (and with that stability).
    I believe good designed Java web app can server up to 25,000 concurrent users on your hardware, based on the performance of the actual web site (application).
  50. If it took you 3 years to do a Struts app with Hibernate, the fault doesn't lie in the stars, but in yourself. My first Struts app took a few weeks to get the gist, and get the app up and running. The rest of the time(3 months) was doing the rest of the pages and rest of the app. It took a couple of weeks to learn Hibernate. The issue isn't whether or not Java is hard, but that all people ARE NOT CREATED EQUAL. What was hard for you clearly isn't hard for everyone considering how ubiquitous Struts and Hibernate are. Even my first java server app for a wireless telecome ran months without problems. The tool can never exceed the capabilities of the user.
  51. 5- For me it took 3 years until I was able to do web development using Struts, Hibernate etc. (I was chief C++ developer in a Unix/Netware software firm for years) .
    Sorry but when i read this sentence, i have thought that you didn't choose the right job...

  52. Sorry but when i read this sentence, i have thought that you didn't choose the right job...
    As I said I spent 1-2 weekend days to learn Java and a few frameworks along with some other activities, including above mentioned social networking website (which I developed in my spare time) and a few others. I learned C and C++ in 3 months when I was 14 (before that I had learned Fortran and Basic). My main accusation here is about several frameworks which are sometimes difficult to learn, not very well documented, ... Every team selects a different set of frameworks (from among hundreds of available frameworks) and teaching all of these to every team member is too costly and sometimes impossible.

  53. Sorry but when i read this sentence, i have thought that you didn't choose the right job...


    As I said I spent 1-2 weekend days to learn Java and a few frameworks along with some other activities, including above mentioned social networking website (which I developed in my spare time) and a few others.

    I learned C and C++ in 3 months when I was 14 (before that I had learned Fortran and Basic). My main accusation here is about several frameworks which are sometimes difficult to learn, not very well documented, ...

    Every team selects a different set of frameworks (from among hundreds of available frameworks) and teaching all of these to every team member is too costly and sometimes impossible.
    Then don't select frameworks. Just write Java as you would C/C++. But I bet, if you are like all other good developers, that you will (just like you must have in C/C++) begin to build your own frameworks. If you don't, you will end up with duplicated code and a maintenance nightmare. And now someone will have to learn your "frameworks". Which are more than likely not documented at all. Ok, so you learned C/C++ in 3 months when you were barely a teenager. But Java frameworks are difficult for you? Okaaaay.
  54. different job, different tool?[ Go to top ]

    shouldn't the question be if JSP(or JSF/Velocity etc.) is losing the battle? For jobs that require 75 % of effort to be spend on rendering web pages and just showing some content from a database, a whole 3-tier solution with a MVC framework is just overkill. Then you can hire some 22 year old that takes pride in correct rendering XHTML standards compliant pages based on PHP, instead of an older more experienced Java developer that builds something with too much power. Of course you can do that also with JSP, but JSP developers will be inclined to go with standard design patterns and make things overly complex. Now, when your project requires secure data, has multiple data sources, I'd say skip the script kiddies and go for experienced Java developers. Different job, different tool. Java is a great language, but sometimes other languages are also perfect.
  55. Re: different job, different tool?[ Go to top ]

    shouldn't the question be if JSP(or JSF/Velocity etc.) is losing the battle? For jobs that require 75 % of effort to be spend on rendering web pages and just showing some content from a database, a whole 3-tier solution with a MVC framework is just overkill. Then you can hire some 22 year old that takes pride in correct rendering XHTML standards compliant pages based on PHP, instead of an older more experienced Java developer that builds something with too much power. Of course you can do that also with JSP, but JSP developers will be inclined to go with standard design patterns and make things overly complex.

    Now, when your project requires secure data, has multiple data sources, I'd say skip the script kiddies and go for experienced Java developers.

    Different job, different tool. Java is a great language, but sometimes other languages are also perfect.
    I wouldn't do this. I'd rather my "framework" do both. At my last job, the "framework" I worked on used Struts(but migrated to GWT), Spring, and Hibernate. We used the same foundation for apps as small as 3 pages. Instead of having apps in PHP, PERL, and Java, we successfully used Java for all of our apps. And since they where architectually identical, learning the smallest app gave you an understanding of the largest. N-tier or MVC doesn't automatically equal complexity. Java, IMO, scales down better than you'd think, provided you the problem a little thought. Each project I worked on, small to mid-size was able to utilized the same common code and approach. That 3 page app took 8 days. I spend 6 of that dissecting and replacing the heinous SQL literals that dotted the code. The result was far more maintainable and easier to understand. Another advantage is that those smaller apps has all the capabilities of their bigger brethren, for almost no extra work: Security, Caching, all sorts of exception notitications, profiling, etc.. all because the small solutions used what the big solutions used. Even a small app can benefit from having emails sent out for certain types of exceptions, providing a faster turnaround to troubleshooting and resulting in happy customers. The problem, IMO, with quickly hacking out prototypes is that prototypes, at least in my experience, become production systems and they never get easier to maintain. I'd rather have a battletested solution that can work well in a variety of tasks.
  56. Of course you can do that also with JSP, but JSP developers will be inclined to go with standard design patterns and make things overly complex.
    Inclined by whom? Should be "standard" rather than standard here :-)
  57. Speed to market[ Go to top ]

    Although the speed to market has been a huge issue for most companies, some have embraced tools which help ease this pain. Most dominant, although overly complex, is the Rational Suite. I have recently found a couple alternatives. ThinkCap, by ClearNova is a GUI tool that enables plug-n-play Ajax behaviors. My favorite today is 'Relax' by ProQuality Software. It has Ajax, EJB, and Web Services support, the ability to have an application generated and functional out-of-the-box, as well as the feature to have 100% control over what is generated. Relax has a new feature that enables you to generate the application in .Net instead of Java. I prefer this option because you get more for less, and the learning curve is small. I recently went through Microsoft training for SharePoint Server. It has a lot to offer as well if you are into the whole non-portability thing. Top features I found were integration with source control and collaboration tools that come with it. An expensive alternative, and costly to gain the expertise to develop with it.
  58. Follow up from Andi Gutmans[ Go to top ]

    I have posted a follow-up clarification post on my blog: http://andigutmans.blogspot.com/2008/05/follow-up-to-recent-java-post.html Cheers and thanks for participating in the discussion!