Expanded Arguments On Why Java Is A Dead-End For Enterprise App Dev

Discussions

News: Expanded Arguments On Why Java Is A Dead-End For Enterprise App Dev


  1. Editor's Note:

    This posting came in from Forrester's Mike Gualtieri. Just to give a little background, TheServerSide has run several articles in the past few months that come down extremely hard on Forrester. One such article that comes to mind is Richard Mayhew's that ends "I really hate those guys sometimes," which in truth, was actually edited down to that, as the original sentiment was much less 'Christian' in its tone. And of course, the comments from TSS readers have been equally harsh.

    Richard Mayhew's take of Forrester's Research
    Richard Mayhew on Forrester's take on the future of Java

    But I think you really have to hand it to Mike Gualtieri for stepping back into the ring with the TSS crowd and offering another angle on his take on the future of Java. I'm not in tune with what he has to say, but I give the guy props for not backing down. Here it is:


    Many of you have asked in one way or another to expand my arguments on why I think Java is a dead-end for enterprise application development. Registration at the Forrester site required. But, it is free and then you can download my 50 slide presentation. If you want to cut to the chase start at slide 14.  Go here for the link to register for free and then download the slides.

    Threaded Messages (38)

  2. I don't want to register in forrester.com in order to read your article. Could you make it freely available? It might seem like a trivial thing to ask, but consider this: what if I had to register for every website with an article that I want to read? I'd have thousands of logins in different websites by now.

    IMHO, you should make it freely available like TSS does with their own articles.

    Thanks.

  3. +1

  4. I wish you did not have to register[ Go to top ]

    Hi guys,

    I wish you did not have to register at Forrester.com to get this. But, I work for Forrester and those are the rules. At least the registration is free and they agreed to let me make these available,

  5. Registration[ Go to top ]

    I don't know why I bothered to tell the truth on the first registration page (Profile); when I reached the second (Role) I was forced to lie (or give up), as you have to make choices where none of the options is true. Also the "Continue" button appears to be enabled after the first choice or two, but doesn't actually work until you have made a choice from all of the sets of radio buttons.

    Anyway, I eventually got to the PDF. If you were looking over my shoulder, this is the URL you would see me browsing:

    http://a964.g.akamaitech.net/f/964/714/1h/www.forrester.com/Marketing/Campaign/BinaryContent/0,5983,2249,00.pdf

  6. Registration[ Go to top ]

    Anyway, I eventually got to the PDF. If you were looking over my shoulder, this is the URL you would see me browsing:

    http://a964.g.akamaitech.net/f/964/714/1h/www.forrester.com/Marketing/Campaign/BinaryContent/0,5983,2249,00.pdf

    Thanks. I do no read documents accessible only via registration. If a blogpost contains a link to a document I need to read and I must register or login somewhere, it is not a blogpost. It's an advertisement.

  7. I wish you did not have to register[ Go to top ]

    Don't worry, reading your first arguments in your blog is more than sufficient ... :o)

  8. Mike,

    Why were Forrester's previous articles open for public view but now you seem to be trolling for a mailing list.

    Pretty sad. I don't want to register with Forrester giving Forresters's previous articles were amateurish at best.

    If you want to talk smack, why not just post your "wisdom" with no strings attached. I hope your new insights are better than these little gems of "premium wisdom":

    • Business requirements have changed. The pace of change has increased.

    Master of the obvious

    • Development authoring is limited to programming languages. Even though the Java platform supports additional programming languages such as Groovy and  JRuby, the underlying platform limits innovation to the traditional services provided by Java. You can invent as many new programming languages as you want, but they must all be implementable in the underlying platform.

    ALL languages must be projected onto the underlying platform.

    • Java frameworks prove complexity. Hibernate, Spring, Struts, and other frameworks reveal Java’s deficiencies rather than its strengths. A future platform shouldn't need a cacophony of frameworks just to do the basics.

    No, they provide abstractions to standard design problems. This is not Java specific. There are frameworks for other languages too. In fact their are .NET equivalents of the frameworks.

    • Java is based on C++. Is this really the best way to develop enterprise business applications?

    Wow. Seriously.

    •  Java has never been the only game in town. C# is not the alternative. It is little more than Java Microsoft style. But, there are new developer tools such as Microsoft Lightswitch and WaveMaker -- and traditional but updated 4GL tools such as Compuware Uniface and Progress OpenEdge. And don’t forget about business rules platforms, business process management (BPM), and event processing platforms that enable faster change offer by enterprise software vendors such as IBM, Progress, TIBCO, Software AG.

    Gee I wonder if Lightswitch or the other competitors are written in a computer language like Java or C#. Nope, just UI to magic and the tools cover all aspects of development and problem domains. No need for custom code or plugins or anything like that.

     

     

  9. Maybe Mike can lend me his crystal ball when's he's done with it?

  10. Credible and plausible[ Go to top ]

    Hi Joe, I don't claim to have a crystal ball. Rather, I hope I have presnted credible and plausible arguments about why Java is a dead-end for enterprise business applications. You will notice in the slides I have a taxonomy of software and I identify what applications for which Java is an excellent choice.

  11. Credible and plausible[ Go to top ]

    Mike,

    Ok, I took the bait and downloaded the PDF.

    Not sure why your contention is with Java alone. It seems that all imperative programming languages are deficient in your view.

    BPMS and Rules Engines are more of a meta-programming paradigm, don't you think. BPMS and Rules are quite easily represented in Java as well as other mainstream languages -- or at least the projections onto a specific engine is concerned. In fact the vendors you represent have Java as a dialect in describing a solution domain or are flat out Java based solutions.

    CEP really has nothing to do with a programming language per se. It is completely different system architecture that once again can be expressed in Java as well as other languages.

    I am surprised you did not explore custom DSL as a core concern for new enterprise development. Once again more of a meta programming concern.

    I will concede Java has flailed in the UI space. But there have been advances. Just my two cents.

    I am not buying the CAD style program development of the other systems you mention in your article. Powerbuilder is a glaring example of a virtually defunct toolset. You cannot cover all problem domains in a drap and drop model. At least not in my experience. You will need custom software to support any solution other than kindergarten trivial.

    I still don't see you beefing out any argument against Java viz a viz your last assessment.

  12. Credible and plausible[ Go to top ]

    Mike,

    Ok, I took the bait and downloaded the PDF.

    Not sure why your contention is with Java alone. It seems that all imperative programming languages are deficient in your view.

    BPMS and Rules Engines are more of a meta-programming paradigm, don't you think. BPMS and Rules are quite easily represented in Java as well as other mainstream languages -- or at least the projections onto a specific engine is concerned. In fact the vendors you represent have Java as a dialect in describing a solution domain or are flat out Java based solutions.

    CEP really has nothing to do with a programming language per se. It is completely different system architecture that once again can be expressed in Java as well as other languages.

    I am surprised you did not explore custom DSL as a core concern for new enterprise development. Once again more of a meta programming concern.

    I will concede Java has flailed in the UI space. But there have been advances. Just my two cents.

    I am not buying the CAD style program development of the other systems you mention in your article. Powerbuilder is a glaring example of a virtually defunct toolset. You cannot cover all problem domains in a drap and drop model. At least not in my experience. You will need custom software to support any solution other than kindergarten trivial.

    I still don't see you beefing out any argument against Java viz a viz your last assessment.

    I've been working with business rules, expert systems and brms since 2000. It seems like when ever some "discovers" business rules and bpm, they feel it's the solution to many problems. As much as I love business rules technologies, it's no panacea. First off, BRMS and BPM are for expert developers to build tools and applications for a variety of end users. The final end user might be a developer, business analyst or non-technical business user.

    Since the late 80's the main challenge of employing business rule technology has been finding qualified rule developers and training end users. There are numerous failures in the Business rules domain over the last 3 decades. For those who feel BPM and BRMS is a general purpose technical solution, history has shown that it's not the case. If that were true, things would be quite different today.

    business rule technology is powerful when used properly in experienced hands. Gaining that experience takes years of dedication. From first hand experience, 75% of the rule developers out there aren't really doing rule development, they're just writing procedural code in a rule language. To really see the benefit of rule technology, it has to be used properly. Even then, it will always require writing code in C#, Java or some other language. That's why most of the business rule products provide that functionality.

    I would say to those writing these type of articles to avoid hyping business rules. It only hurts the industry when business users have unrealitistic expectations of what the technology does and the value it delivers.

  13. "Many of you have asked in one way or another to expand my arguments"

    No, we asked you to actually HAVE some arguments.

  14. Registration and the like...[ Go to top ]

    Yeah, I too am not overly enthused about having to register to get content, and I'm a little loath to put up a link that requires such action. Having said that, Mike has been at the center of a few good discussion in the past little while here at TSS, not to mention the fact that we've essentially put a corkboard around his neck and have been throwing plenty of darts his way. Along with the fact that he's taken our jabs seriously enough to come back with a reasoned response makes me think that a link over to Forrested, despite their 'registration' policy, isn't too unreasonable.

    Let's not be too rude to Mike. Mean and nasty is expected, but we're too civilized here on theserverside to be rude.

  15. Whoever wrote this obviously has no clue how to develop software.  Enterprise software development is not easy.  Just like building a rocket is not easy.  It takes trained engineers to do it.  This presentation is written by someone who can't do software development...if they could, they would not be working for Gartner, they would be doing software development.

    Why would I move from the platform/vendor independent Java to a super expensive, proprietary, bloated, vendor lockin, tool like the author suggests? These bloated tools do nothing but make slow, bloated systems which do not work and scale and increase the cost/complexity of doing business.

    Failed projects are failed projects.  No language or development tool is going to magically make projects successful.  Poor business requirements, poor project management, unreasonable expectations, low quality developers, and politics all contribute to failed projects.  

    As far as user experience, yes JSP stinks, and so does JSF.  GWT is light years ahead of JSF and Javascript based frameworks like Ext JS are even better.  What should we use for front-ends? Use the proprietary, patent crippled, super expensive Silverlight or Flash?  If so, why use a web browser at all?  Heck, we can increase our development costs even more and make specific applications for each platform out there.  yeah that makes sense.

     

  16. boredom[ Go to top ]

    +1

    I will never understand why some people get involved in areas where they have no skills for it. Apparently out of boredom or to make other impressed.

  17. Just ignore[ Go to top ]

    +1

    The graph showing .Net vs Java popularity almost made me pee my pants :)

    I think Mike would do great at Comedy Central.

  18. Registration -- no.

    Having read several summaries on this topic, though, I find something greatly lacking in such argument -- any credible point to a replacement for Java.

    Java's far from perfect, but what are you really going to replace it with in this role?  C#?  Despite Mono it's not really anything an enterprise should rely on outside Windows -- and not everyone wants to lock their whole enterprise into Windows indefinitely?  PHP, Ruby, etc?  No, there is no evidence that they can really scale to the needs of large, complex enterprise software -- as much due to their lack of strong static type checking and related failings in refactoring tooling as due to runtime limitations.

    It's fashionable to throw stones at the old dog, but unless you want to be a Windows-only lackee, the market has yet to come up with a credible alternative.  You might argue that Scala is such an alternative -- and I'd agree except that this builds on the same Java ecosystem, so it's really somewhat of a Java++ rather than a Java-killer, despite the huge syntactical differences in the languages.

    If you argue that Java is too complex for a given need, then its likely that you are simply using too complex of a framework (or not enough of one) for the task at hand.  In this regard the ecosystem around the language can be confusing, but the ecosystem is also huge and vibrant.

    Overall, yes, Java is imperfect, but I've seen nothing persuasively argue that it's not the best we've got.  Until there's a credible and clearly better replacement for it, Forrester, et al, should find something else to do.  If there is a clear and clearly better replacement, then Forrester, et al, would have articles leading with the wonders of the replacement -- but instead they throw stones and confusion around the current market leaders.  One might cynically argue that this is a good way for them to get paid to do more research....

  19. Agree[ Go to top ]

     No, there is no evidence that they can really scale to the needs of large, complex enterprise software -- as much due to their lack of strong static type checking and related failings in refactoring tooling as due to runtime limitations.

    Agree! Actually, there are a lot of cases in which people migrate from Python, Ruby, Php to Java as their business becomes really large.

    Taobao.com(more than 300 million users) my company migrate from php to java for years.

    Yesterday, infoQ, Catching up with Nuxeo: Switching from Python to Java

     

  20. I am not surprised[ Go to top ]

    John R. Rymer with whom Mike Gualtieri did "the research" doesn't even know about the existence of 64-bit JVM. See it for yourself: http://blogs.forrester.com/john_r_rymer/10-06-21-why_im_worried_about_javas_future.

    Camreon, I knew you asked us not to be too harsh on Mike and his "findings", but these guys are just a plain joke.

  21. I hate these guys![ Go to top ]

    Never do meaningful things but bullshit. Lier, cheater. Unfortunately, some innocent new comers are confused and waste a lot of time. Those people who are solving leading-edge problems do not have time to waste with these hollow so-called consultant.

  22. I read the PDF. I wish it'd have been the actual teleconference, because then you'd have been able to gauge the intelligence of the audience by how much they laughed. More laughter = more intelligence.

    It's all FUD.

    The poitns that he uses to decide are a trend toward faster change, and toward a great user experience. He says java wasn't designed to work with either, so it's clearly dead. 32% of projects succeeded, 44% were challenged, 24% failed, according to a CHAOS summary 2009 report. I couldn't afford the report itself, and honestly I'd be pretty sure the money'd be wasted anyway.

    But the Forrester guy says this:

    Java is not the best choice to satisfy the two megatrends for enterprise application development.

    1. The power of Java is not designed for business applications.

    2. Java innovation does not necessarily equal application development innovation.

    3. Java's strong suit is not user experience design and adaptability (the two megatrends).

    4. Better alternative exists.

    Okay, go ahead, finish laughting. he actually explains these: he says Java can be difficult to learn because you have to learn the frameworks for presentation, etc., and OO doesn't equal automatic productivity and great design. The number of frameworks is a problem, too, he says. Based on 395 eclipse developers, plumbing frameworks are the most popular - with 22% using spring. (of 395. Equinox got 7%... what is his definition of a plumbing framework, exactly?)

    He says Java innovation doesn't equal app development innovation: cases in point, j2ee, osgi, jsf, javafx, and mobile.

    Innovations were pushed by people who were interested in the technology, not in application development, so innovations targeted improvments, not developer productivity.

    He says Java sucks at UI and adapability, saying Swing is a nightmare, JavaFX is a failure, and he says "Spring and Hibernate are good for developers, but are table stakes for bussiness applications." What are table stakes? I don't know. Maybe they're expected costs?

    Finally he gets to some meat: basically, 4GLs are GOING TO TAKE OVER. We knew it all along, when they hit the scene in 1995 we knew 3GLs were dead, dead, dead. So dead.

    He also mentions newer programming languages are designed to make certain apps easier, pointing out "ruby on rails," and "web2py" specifically ("and many others") apparently unaware that RoR is a library for Ruby and web2py is a framework itself.

    In other words,  these things that are going to kill off Java either have the same characteristics as Java when it comes to the points he's criticizing, or they've been scheduled to kill off all programmer jobs for the past 15 years with no headway whatsoever except in the minds of Forrester analysts.

    I guess it's good that the author is willing to engage an audience, but i sure wish he'd pay attention to the holes in his own arguments before defending them. He makes so many leaps of logic that it's not funny, and gets some basic stuff just plain wrong.

  23. The slide deck demonstrates a very poor analysis of the problem. The crux of argument seems to be that CEP, BPM tools offer better productivity than a 3GL language such as Java. However CEP, BPM tools that I work with require deep knowledge of Java e.g. the IBM BPM tool set which executes on IBM Process Server. Indeed one can build rules in ILOG using Java. So essentially the argument seems to be about developing Enterprise Apps in Java to avoid developing them using Java.

    Reading between the lines, Mark really seems to be comparing custom application development (CAD) against packaged enterprise applications. This is the age old build vs buy decision, repackaged to focus on the merits of packaged apps against those built using Java. There are many arguments for both and if the decision does fall on the side of CAD there are many platforms that can be used of which Java is just one.

    So Mark, if you want to have a debate on build vs buy then do so but don't pick on a specific language when examining the build side. All languages have their pluses and minuses and ultimately any build vs buy decision depends on context, as does the choice of which language to use when decision comes in favour of build.

    Finally I am indirectly a Forrester subscriber (through my membership with the BCS), so this is very disappointing. Normally Forrester research is so much better and I used it extensively when I was writing my MBA dissertation.

  24. Many apologies, meant Mike instead of Mark:)

  25. Confused[ Go to top ]

    Ok, so in part 1 of the PDF it is stated that Java is bad because it has an enormous amount of frameworks that you may or may not need to learn. The second part is all about how if those frameworks are prepackaged and sold to you as a product, then they are the future. Eh?

    And about the UX part; being in the middle of developing an iOS application, I know for sure that as a development platform, Java is a decade ahead of Apple's XCode / Objective-C. (I have a fairly length blog post about that, with arguments ;-) So how is it possible that Java is failing, while obviously technically lesser platforms are on the rise? 

    One last remark about JavaFX; the choice of using a DSL turned out to be the problem; people had trouble learning it. But JFX is an attempt to put UX back into Java at a higher level, exactly because of the revival of UX on all the mobile platforms. And as observed with iOS (see above), JFX's success will solely depend on the amount of platforms it runs on, not on any technical factor.

  26. Response to Mike[ Go to top ]

    Hi Mike,

    I was just at FOSDEM where there was a healthy and robust discussion on the future of Java. The consensus seemed to be that there's no viable alternative and that going down the '4GL' path that you suggest is only taking us back into the dark ages of proprietary, locked-in solutions that are incredibly frustrating and expensive to customise. There are _very_ few problem domains that I've worked in where a 4GL will be the solution out of the box. A few people also wondered about the Java bias of your analysis - why did you not explicitly give equal coverage to the popular .NET ecosystem?

    You also stated that Java had failed as a front-end technology and as it stands I kind of agree.  Yet you offer no meaningful alternatives and I don't think you have taken a serious look at 'new' frameworks such as Grails, Scala Lift, Seam, GWT, Spring MVC and a host of others in the Java ecosystem.  Not to mention that with the whole 'HTML 5' thing arriving on our doorsteps - the HTML/CSS/Javascript combination with WebSockets and/or Ajax calls will probably dominate.  But here's the really important bit - it's actually often not the technology but the expertise of your user experience people and/or graphic designers that actually make the difference here.

    On the Java language itself I think the OpenJDK needs to be given a chance to put in the sort of features that developers of the future will need.  Yes the language itself has stalled somewhat, but the process is moving again.

    Java has also got arguably the most powerful and flexible VM on the planet, ontop of which a host of useful languages can be run. For example, members I've talked to in the London JUG happily prototype sites in Grails, solve functional problems in scala, perform concurrent programming in Clojure and write core domain logic in Java. And yes they even use Java based rules engines and BPMs - whatever the appropriate language/tool is for the job.  Again this all runs on hte Java ecosystem.

    I was also on the Forrestor phone call on this topic and the various IT staff members I was with saw were dissapointed with your analysis - not that you didn't have some valid points about Java's current weaknesses but that you didn't seem to be up to speed with the latest advances in the ecosystem and that secondly that you offered no realistic alternatives.

    Discussion is good though and I applaud your efforts in continuing to engage!

    Cheers, Martijn

  27. Throw out your dead[ Go to top ]

    Not sure we need to expand the argument but rather deal with at least one guy talking to the business community about FUD.  After dealing with Microsoft’s FUD machine the first half of the decade, you think the java community would know how to slot this guy and go through the steps to de-fang him. Can someone document this pattern?

    Even while Microsoft’s superior marketing machine and well promoted alternative heaped it on, it never got traction.  So why one little guy now?  I’d say that after a decade, Java has become mature and the innovation curve has flattened out.  Oracle will still drive innovation but at a higher ROI threshold than Sun.  The true multiplier, the community, has put this horse away wet but is seeing less room to move.  The threat is the paralysis of not knowing where the innovation is going to come from next – if it comes.

    Do I go software/platform/infrastructure as a service, cheap offshore, functional? My feeling is we are in a holding pattern until some new catalyst drives things like the internet did.  I’m looking towards start-ups to point the way.

    As for today’s FUD attack, it seems Forrester has to sell the sizzle and generate it’s own demand.  They say Wall Street moves on greed and fear, so maybe it's time for a little fear.  I do appreciate it so I can stop, assess, discard.  Next.

     

     

     

     

     

  28. Throw out your dead[ Go to top ]

     

    Even while Microsoft’s superior marketing machine and well promoted alternative heaped it on, it never got traction.  

     

    Oh really?  

     

     

     

  29. I've read these posts and the TSS blogs. Many posts seem to be from coalface developers. It's disappointing to see such naked aggression but when you confront the status quo and the livelihood of many that is the predictable outcome.

    I don't have a problem with registering At Forrester. Storm in a tea cup... 

    Personally I'm a bit of a veteran these days having started with COBOL in 1990 and then moving to UNISYS LINC and then onto Powerbuilder. Later I went onto Java and then into other fields removed from application development but still in technology.

    I remember the excitement of Java and the beginning of 'online' websites and applications. Little did we know how much could be done and what has been achieved with the toolsets so far and on mobile phones in particular is fantastic.

    Mike's pack in my view does NOT do that good a job of conveying his point but his core point is on the mark. I'd re-phrase it as - 'Java has enabled new types of applications to be written and underpinned profound growth in technology utilisation, but developer productivity and the cost profile of applications developed with it indicate that a replacement needs to be evolved'.

    To use an analogy 'Oil has enabled great advancements for man, with many positives, but when considered from a macro standpoint, we as the masters of the planet now acknowledge that alternatives to it need to be found, and evolved to be commercial such that we can stop using oil'.

    Some have made the point that Mike has not provided an alternative but I don't think he is duty bound to. The industry needs to first accept that the status quo is far from ideal and then let the capitalist system produce challengers that will be compelling alternatives.

    Prior research produced about 5 years after Java entered the mainstream has shown that Java applications cost more and take longer to develop. .NET is not that much better. As Mike points out there are many frameworks to use on top of the basic language and it is simply too hard to build UIs with it. Of course we do build business applications with it but its not ideal. The language itself is a problem but the bigger issue is that the developer tools built using Java do not hide the complexity and C++ programmatic nature of the language such that the tools deliver high levels of developer productivity and cost (which is better than the 4GLs).

    By now we as a industry should be onto 5GLs and 6GLs. Instead we went from 4GLs and then back to a 3GL (java). Toolsets for developing applications are not delivering the productivity of the old 4GLs like UNIFACE or INGRES or POWERBUILDER or SQLWINDOWS.

    In fact the java language resulted in a huge expansion in the types of enterprise enabling applications we use such as ESBs, BPMS, Portals, rules engines, document generation engines and so on. Many of these offer great leaps in productivty but they break down at the edges when Java or UIs are needed.

    Take for example just using Java. I have to put a semicolon at the end of every line. Its 2011 and that sort of rigidity still persists? I don't understand why.

    As for being non-proprietary, well nearly every mainstream business organisation is using vendor based solutions which are based on java and these ARE PROPRIETARY so where are we getting the benefits?

    We've not demanded as an industry that Java evolve to be a 5GL or 6GL or that software development vendors make it easier, cheaper and faster to develop with it. It needs to be a whole lot less complicated as complication means bottom line cost going up. Just have a look at how many framework, and JSR acronyms are out there. When 4GLs did abound a company dealt with one name - the 4GL that was it.

    In summary its time the market begin the journey to develop commercial 5GL app dev products. In my view large scale businesses would have no issue paying proprietary licence fees in exchange for a development platform that is cost-effective and very rapid to devdlop in. In fact by now there should be no technology programmers, the business should develop themselves using business friendly software. The two teams merged into a single functioning business. Today you cannot put Java in the hands of the business.

    Of course this evolution is not in the software vendors' interests. They may too much money from the downsides of Java.

    We achieved a great deal but java's usefulness will start to impair us going forward.

  30. 'Java has enabled new types of applications to be written and underpinned profound growth in technology utilisation, but developer productivity and the cost profile of applications developed with it indicate that a replacement needs to be evolved.'

    Um... my apologies, but I disagree. It doesn't NEED to be evolved. What's more, the desire for an evolution doesn't mean that Java is "dead." All it means is that people desire an evolution, as you seem to.

    And 5GL, 6GL... well, the 4GL was great, I guess, for the fifteen minutes that the meme had any power. I used MAPPER back in the day (well, actually, back in the 90's, but hey.) Now we'd shrug and say "Oh, look, a DSL" and move on. 

    Is it "time" for the 4GL? The 5GL? I think what you are asking for is an evolution of the programming language; that's happening, even in Java, even in the JVM. The general concept of the 4GL is a "programming by GUI" approach where people snap together preexisting functionality; we can do that now, without needing to do any of:

    • Abandon Java/C++/C#
    • Hyperbole about programming language death being equivalent to millions of lines of existing, working, maintained code, with more code being produced all the time

    In the end, Java isn't dead. It's consistent, I suppose, in some ways we'd prefer it not be, but perhaps that's changing. (We'll see if Oracle delivers Java 7 and Java 8.)

  31. 'Java has enabled new types of applications to be written and underpinned profound growth in technology utilisation, but developer productivity and the cost profile of applications developed with it indicate that a replacement needs to be evolved.'

    Um... my apologies, but I disagree. It doesn't NEED to be evolved. What's more, the desire for an evolution doesn't mean that Java is "dead." All it means is that people desire an evolution, as you seem to.

    And 5GL, 6GL... well, the 4GL was great, I guess, for the fifteen minutes that the meme had any power. I used MAPPER back in the day (well, actually, back in the 90's, but hey.) Now we'd shrug and say "Oh, look, a DSL" and move on. 

    Is it "time" for the 4GL? The 5GL? I think what you are asking for is an evolution of the programming language; that's happening, even in Java, even in the JVM. The general concept of the 4GL is a "programming by GUI" approach where people snap together preexisting functionality; we can do that now, without needing to do any of:

    • Abandon Java/C++/C#
    • Hyperbole about programming language death being equivalent to millions of lines of existing, working, maintained code, with more code being produced all the time

    In the end, Java isn't dead. It's consistent, I suppose, in some ways we'd prefer it not be, but perhaps that's changing. (We'll see if Oracle delivers Java 7 and Java 8.)

    From a business rules and bpm perspective, the goal of "visual programming" is over-hyped. Anyone that's actually in this space knows first hand what "visual programming" tends to produce. Even then, someone still needs to write stuff in Java/C#/C++ for these 5GL/6GL tools to execute. Just because we "can" draw a gigantic diagram of the business logic, it doesn't mean we should. If you want value from your bpm, brms, or cep software, you have to use it appropriately.

  32. 'Java has enabled new types of applications to be written and underpinned profound growth in technology utilisation, but developer productivity and the cost profile of applications developed with it indicate that a replacement needs to be evolved.'

    Um... my apologies, but I disagree. It doesn't NEED to be evolved. What's more, the desire for an evolution doesn't mean that Java is "dead." All it means is that people desire an evolution, as you seem to.

    And 5GL, 6GL... well, the 4GL was great, I guess, for the fifteen minutes that the meme had any power. I used MAPPER back in the day (well, actually, back in the 90's, but hey.) Now we'd shrug and say "Oh, look, a DSL" and move on. 

    Is it "time" for the 4GL? The 5GL? I think what you are asking for is an evolution of the programming language; that's happening, even in Java, even in the JVM. The general concept of the 4GL is a "programming by GUI" approach where people snap together preexisting functionality; we can do that now, without needing to do any of:

    • Abandon Java/C++/C#
    • Hyperbole about programming language death being equivalent to millions of lines of existing, working, maintained code, with more code being produced all the time

    In the end, Java isn't dead. It's consistent, I suppose, in some ways we'd prefer it not be, but perhaps that's changing. (We'll see if Oracle delivers Java 7 and Java 8.)

    From a business rules and bpm perspective, the goal of "visual programming" is over-hyped. Anyone that's actually in this space knows first hand what "visual programming" tends to produce. Even then, someone still needs to write stuff in Java/C#/C++ for these 5GL/6GL tools to execute. Just because we "can" draw a gigantic diagram of the business logic, it doesn't mean we should. If you want value from your bpm, brms, or cep software, you have to use it appropriately.

    I did design a "domain specific" tool for creating "rules" using Drools and Java when the "rules" ran.  While it did help in some areas and having done it all by hand before and after, the ROI just was not there to build and maintain the tool. Coming up with all the variations I would need and to represent them visually so someone could understand was a big pain if not next to impossible.  And in the end, someone who had programming (aka logic) skills still needed to do the "rules design" work even if it was visually.

  33. Some have made the point that Mike has not provided an alternative but I don't think he is duty bound to. The industry needs to first accept that the status quo is far from ideal and then let the capitalist system produce challengers that will be compelling alternatives.

    The status quo is never ideal.  One should always look towards better ways to do things.  Before calling the status quo a dead-end, however, one really must provide a viable alternative -- otherwise you're just saying either (a) the entire endeavor of enterprise application development is a dead-end or (b) there are viable alternatives but you have to pay us money for us to find them for you.  I strongly suspect Forrester is really trying to say (b) but has not actually managed to find any generally viable alternatives.  Sure there are technologies one might apply to UI generation, for instance, but what's ready to replace the overall technology stack?  Nothing.

    This is just someone trying to raise FUD about the road that's working for the industry so as to get the industry to pay them to look for other roads!

  34. While there is always a feeling that increasing the "expressive power" or level of abstraction of a language or tool will yield massive productivity gains, history has shown that this doesnt happen in  reality.

    The reason why the development community has largely settled on 3GLs is because a good 3GL provides a baseline on top of which is possible to relatively easily create pockets of higher level abstraction. Its MUCH harder to to the reverse: to bend a very highly abstracted language or representation around a low level nuance that occurs in most real world problems. Java isnt the best possible 3GL for every occasion but its good enough for most purposes.

    The other big advantage of text based 3GLs is we have evolved excellent  tools and practices to overcome the problems of managing lots of detail inherent in 3GL code: from refactoring IDEs to Test Driven Development.

     

  35. Invalid title of the presentation[ Go to top ]

    I think there is a big misunderstanding. Before the quiestion "Why?" the question "Really is?" must be answered. Mike somehow think the answer for "Really is?" is "yes, of course". But the discussion is mostly about arguing this question ;-)

    If Mike would like to bring arguments for paradigm shift "Use metalanguages and proprietary development solutions instead of Java", all we know he did a good job. The arguments are here. But that's all.

    I do not understand why the existence of "better productivity frameworks", such as hibernate, grails or struts makes Java the dead-end of for enterprise app dev. Instead, it grows its potential. It makes a necessity of the RAD tools smaller and smaller. 

    And about metalanguages. AFAIK ALL (or at least most) ones have some hooks how to incorporate Java :-D . And it's clear. BPM is about orchestration of some pieces of code. But you HAVE TO HAVE these ones!

    And about RADs. All of us know some ones. Most of us used some. All of us know that ech RAD works well in 90% cases of tasks it is designed for. The last 10% have to be written in some 3GL. And the best choice for the 10% is IMHO Java.

    And last, but not least: For each type of task you need a different RAD or metalanguage. Four different cases means for different tools. And the only glue binding them together is, such a big surprise,  Java :-D

  36. Expanded rediculous arguments...[ Go to top ]

    "A key developer angst is what combination of the many frameworks to use."

    Where I come from choice is a good thing. It means there’s lots of activity in the space and it means you have well, uhm, choice. If you’re too lazy to spend some time analyzing them to work out which one suits you or you are overwhelmed by new things (ie., changephobic) then you really shouldn’t be in the IT industry to begin with.

    "Swing is a nightmare to learn"

    Amen brother but refer back to the first point – you do have a lot of choice in the Java world unless you’re suffering from "herd mentality" and think you have to use Spring because you *think* everyone else is using it and think you have to use Hibernate because you *think* everyone else is using that. There are lightweight dependency injection frameworks (Spring’s original reason for existence) out there that you can master in an afternoon that don’t require XML or annotation hell and there are plenty of other object persistence solutions out there that don’t require you to deal with Hibernate’s not so transparent “transparent persistence”

    "Business rules, business process logic, presentation logic and layout is embedded in code or code-like constructs."

    Is he not aware of the many Java based BPM and rules based frameworks that allow declarative configuration of business processes and business rules?

    The misrepresentation of the truth in that PDF appears to be the result of someone who "doesn't know their stuff" or someone who is "deliberately misleading" for their own agenda.

    C# was going to kill Java - it hasn't

    PHP was going to kill Java - it hasn't

    Ruby on Rails was going to kill java - it hasn't

    People have been predicting the death of Java for years and this guy has joined a very long line of failed fortune tellers. I suggest he go back take another look into his crystal ball.

  37. Use www.bugmenot.com to get an existing user/pass so you won't get spam.. enjoy.

    This article does nothing but complain about the complexity of Java, JEE and its frameworks. It provides no solid solution or recommendation that would provide a technology that is simply better. Java is what it is and will evolve and technology evolves. 

    I'm not saying that Java is a "silver bullet" that will be a good fit for any project, but overall the technology solves and fits A LOT of problems. The author of this article is saying these things for attention. There are a lot of Java developers out there and there is a a lot of corporate money backing Java. Google, IBM, Oracle, Research In Motion and most of the larger tech companies use this technology and advance. Why in the hell would the author say that Java is no longer a viable option for enterprise unless your just trying to get someone's goat.

  38. platform agnostic[ Go to top ]

    in deed, java is not perfect, especially to code massively parallel systems...

    I remember language, i think it is called TAO, which runtime includes a loader to a bare hardware, whatever hardware which is able to compute.

    occam - gave a life to erlang (and still is not dead yet itself), Jini, in comparison, is kinda akward. The rest, like RoR (or whatever 4GL) - is a joke (I call them - "jail for a programmer" - the higher level of the framework - the more restrictions you have to deal with)....

    Having said this, the latest developments in parallel execution in Java (1.6- 1.7) are encouraging, however I still do not see how one can deploy even modern Java code on real multi-processor systems (think Thinking Machine) without "acrobatic" tricks and tweaks...

  39. Looks like we need a return to the CASE application generators pre java. At the moment I am working with a wonderful example CA Plex that utilises pattern inheritance at an abstract design level with declarative data models which provide the concrete implementation. This tool goes all the way as the patterns are incrementally made up of very granular componets and aggregated up to make very large business oriented pattern. As all the inheritance is at the design level it is completely technology agnostic and the generation is a matter of choice web, client, server, database. From the same design web or Java/C# clients, java/C#/RPG server and various Database options can be generated from the same design. The productivity of this too is more than 10 fold when compared to more traditional programming languages. The productivity is even more when in appluication change mode due to the model being a repository of all design information. Full version control with version inheritance of branches is just a part of the tool and natural.