Responses to "Java is losing the battle for the ... web"...

Home

News: Responses to "Java is losing the battle for the ... web"...

  1. This is a summary on the mailing list commentary on Andi Gutman's "Java is losing the battle for the modern web," somewhat summarized on TSS. It's all about the perspective on the API and libraries and it's slightly incomplete, because it's still going on! One comment was:
    I've done Java for a long time now, but every time I do a bit of Rails work, working with Java + Tapestry + Hibernate + Spring again feels heavy, clunky and slow. And I still have nightmare flashbacks of working on a huge project built around entity beans...
    This centers around the use of traditional development models – with an edit/compile/run cycle – versus the dynamic nature of scripting language deployment. It's odd that Hibernate and Spring were included here – with no offense intended to Tapestry – because Hibernate and Spring isolate developers somewhat from the compile/edit/run cycle by offering easier persistence and late binding of service references. The same commenter said:
    ... as 'elitists' go, most of the ones I've met are in the Java camp and won't even deign to read about Ruby or Python. As soon as they hear that those languages don't have static typing, those languages are suddenly 'beneath them.' Clearly I'm not saying all old-time Java guys are like that (I'm an old-time Java guy, remember), but I've met lots of them. Now, there are those in the dynamic language camp who are snotty snobs about Java. Of course there are. But that article didn't sound like that to me.
    It's sad that adherents for languages like Ruby, Python, Scala, and Java take an approach to languages as if there was a zero-sum game involved, with a "winner" and multiple "losers." Another commenter:
    It is full of unsubstantiated assertions and contradictions. It ignores some important bits of reality that are convenient to the point it is trying to make. Overall, the article is blatantly slanted to a "get stuff done as quick as possible" attitude. I don't know about the rest of you, but I've got first-hand, painful experience with doing things that way. Even when it "succeeds" it still costs as much in the long term and causes tons of different headaches. Like I said, questioning the status quo is rarely a bad thing, but this guy should back up his thoughts with some evidence. An example of how he kills his own credibility: the comparison between a Groovy or PHP "Hello World" to a Java version. Give me a friggin' break; I expect that kind of comparison from a high school student who just learned to program, not from anyone who's actually built applications. ... Do we really have to go over yet again how Java != JEE != entity beans? And Tapestry? ... Hibernate is very useful, but heavy - but show me that kind of robust O-R mapping and caching in PHP or Python or Ruby....where is it? See, that's a big problem and there aren't small solutions. JPA is definitely an improvement, though.
    This spawned its own response:
    Yes, I know that Java != blah blah, and don't need the newbie lecture about it. As for O/R, have you seen ActiveRecord in Rails? It's unbelievable. It does suffer from being 'opinionated software' but it's a hell of a lot easier to use than Hibernate. (And yes, I know that Hibernate != Java, but as far as I know, Java doesn't have O/R baked in, so you have to use something if you want O/R, right?)
    This started a conversation about whether ActiveRecord is enough – it's very common for Rails, obviously, but that might be a case where all you have is a hammer and thus everything looks like a nail. Alternatives were brought up like iBATIS or an ODBMS (where persistence isn't based on type.new, type.save but on container.persist(type), depending on specific implementations). One poster, looking at the whole thread, said this:
    Funny coincidence is that we had a Java guy at CJUG yesterday talking about a small but powerful framework he wrote because he thought web applications in Java are just too painful and he didn't like the other frameworks out there. So he wrote Tagger Cat and this is his project summary:
    Tagger Cat is a Visual Model Driven JSP Application Framework for rapidly building database backed applications. Tagger Cat is an action based framework that leverages Hibernate and includes design tools integrated with Dreamweaver.
    As most of you might know, I am working in PHP. One of the reasons for that is that when I started out with programming in 2000, I couldn't get a job in Java because of the .com bubble bursting right around that time. When I tried to set up en ecommerce site for my brother as one of my first projects, I couldn't find anything decent in Java. Mostly Perl or PHP. The reason I ended up with PHP was because it was easy to get an affordable web host that has PHP and MySQL installed (for small to medium shopping carts). I acknowledge that PHP is currently not scalable enough for Enterprise applications but for small to medium sized projects it's a pretty good fit. And with PHP 6 in development, OO is a possibility as well. We'll see what happens in the next few years. Ruby gains momentum. For small to medium stuff it will need the amount of open source applications available in PHP to get into that market.
    Another separate comment, slightly edited for language:
    I dunno, there's an awful lot of handwringing going on. Ruby people say stuff like "Java should have duck typing, nyaah, nyaah, nyaah," closures, lambdas, all kinds of stuff. Great. Sure, those things can rock. But does Java really need them? Does Java suffer by not having them? No. Java's capable, period, staying within its paradigm. People saying "java is losing the battle" are lying, because THERE IS NO FREAKIN' BATTLE. If there was one, Java is winning it, by sheer volume. i.e., I'm calling bullshit. It's not really icky bullshitty bullshit as far as such bullshit goes, but it's still bullshit.
    What about it, readers? Is this wild growth of choices and techniques a problem? If it is, is there a solution? Is there even a "right way" out there to be found?

    Threaded Messages (38)

  2. It's odd that Hibernate and Spring were included here – with no offense intended to Tapestry – because Hibernate and Spring isolate developers somewhat from the compile/edit/run cycle by offering easier persistence and late binding of service references.
    Wha?? Since when did Hibernate and Spring support dynamic definition and deployment of entities/beans? Yes, they do late binding of service references, but when I am developing, and add a Spring bean or a Hibernate mapping, i do have to restart my app. Don't get me wrong, I do love and use both heavily. But, once I got the taste of working with a much lighter (in terms of development) platform like Grails, restarting your application seems arcane. In Grails, you can get by without restarting except... when it is time to add a new Hibernate or Spring definition ;-)
  3. It's odd that Hibernate and Spring were included here – with no offense intended to Tapestry – because Hibernate and Spring isolate developers somewhat from the compile/edit/run cycle by offering easier persistence and late binding of service references.


    Wha?? Since when did Hibernate and Spring support dynamic definition and deployment of entities/beans? Yes, they do late binding of service references, but when I am developing, and add a Spring bean or a Hibernate mapping, i do have to restart my app. Don't get me wrong, I do love and use both heavily. But, once I got the taste of working with a much lighter (in terms of development) platform like Grails, restarting your application seems arcane. In Grails, you can get by without restarting except... when it is time to add a new Hibernate or Spring definition ;-)
    The reference here is to the compile step - not the restarting step. Good point, though.
  4. The reference here is to the compile step - not the restarting step. Good point, though.
    Please read http://www.hibernate.org/hib_docs/reference/en/html_single/#persistent-classes-dynamicmodels
  5. What about it, readers? Is this wild growth of choices and techniques a problem? If it is, is there a solution? Is there even a "right way" out there to be found? I think there are some problems with having too many frameworks out there. I also think the Java community as a whole needs to take a deep breath, stop shit talking and/or panicking at every inane attack. On the one hand, the quantity of frameworks at first blush would signify that the language or platform is deficient and requires significant extension to meet the needs. However, in the java world, how many frameworks are truly unique. And for that matter most of the overkill, and acrimony between parties, is in the Web tier layers. So is the sheer volume of frameworks an indication of deficiency or just that there are more java anarchist poets out there who are trying to make a name for themselves by promoting their new and revolutionary framework. I'm not sure that java as a platform is the problem here. Granted the JVM started out as a substrate for building the "network computer" or whatever the original marketing garbage was and the JCP was setup as a democratic(cough cough) committee to add new features to the platform. As a lot of people can attest to, the JCP has degenerated into a bunch of cackling harpies defending their own agendas rather than advance the platform. Most JSRs are DOA or are on their last breath with everyone jumping ship. And JSR submittals are getting cartoonish lately. Instead of entertaining "JSR 324 On Screen MIDlet API for Java ME", how about beefing up numerics in the language so it's finally usable for analytics. Java isn't losing the battle, it has lost it's religion. My solutions: - Mark and Sweep the JSRs in the JCP that are dead. No activity in X days, put the JSR on probation. After another X/2 days no activity, kill it. It should be a "cruel to be kind" mentality. I don't like the JCP but it's what the java community has at this point. Show some integrity or at least some vitality with the responsibility you politicked for. - Sun should protect their brand by allowing vetos on frivolous JSR approvals. - Web application framework developers need to grow up. Great, you've written a new framework because JSF sucks or Struts sucks or Tapestry sucks, yah ta yah ta. There are no frameworks that solve all problems and never will be. Every framework has some sort of HTTP -> Object Map, validate, process and view. Nothing extraordinary going on. - Put to rest this dynamic vs static typing debate. It's an ideological argument and brings nothing to software engineering as a craft -- it's religious zealotry. Software engineers should have multiple tools in their toolkit. Too much proselytizing nowadays, not enough product.
  6. Should Java ever have had a religion?
  7. Should Java ever have had a religion?
    Probably should've used a better phrase than "lost's it's religion". I was thinking java lately is having an existential crisis. That being said, do I think should java ever had a religion? Personally, I think no but from an objective viewpoint it had to. Java was created/hyped or whatever as a (r)evolutionary platform for distributed and concurrent programming. In order to be evolutionary, I guess it was necessary to have a guiding force to filter out noise along the way. The JVM was the primordial goo and the JCP would play the council of elders to take community feedback and evolve the platform -- everything else was supposed to be userspace value-added propositions separate from the core process. Unfortunately, corruption and apathy has set in the JCP and any evolutionary path seems murky at best with every vendor trying stake a claim. IMO, the Web Framework flame wars are a crappy thing for the java community. These are APPLICATIONS not part of the language or platform. Java and deficient frameworks are being lumped together unjustifiably. The web in general as a development environment is stagnant and deficient. HTTP hasn't evolved so I think it's disingenuous at best to say java is losing the battle for the modern web. The available frameworks maybe, but not the language or more importantly the JVM. Now that I think about it, what the hell is the "Modern Web"? We hear the Web 2.0 interactivity, social networking, etc. buzz but what does that mean from a development viewpoint. I'd like to see the war defined before throwing up the white flag. Rails is cool and definitely hits a sweet spot for some problem domains, but dig into their community -- the rumblings are starting to surface just as it did with java/ASP/.NET -- particularly and surprisingly with ActiveRecord. AJAX has momentum but all and all it's a huge kludge and dangerous, no matter what language on the server side you use. The pretty funny rantings of Zed Shaw show that java is not the only camp where all is not well.
  8. Reply to Frank[ Go to top ]

    Web application framework developers need to grow up. Great, you've written a new framework because JSF sucks or Struts sucks or Tapestry sucks, yah ta yah ta. There are no frameworks that solve all problems and never will be. Every framework has some sort of HTTP -> Object Map, validate, process and view. Nothing extraordinary going on.
    No offence, but I think that is a rather naive statement. Ultimately the goal of any development technology is to try to find a balance between two things (relative to the problem being solved): 1. Reduce the amount of code a developer has to type in 2. Make it easy to maintain this code Depending on the problem domain, chosing the right framework can make a big difference in this regard. They arent all the same. The stack I use at for mission critical enterprise apps (like what I am working on now) is a hell of alot different than what I use for lighterweight applications.
  9. Re: Reply to Frank[ Go to top ]

    No offence, but I think that is a rather naive statement. Ultimately the goal of any development technology is to try to find a balance between two things (relative to the problem being solved):

    1. Reduce the amount of code a developer has to type in
    2. Make it easy to maintain this code
    I'm sure the developers of all frameworks have this in mind and have different viewpoints on how to solve them. Their success is subjective. The operative phrase you use "relative to the problem being solved" is again specific to a business need. Web frameworks in general solve the Map->Validate->Process->View paradigm(naive as it may be) unless you're talking about a vertical framework specific to a unique line of business. But in that case, I don't think it would be considered a web framework but an application.
    Depending on the problem domain, chosing the right framework can make a big difference in this regard. They arent all the same. The stack I use at for mission critical enterprise apps (like what I am working on now) is a hell of alot different than what I use for lighterweight applications.
    I think you're making my point. You analyzed different problem domains and found one framework met your need viz a viz a different framework "depending on the problem domain". And the opposite was true. It sounds like you didn't say "X sucks I'm only using Y for all problems because JSP/JSF should die". As a side note, could you elaborate on why the one stack was applicable to your enterprise model versus the lightweight one and vice versa. It would be interesting to hear other real world thought processes on design issues and how certain frameworks are more useful in mission critical situations.
  10. re: frank[ Go to top ]

    I think you're making my point. You analyzed different problem domains and found one framework met your need viz a viz a different framework "depending on the problem domain". And the opposite was true. It sounds like you didn't say "X sucks I'm only using Y for all problems because JSP/JSF should die".
    Sounds like we are on the same page.
    As a side note, could you elaborate on why the one stack was applicable to your enterprise model versus the lightweight one and vice versa. It would be interesting to hear other real world thought processes on design issues and how certain frameworks are more useful in mission critical situations.
    No problem The "enterprise" app I am working on has the following needs (in parens Ive encluded the technology we are using to solve the need): - Hundreds of often-changing business rules (Business Rules Engine) - 30+ interfaces with external systems both inside and outside the exterprise that use a variety of transport technologies and message types (Enterprise Service Bus) - Multiple routs of user interaction like web, fratclient, sychnronous messaging, etc that needs to have the same set of business rule validation (SOAP facades that wrap EJB 3.0 POJOs) - Asycnronous outgoing messages (JMS) - Complex reports (Reporting engine/server) - Contractual need to open buisness services and processes to outside world (SOAP again) - For the web pages we are using JSF (not because I want to but because it is an enterprise standard, but with a WSYWYG editor is not nearlly as bad as having to do it by hand) So we are using alot of technologies that are often vilified by the "J2EE is bad" folks. The truth is, I happen to be working on the type of app that need these heavy weight technologies. I wouldnt use most of them on a small departmental app or a personal project because they are simply too big and too cumbersom to use unless you have too. I think the mistake Sun made was that they said the patterns that an entprise app should use are the same that a simplier app should use and they designed an ecosystem of specs that scaled down very poorly. I think conversrly, alot of people who like Rails/Grails and the like made the exact opposite error in that they felt that since frameworks and dyncamic languages appropriate for small to middleweight apps, then by definition J2EE technologies are inheriantly bad. I think the industry in general is moving away from these polarizing viewpoints and is seeing that different levels of complexity require different tools.
  11. Sun[ Go to top ]

    I think the mistake Sun made was that they said the patterns that an enterprise app should use are the same that a simpler app should use and they designed an ecosystem of specs that scaled down very poorly.
    This is a very good point. Remember Sun's J2EE blueprints from around 2000, 2001? And the Pet Store sample application? Microsoft was quick to point out how bloated and over-engineered that was - see http://msdn2.microsoft.com/en-us/library/ms954626.aspx . There were Java-based frameworks like iBatis, OC4J, and Spring putting together their own petstore apps to show how easier they were than following the J2EE blueprints. And today, there are plenty of choices in many languages for creating such an app in less than a day. So yes, I think Sun tried to sell a solution for one set of fairly complex applications for all applications. From 1997 to 2000, we jumped from HTML via perl scripts in cgi-bin (messy) to servlets outputting HTML code (messy) to 14000 lines of code to build a petstore app (very messy). So Sun missed out on a better abstraction for making webapps easy to make. Struts appeared around 2000, and while Struts introduced some organization to a webapp, I don't think it made things much simpler. When you look at this history, I think it can be argued that it just took longer than it should have for simple, widely-known web development options to be available in Java.
  12. Re: re: frank[ Go to top ]

    I think the mistake Sun made was that they said the patterns that an entprise app should use are the same that a simplier app should use and they designed an ecosystem of specs that scaled down very poorly.
    I'm not sure why people keep saying that, since it's simply not true. If all that you need is a homepage kind of thing, nobody stops you if you're just using JSP with embedded scriptlets for that. Heck, you don't even need to use classes. Just stuff everything on that JSP page, interweave some HTML markup in there and be done with it. This style of programming is absolutely identical to what people often do in PHP. If you don't need classes, an MVC design, transactions, distributed objects, messaging etc, by all means please just go for the bare JSP approach. This is a perfect example of how excellent the Java EE specs scale down. Java EE is indeed a pretty huge platform, but it's trivial to just use two parts of it, namely Servlet and JSP completely standalone. After a while it may happen that your application grows and becomes hard to maintain with all that business code hanging around between the HTML markup. In that case it's only a small step to refactor that code and put it into Java's excellent class system. A little later you might find your programmers keep putting business logic on your pages and you might mandate the use of JSTL then to make a simple separation between view and business logic, without adopting an MVC approach (yet). If you find your application is really growing, you might start to appreciate the benefits MVC can give you. At that moment you can start using JSF, and mixing it in the same application with your existing JSP pages. Your JSF backing beans can simply call your existing business logic classes and all will be fine. Till this point of time you've probably done all your persistence stuff with plain SQL and through JDBC. Perhaps you now decide it's time to actual model the entities in your application and adopt JPA to naturally map these to your existing or revised database. Suppose your application now really starts to grow; you're deploying services to multiple servers and find that it's hard to guarantee integrity between operations on those servers. At that point you may start to use JTA. Perhaps you want to start using it programmatically first, just to get the feel of it. A while later you could decide you'd rather go for declarative transactions and start using some simple session beans. etc etc... The point I'm trying to make is that all mentioned technologies can be introduced into your application step by step. If your application at some point of time doesn't grow anymore, just keep using what you have. This is in contract with PHP. If your application grows, the only option you have is to relocate some of the code that's embedded on the page to a top level class. There is no package system. There is no limited language for the view layer, there is no readily available MVC system in the platform itself, there is no O/R mapper that comes with PHP, there is no facility for transactions, there aren't any concurrency tools (like the infinitely useful java.util.concurrent package). Etc etc. Not all applications need all that stuff, but if you do, it's there to take in Java, without the need to install a single third party library. And if you don't need it, don't use it. It's as simple as that...
  13. JSP[ Go to top ]

    I'm not sure why people keep saying that, since it's simply not true. If all that you need is a homepage kind of thing, nobody stops you if you're just using JSP with embedded scriptlets for that. Heck, you don't even need to use classes. Just stuff everything on that JSP page, interweave some HTML markup in there and be done with it.
    There are a couple of issues here. First of all, your mention of pure JSP as Java's solution for the low end illuminates the problem. Most web apps and websites fall somewhere in the middle between what pure JSP does well and what hard-core J2EE does well. Simply put, the Java ecosystem hasnt had a good web-development solution for a huge swath of the apps people need to make. Struts became the defacto standard for that space and while it was a step up from pure JSP inn terms of patterns, many find it very lacking for many reasons. I think it was a HUGE oversight for sun to not have an offical compelling solution for the smalish to medium size projects as an official part of JEE. But to get back to the "low end" side of things and seeing JSP as the solitution, there are some problems with this as well. While the syntax of JSP is perfectly fine (while not as easy as PHP), the problem here is not with the language itself, but with its underlying infanstructure. Because of the relative heavywheight nature of the JVM and the session-based nature of Servlet technology its very hard for hosting companies to offer cheap yet quality shared-enviornment hosting solutions. This was the #1 issue keeping JSP from being as popular as PHP and ASP for internet web sites construction. If also add that not having a cheap WYSWYG code editor for JSP didnt help either.
  14. Re: JSP[ Go to top ]

    Just stuff everything on that JSP page, interweave some HTML markup in there and be done with it.


    There are a couple of issues here. First of all, your mention of pure JSP as Java's solution for the low end illuminates the problem. Most web apps and websites fall somewhere in the middle between what pure JSP does well and what hard-core J2EE does well.
    I'm not sure I fully agree with you there. The entire argument seems to be that a no nonsense language and platform like PHP is better suited for the majority of the simple web apps. If we break this down and take a look at what PHP exactly offers, then we see it basically has a library with some utility methods to query a database and read from files. Next to that it offers a page based templating system where you are supposed to interweave HTML markup with delimited PHP statements. The typical pattern here is that 1 page starts to extract some parameters from the requests, throws that into a query, maybe performs some logic on the result and loops over that result with some HTML markup inside and outside that loop. The advantage of this stuff is that you barely have to learn anything about computer science or programming, plus that the development pattern is to change something on the page, hit ctrl-s in your editor and refresh in your browser to see the results. I may be mistaken, but isn't that what the entire argument of this and the related news posting here boils down to? Since this is -exactly- what pure JSP does, I'm a little confused why people first say that PHP offers that what the majority of the simple web apps need, but when it's clear that Java offers exactly the same suddenly 'a little more' is needed. There are of course a few differences at this level, but they are not that radical. PHP doesn't require declaration of types. Then again, if all you do is extracting stuff from the request (some Strings) and stuff that into a SQL query (a String) and print the result to the response, you won't see much typing in Java either. In fact, I've seen PHP developers starting with JSP and they simply declared everything to be a String. Like I mentioned in the previous post, you can advance a little over just using code directly on your page and start using separate classes for stuff. Java's OO implementation is undoubtedly better designed (in PHP it was more of an afterthought to the language). Without restarting your application, you can change most everything inside Java's class methods. Just change some code, save it, hit refresh, and the changes are there. You can't however change anything to the structure of your class (i.e. add or delete methods, change the signature of methods). PHP as a pure interpreted language does allow this, and thus has one advantage here.
    While the syntax of JSP is perfectly fine (while not as easy as PHP)
    Could you give an example of where the syntax of PHP is -really- easier than JSP? It's both simple for and while type statements delimited with some bracket and HTML between. While the syntax of languages like prolog, lisp, or scheme differ radically from that of Java, languages like C#, Java, PHP, Javascript, etc have a syntax that is absolutely quite similar to each other. For example, PHP may have some easy notation for initializing a Map with some values, that Java is lacking, but IMHO really nothing that radically different.
    Because of the relative heavywheight nature of the JVM and the session-based nature of Servlet technology its very hard for hosting companies to offer cheap yet quality shared-enviornment hosting solutions.
    You have a point there, offering cheap shared hosting solutions is indeed a problem with the current JSP platform. In fact it's the only -real- difference I ever encountered. I think much of this has to do with the problem that Java can't change the structure of classes which are already loaded. Theoretically this requires 'only' a restart of the context on which an individual web app is deployed, but in practice it seems to require the whole JVM to be restarted. This is of course problematic for a shared hosting environment. The fact is that apparently not a lot of the existing Java users require this ultra low-end functionality and thus there isn't much incentive for Sun or any of its partners to solve this problem. Nevertheless it can be argued that Sun should have, and should have a long time ago. On the other hand, don't forget that the cheap shared hosting is also not the most optimal environment for PHP code. I've heard PHP people more than once complain about global settings, versions and extensions they were unable to change or add in such an environment. Let alone the fact that a single script that does some stupid things may easily grind the rest of the system to a halt. The major advantage of Java remains that there are so many opportunities to scale up. Like I already said, start with pure JSP today, and you can keep adding things until you are at the enterprise level or anywhere in between. With PHP, when your code base reaches the size that it really DOES need packages, transactions, MVC etc etc then it's rarely an option anymore to switch to a complete different platform.
  15. Response to arjan[ Go to top ]

    I think you are misreading my point. We both agree that at a syntax and development experience level, there is not a whole lot of difference between pure JSP and PHP. The major differences between the two are the quality if cheap hosting and the ability to scale. My point is that inbetween Pure JSP on one end and sophisticated enterprise development on the other end, there is a whole universe of apps that never really had a good development solution. Even elegant technologies like EJB 3.0, Spring and Seam have medium to large business applications as their sweet spot. The problem, is that for anything that needs more than pure JSP but less than a sophisticated business-development framework, ther has (in my subjective opinion) never been a good solution. But I think things are changing.
  16. Re: JSP[ Go to top ]

    start with pure JSP today, and you can keep adding things until you are at the enterprise level or anywhere in between.
    That sounds like a nightmarish perscription for spaghetti code hell.
  17. Re: JSP[ Go to top ]

    start with pure JSP today, and you can keep adding things until you are at the enterprise level or anywhere in between.


    That sounds like a nightmarish perscription for spaghetti code hell.
    Don't get me wrong, it typically is. But A LOT of applications out there start as something tiny and small and grow out into something large. On the way so many stuff is refactored that nothing of the original application remains when it reaches enterprise level. The entire idea is that by moving up the ladder, you constantly REMOVE all the spaghetti that has been produced in the previous stage of your maturity process and re-implement it step by step with more advanced technology. Linux for example started its live as a terminal emulator that Linus wrote in assembly to play with its new 386 computer. Inherently there's nothing wrong with the incremental prototyping approach, as long as you take care to actual refactor/remove/redesign your older code. When done incorrectly, a nightmarish lump of spaghetti might indeed be the result; having an application where some code uses transactions, some other code operating on the same data sources doesn't, some pages still having scriptlets on them, while others use the full MVC approach including communication with EJB session beans etc is not an ideal system, to put it mildly. Nevertheless, Java DOES allow the path where you start small and grow large. I would also rather design for a large system right from the start, but the reality is that this isn't always possible. Of course, with Java you also don't have to start small. If you want to start large, the technology offers you this option too ;)
  18. reply to Berry Crawford[ Go to top ]

    Hi Berry, What you mentioned the most important two things, are key factors on how to make engineers doing their job easier, not the key rules on how to make applications get better performance, while the latter is just the most important factor for web applications, especially for huge scale apps, such as Facebook, Youtube , etc. As a java engineer, I'm eager to know how to reply to the challenge the PHP guy kick to us, but I'm disappointed to see no satisfactory reply coming out yet.
  19. Re: reply to Berry Crawford[ Go to top ]

    Hi Berry,
    What you mentioned the most important two things, are key factors on how to make engineers doing their job easier, not the key rules on how to make applications get better performance, while the latter is just the most important factor for web applications, especially for huge scale apps, such as Facebook, Youtube , etc.

    As a java engineer, I'm eager to know how to reply to the challenge the PHP guy kick to us, but I'm disappointed to see no satisfactory reply coming out yet.
    I agree with what you are saying. For most web apps I think developers are more expensive than hosting platforms, so I think the focus should be on productivity and maintainability. But when it comes to the very high end and very low end, I think scalability is becomes more expenisive and thus more important. For the very low end, PHP has been so successful becuase a hosting company can offer very cheap plans because they can scale their severs and stick alot of accounts on one server. For the very high end, massive scalability is clearly important to handle large loads. At both those levels PHP and the such cans scale because they use the underlying OS's process model istead of threads and use a "share nothing" architecture. What Java REALLY needs is a similar architecture. What I think would be a pretty neat open source porject is to create a quality "mod_java" that loads the VM in non-JIT mode and then processes a JSP-like page, and then kills the VM. behind that would be a framework that persisteted sessions to the database and provided some sort of MVC context. Obviously each individual request would be slower, but it should scale to heavier load than servlet-based web applications. The issue here is how expensive it would be to instantiate a new JVM instance for each HTTP request/OS process. If its too slow or two expensive in systen resources, a special JVM would probablly need to be devloped as part of the project that is optimized just for that. This NEEDS to happen and it clear Sun isnt going to do it. I think it would be a great open source project.
  20. Men, we have to stop to evaluate frameworks, stacks etc...and go into Seam. Seam is the first full stack framework in Java community trying to address easily every complexity you can find in a web application. Almost every task that is usually boring for web developer is recognized by Seam and it gives its great solution: -persistence, -security, -PDF, Mail generation, -events, -RESTful style, -remoting, -web services, -testing, -also logging! this is a good example, look at the @Logger annotation. -more... The keypoint is that everything is well integrated in the framework. It has maybe a little cost: no one of these aspects can be used out of Seam (AFAIK). This is the big difference but also the great advantage over Spring IMHO. Every component in Seam cooperate with other to deliver a great framework. I wonder, which web application can't take advantage from Seam?
  21. Seam[ Go to top ]

    I wonder, which web application can't take advantage from Seam?
    I think Seam is a well-concieved and well implemented framework, but its not a "one size fits all" technology. On the continuim from small applications to huge enterprise systems, I think Seams sweet spot is somewhere in the middle. Thats just my opinion though.
  22. Re: Seam[ Go to top ]

    I wonder, which web application can't take advantage from Seam?


    I think Seam is a well-concieved and well implemented framework, but its not a "one size fits all" technology. On the continuim from small applications to huge enterprise systems, I think Seams sweet spot is somewhere in the middle. Thats just my opinion though.
    Hmm...all the Seam features can be achieved in a EJB environment, so I think it is for huge enterprise systems. But also in plain Tomcat it is great (no EJB, no mircocontainer), and surely much better then Spring + Hibernate + JSF.
  23. Re: Too Much Freedom a Bad Thing?[ Go to top ]



    -persistence,
    -security,
    -PDF, Mail generation,
    -events,
    -RESTful style,
    -remoting,
    -web services,
    -testing,
    -also logging! this is a good example, look at the @Logger annotation.
    -more...

    The keypoint is that everything is well integrated in the framework.
    Yeah, well, I already know how to do most of those things using other technologies. At the time it sucked to have to learn all those things, but what's the advantage for me to learn them all over again in a different way? I hope seam is extremely well documented because nothing is more annoying than being stuck on a problem you already know how to solve.
  24. Subtext of the debate[ Go to top ]

    It seems like these kinds of debate crop up with regular intervals. I wonder if all these people moving to "newer" frameworks are doing it out of fear of loosing their jobs, since big business seems to be off-shoring work right and left. clearly, if we keep changing the technology, than businesses have a harder time shipping work off shore. At what point is moving to a different framework or language productive? Isn't it just moving the target? It's clear that dynamic languages have many benefits and same is true of statically typed languages. I don't understand the need to be bi-polar. It's not one or the other. At the end of the day, all I care about is getting my job done using the tools my client has chosen. If that is C#, Sql, Java, LISP, Javascript, python, perl or ruby makes no difference to me. The battle we're loosing here isn't language X versus Y. It's empowering developers, so that we get to choose the tool, instead of having some executive making a decree that everyone has to follow. From my limited experience of 10 years, when developers get to choose the tool, development tends to go more smoothly. When executives make a blanket decree to use technology X, it tends to lead to problems.
  25. re:[ Go to top ]

    When executives make a blanket decree to use technology X, it tends to lead to problems
    I know I have had horrible expeirences in having totally inapropriate technology dictated to me many times, but lets not forget that an executive has to think in terms of hiring staff with particular skills, leveraging talent accross projects, paying for support contracts, etc. I think enterprise standards are not a problem per se, the real problem is that when the people in charge dont have a clear picture that not all applications need the same tools. A good enterprise architect will decide on a few different stacks that can be applied to different problem domains.
  26. I'm working with Hibernate and Spring MVC to develop web applications. Using frameworks like Appfuse significantly reduces the amoung of coding. However, the amount of time needed is still **enormous** compared to scripting languages like PHP, Rails etc. The point is, that there are so many Java components into any one app, all of these components developed by different people, that the chances of having a little problem here or there adds up to a mountain of little issues. Add a little Hibernate, one of the most complex Java apps I know, and the lack of documentation for many components (not applicable to Hibernate BTW) and you find yourself struggling through one issue after another. It just takes a lot of time that is not really about programming functionality. Especially on the client side development can takes ages, because it's basically not possible to step through front end template execution (e.g. Freemarker, JSP). And even though we have a mountain of frameworks, there's never a lot of ready made functionality available. I guess in Java space we love building the frameworks. But that's it. After ignoring the web for a decade (it was called JSP), the Java community came up with JSF. A framework that relies on POSTS for all of its interaction and is generally useless for anything but standard business backoffices. If there was a smiley for COME ON!!!, I would put it right here. The one standard answer to this which I love is, "every job requires its specific tool". Good point and very true. So, if JSF is covering the niche of backoffice interfaces, which kick ass toolbox covers the frontend? I suppose GWT is an impressive piece of technology in this area, but still pretty niche. I haven't ever seen a GWT website that didn't look like it was made by Google. And if you ever want something that is not covered by the standard components: good luck! Using Spring MVS with annotations actually leads to a level of productiveness. Be it on a plumbing kind of level. Spring annotations significantly reduces the XML headache of before. Things are looking better and better there. Spring actually makes my life easier. At the same time, Spring MVC doesn't offer anything like the plug and play components market of php. Here, have a blog. Throw in a forum. etc Have an interactive datagrid. So, as good as it is, it doesn't deliver 'screaming productivity'. Nobody seems to care about this stuff in Java. And there's always another frameworks around the corner to fragment the marketplace even more. I think this is the problem. Conceptually, the tools in the Java space are amazing. You *think* that this should reduce the amount of programming time significantly vis-a-vis PHP and the like. Unfortunately, this often is just not true. Many of the tools used to reduce programming time, do this at the expense of complexity under the hood. Or they're so new that there's hardly any ready made functionality available. Then there is hosting. It's very hard to run Java in a shared hosting environment and there are therefore limited affordable hosting options. Which is kind of weird. Why hasn't there some focus here to resolve this issue? Without ease of hosting, you won't find a lot of enterprising cash strapped people say, let's build it in java. I think if you want Java succeeding in the web space, you need to look at the kind of things developers want to create and tune your frameworks, JVM and development tools towards that. "It" has to be easy. And I do mean this to include regular websites where designers want total design flexibility and pixel perfection and not just backoffice websites where the big vendors see a neat opportunity to sell there little widgets. So then it becomes important to create easy support for accessing Java objects through the front end, e.g. Ajax and Flex. You want developers to have a powerful scripting language, with code insight, object property acces and solid debugging options. You want ready made front components, be it low level like calendars, trees etc (no, input type=text WON'T suffice) with full fledged demo's. You want extensive documentation. I guess, the bottom line for me is "simple things should be easy". And in Java, simple things are often just too hard.
  27. Spring MVC[ Go to top ]

    I consider Spring MVC as Struts in perfection, and I despise Struts. Spring MVC is well engineered, nevertheless it's stone age programming. Example: With Spring MVC (and Struts) the programmer cannot fully abstract from low-level http request parameters. With JSF you can, the components fully encapsulate their decoding. Even worse, Spring MVC opens a ton of security holes. Just think of selections where it is vital to verify that the selection submitted by the user is really one of the available selection options. With JSF (and Seam) the framework takes care of this validation and the programmer can fully abstract from such kind of problems and concentrate on the business logic. If I have to choose between Spring MVC and JSF/Seam, I dump Spring MVC immediately. Compared to Spring MVC, JSF/Seam is a huge productivity step forward. Nevertheless, the future eventually belongs to Rich-internet-apps, and this is why Java is losing the battle for the web. PHP btw is losing the battle too. Flash and Silverlight are poised to be the big winners, unless Sun hopefully takes action soon and improves the unimpressing Java FX.
  28. GWT[ Go to top ]

    Flash and Silverlight are poised to be the big winners, unless Sun hopefully takes action soon and improves the unimpressing Java FX.
    I think GWT should not be left out of your list of potential winners in the rich-app world. GWT leverages all of the nice development tools and practices we as Java developers have come to appreciate, e.g. debugging of your UI in Eclipse and unit testing your control logic. It's Apache V2 licensed, does not require a plugin and its community is gaining momentum (have a look at the gwt-ext and gwt-widgets projects) Furthermore, it is already 'proven technology'. See all of Googles web-based software offerings (gmail etc).
  29. Re: GWT[ Go to top ]

    Gmail and Google Calendar were NOT written with gwt. They were the reason that made google create gwt in the first place (to address large ajax projects). IMHO, gwt is only suited to somewhat highly interactive apps, but it really delivers when it comes to ease of ajax programming and small-size js files.
  30. Java is now fragmented as Unix that way Microsoft has been successful. But Java offers much more than a language to an enterprise and to the technology world. It offers flexibility to use a framework/solution to a particular problem. The problem is in the usage of technology and not what it can offer. The issue is that most enterprises are locked into vendor specific Java technologies, which ties their hands. The other issue is with developers and architects, who tend to believe that Java is a very simple language and that can easily be tamed. This naive beliefs tend to give a picture that Java is loosing. But in reality architects who are strong with Basics (Frameworks, Patterns) and Software engineering principles can use Java can give an enterprise the desired ROI. The future of Java is exciting. As far as I see, JVM will be proliferated with host of non-Microsoft languages and offers much wider choices and ease to solve problems. But again with ease, comes the correct usage. Correct usage is always questionable as it depends on the developer/architect using the technology
  31. Web Frameworks[ Go to top ]

    Early on, ASP was horrible, even for it's time. Recently, ASP.NET has become great because Microsoft has been so aggressive and persistent in developing it, polishing it, and fixing its problems. And the way it is so well integrated together with the IDE, framework, language, and server. Their different teams all work together in a very coordinated fashion. They often add features to the language to facilitate the framework, or adjust the ASP framework to accommodate some new IIS design. Personally, I prefer Stripes (Java MVC framework) to ASP.NET, but I definitely admire the polish, ease of use, and novice-friendliness of ASP.NET. I like the freedom and flexibility of the JVM platform over .NET and I like the elegance of MVC over ASP.NET development (although I presume the forthcoming ASP.NET MVC will be excellent) JSF is nearly unchanged since it's 1.0 release. It had major problems and shortcomings when the first version shipped in 2004, and they are still there now. They have some really smart people on the JSF design team, but there is something fundmaentally wrong with the governance of that project for it to have stalled in such a flawed state for so long. Is Java losing the web market? It's probably losing some market share, but I think JVM is still extremely fertile, relevant, and is a key part of the bleeding edge developments. I see Microsoft taking more mindhsare among businesses I work with, and that's not just because of ASP, but because of SharePoint, VSTO, SQL Server, Analysis Services, and a general all-Microsoft mentality.
  32. Re: Web Frameworks[ Go to top ]


    JSF is nearly unchanged since it's 1.0 release. It had major problems and shortcomings when the first version shipped in 2004, and they are still there now. They have some really smart people on the JSF design team, but there is something fundmaentally wrong with the governance of that project for it to have stalled in such a flawed state for so long.
    The semi stallment came to my knowledge from the jee5 schedule. JSF 1.0 - 1.1 was a fixup of minor issues 1.1 - 1.2 fixed the html mixing issues, prepared some stuff like custom life cycles which are vital for ajax and added the unified el. The main problem was that the 1.1 - 1.2 move was constrained by the JEE5 release schedule. The big overhaul which in my opinion already should have been done in 1.2 is now in 2.0 and things look really good. But back to the topic. I think that java has lost itself somehow in framework infight, while other platforms are moving happily away from html at all. I dont see a bright future in html, html based webapps are at the last third of their lifetime. Where things are going is pretty clear with silverlight and flash based ui frameworks. And javafx has a pretty bad starting position there. And yet while something is along the horizon which can really damage javas reputation as web language we still get another web framework more or less doing the same as 15 others every week. Java has problems a) We have the frameworks which could do it, but our visual tooling for people easily jumpstating into those is more or less lousy and not working across tools. b) There is flash based stuff easy to deploy, there is silverlight easy to deploy in the long run, and we still fight with jre browser plugin issues (partially past issues but still issues) We had the first rich client browser platform, we could not make it a standard, due to a) Runtime size b) Browser plugin problems c) Memory size problems d) Untolerable startup times of the applications See the big problem there. Scripting languages are not the problem. I work with them around 80% of my times, and I can see there merits but also their huge problems. They are so dynamic that you can end up in a mess where C++ is a kindergarden compared to it if you do not do a heavy self contrainment in the long run. No static type checking means you have to program your type contracts yourself into methods to avoid messes and there goes the self propagated reduced lines of code advantage. Add to that that you have to work heavier with unit tests than before and that someone might mess up your based classes and objects because it is cool. Scripting languages do not scale well, period, while being excellent at small stuff, you really have to be careful in big programs, especially the highly dynamic ones. If you want to do yourself a favor then dont jump on the rails/grails or any other scripting framework bandwagon early, do a proper evaluation, train your team into what they are allowed to do or not, or simply buy javarebel for your team and stick with a working proven path!
  33. Re: Web Frameworks[ Go to top ]


    But back to the topic. I think that java has lost itself somehow in framework infight, while other platforms are moving happily away from html at all. I dont see a bright future in html, html based webapps are at the last third of their lifetime. Where things are going is pretty clear with silverlight and flash based ui frameworks. And javafx has a pretty bad starting position there.
    And yet while something is along the horizon which can really damage javas reputation as web language we still get another web framework more or less doing the same as 15 others every week.

    Java has problems
    a) We have the frameworks which could do it, but our visual tooling for people easily jumpstating into those is more or less lousy and not working across tools.

    b) There is flash based stuff easy to deploy, there is silverlight easy to deploy in the long run, and we still fight with jre browser plugin issues (partially past issues but still issues)


    We had the first rich client browser platform, we could not make it a standard, due to
    a) Runtime size
    b) Browser plugin problems
    c) Memory size problems
    d) Untolerable startup times of the applications


    See the big problem there. Scripting languages are not the problem. I work with them around 80% of my times, and I can see there merits but also their huge problems...
    So you think people are more comfortable with silverlight and flash stuff right? Ask people how comfortable they are with online banking or any mission critical UI using flash/silverlight? HTML applications are at last third of its life time??? Proof please.
  34. Re: Web Frameworks[ Go to top ]

    So you think people are more comfortable with silverlight and flash stuff right? Ask people how comfortable they are with online banking or any mission critical UI using flash/silverlight?

    HTML applications are at last third of its life time??? Proof please.
    Well lets say it that way, the ajax craze the last years was just the beginning. Lets sum it up, history currently is repeating itself. HTML in its current browser supported incarnations is a lousy UI model. UIs need a good set of controls, a decent isolatable object model and events and statefulness. HTML is none of them. We are at a borderpoint where people demand rich client functionality out of that broken model. So we spend hundreds of hours to shoehorn that into that model, we spend the same amount of time to support legacy browsers which should have been killed years ago. We are facing the wall currently and ajax is not the solution. You can shoehorn a lot of things into it, but DHTML does not have decent namespacing no decent subdom tree isolation the event callback paths into the server are all hacks. Others deliver rich client ui frameworks out of the box without all this. This is the exact same thing which happened in the mid eighties when the old terminal model which is pretty similar to html but was more sophisticated in terms of user input control handling than html probably ever will be, was replaced slowly but surely by rich client frameworks. I dont need to many proofs to make this assumption I just have to see what I have been spending my time on a lot the last months (mostly ajaxy stuff demanded by customers) Being around since 82 having seen a lot of ui technology shifts I see the patterns again all over the place we had in the 80s. I would even say the entire web application craze just turned back the wheel to a situation rather similar to the 70s technologywise, with dumb terminal inputs being state of the art again while people not accepting that anymore. I would take this warning seriously, HTML is a flawed application frontend model, and no one really is willing to fix it seriously, especially not the one having the browser with around 70% marketshare pushing a rich client ui again and who did not have any interest in cross plattform applications upfront before entering the browser market! I know this is no definite proof except that history usually repeats itself and you can learn a lot from looking at it.
  35. Re: Web Frameworks[ Go to top ]

    So you think people are more comfortable with silverlight and flash stuff right? Ask people how comfortable they are with online banking or any mission critical UI using flash/silverlight?

    HTML applications are at last third of its life time??? Proof please.


    Well lets say it that way, the ajax craze the last years was just the beginning. Lets sum it up, history currently is repeating itself.
    HTML in its current browser supported incarnations is a lousy UI model. UIs need a good set of controls, a decent isolatable object model and events and statefulness. HTML is none of them. We are at a borderpoint where people demand rich client functionality out of that broken model. So we spend hundreds of hours to shoehorn that into that model, we spend the same amount of time to support legacy browsers which should have been killed years ago. We are facing the wall currently and ajax is not the solution. You can shoehorn a lot of things into it, but DHTML does not have decent namespacing no decent subdom tree isolation the event callback paths into the server are all hacks.

    Others deliver rich client ui frameworks out of the box without all this. This is the exact same thing which happened in the mid eighties when the old terminal model which is pretty similar to html but was more sophisticated in terms of user input control handling than html probably ever will be, was replaced slowly but surely by rich client frameworks.

    I dont need to many proofs to make this assumption I just have to see what I have been spending my time on a lot the last months (mostly ajaxy stuff demanded by customers)
    Being around since 82 having seen a lot of ui technology shifts I see the patterns again all over the place we had in the 80s. I would even say the entire web application craze just turned back the wheel to a situation rather similar to the 70s technologywise, with dumb terminal inputs being state of the art again while people not accepting that anymore.

    I would take this warning seriously, HTML is a flawed application frontend model, and no one really is willing to fix it seriously, especially not the one having the browser with around 70% marketshare pushing a rich client ui again and who did not have any interest in cross plattform applications upfront before entering the browser market!

    I know this is no definite proof except that history usually repeats itself and you can learn a lot from looking at it.
    I don't get it, please define your definition of RC functionalities. Do you consider a button that will shine after being clicked RC functionality?
  36. Re: Web Frameworks[ Go to top ]

    it.


    I don't get it, please define your definition of RC functionalities. Do you consider a button that will shine after being clicked RC functionality? Complex userinteractionw without page refreshes, self validating controls, control rearrangement depending on the input given, change listeners which can trigger other actions etc... all of that without any round tripping to the server! Simple a normal user interface with self validating inputs and complex user interface elements up to elements which even would allow the drawing of images in real time. Html with its stateles protocol and simple text input elements is not up to the task! Or in other words, controls more complex than a simple input, interaction more complex than a simple http post and server side round tripping only for sending and receiving raw data! Or in other words the web is moving towards the user interface interaction of the late 80s- mid 90s and HTML is still stuck in the user interaction of the mid 70s and early 80s! What happens now is the reinvention of the wheel which alredy was reinvented in the 80s!
  37. Re: Web Frameworks[ Go to top ]

    it.


    I don't get it, please define your definition of RC functionalities. Do you consider a button that will shine after being clicked RC functionality?


    Complex userinteractionw without page refreshes,
    self validating controls, control rearrangement depending
    on the input given, change listeners which can trigger other actions etc... all of that without any round tripping to the server!

    Simple a normal user interface with self validating inputs
    and complex user interface elements up to elements which even would allow the drawing of images in real time.
    Html with its stateles protocol and simple text input elements is not up to the task!

    Or in other words, controls more complex than a simple input, interaction more complex than a simple http post
    and server side round tripping only for sending and receiving raw data!

    Or in other words the web is moving towards the user
    interface interaction of the late 80s- mid 90s and HTML is still stuck in the user interaction of the mid 70s and early 80s!

    What happens now is the reinvention of the wheel which alredy was reinvented in the 80s! If the UI is validating data and sending it back to the server, drawing images in real time and other complex input control, this is not a browser. With flash and silverlight, you still need to install plugin in a browser, which means you are installing an application into an application. If the functionalities from these plugins are all you need, why do you need all overhead from plugin infrastructure? Simply create a open standard standlone application that is lightweight with the capability of handling heavy duty jobs. Then there is nothing to do with HTML because your app can still use HTML as markup language in translation of your GUI rendering.
  38. http://www.plat-forms.org/2007
  39. Just posted a relevant response here : Java : if (compete with PHP / Ruby / Python) { stop fixing the syntax and start fixing the runtime } In summary it talks about the fact that we need to focus on the infrastructure and not so much the syntax or dynamism (closures / dynamic typing / duck typing) of the language itself. It suggests the following : a. Make it easy to host java apps on multi tenant application servers. b. Do away with the compile-build cycle (ie. auto compile like PHP / Python / Ruby do). Dhananjay