Java Is A Dead-End For Enterprise App Development

Before Java was invented, one of the key industry trends was to increase the productivity of both developers and end users. For example, fourth-generation programming languages (4GL) such as Powerbuilder, Progress, and Uniface provided professional developers with faster ways to develop business applications than using COBOL, Pascal, C, or C++. For end users, tools such as Dbase, Lotus Notes, and Visicalc provided them with the unprecedented ability to create mini-apps without the need for professional developers. In the early '90s, this productivity trend was thrown into a tizzy by the Internet. Now, software vendors and enterprise application developers had to rush to write a whole new generation of applications for the Web or risk becoming irrelevant. The Internet forced developer productivity and 4GL’s to take the back seat.

Java Was At The Right Place At The Right Time For Web Applications

Java was designed in 1990 as an easier and more portable option than C++ to develop embedded systems.  The invention of the WWW in 1993 started a meteoric change in IT application development. Sun Microsystems moved quickly to take advantage by selling “network” servers like hotcakes and offering Java as the platform for Web development. Most other software vendors were caught off guard and Java became the de facto Internet development standard for enterprise Web application development.

Fast-Forward 20 Years

Forrester data reveals that Java is still firmly planted in enterprise IT shops for custom-developed applications (see figure). But, data always tells us what happened in the past and does not predict the future. Application developers should also not make the mistake that adoption means goodness.

Java is not going away for business applications, just as COBOL is not going away. Java is still a great choice for app dev teams that have developed the architecture and expertise to develop and maintain business applications. It is also an excellent choice (along with C#) for software vendors to develop tools, utilities, and platforms such as BPM, CEP, IaaS, and elastic caching platforms (ECP). Software such as operating systems, databases, and console games  are still mostly developed in C++.

 Java Has Served Its Purpose, But Now It Is Time To Move Forward

Java development is too complex for business application development. Enterprise application development teams should plan their escape from Java because:

  • Business requirements have changed. The pace of change has increased.
  • 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.
  • Java bungled the presentation layer. Swing is a nightmare and JavaFX is a failure. JSF was designed for pre-Ajax user interfaces even though some implementations such as ICEfaces incorporate Ajax. There is a steady stream of new UI approaches reflecting Java's lack of leadership in the presentation layer.
  • 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.
  • Java is based on C++. Is this really the best way to develop enterprise business applications?
  • Java’s new boss is the same as the old boss. Oracle’s reign is unlikely to transform Java. Oracle’s recent Java announcements were a disappointment. They are focused on more features, more performance, and more partnerships with other vendors. So far, it appears that Oracle is continuing with Sun’s same failed Java policies.
  •  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.

What It Means: Application Development Teams Must Find A Better Way To Develop Apps

Many enterprise application development teams are already using a combination of tools and technologies to overcome the complexity and inflexibility of Java applications. BPM is used to quickly define and change business processes, and collaboration suites like SharePoint and Lotus are used to respond to the increasing demands of long-tail apps. Progress Software’s responsive process management (RPM) combines the best of BPM and business events to help businesses respond to real-time events and change business processes. This is just a small sampling of the next generation of business application development tools

Clear standard alternatives to Java and C# for custom-developed applications do not exist. There are issues with many of the alternatives. For example, BPM tools are great for defining and implementing processes but a poor choice for implementing compelling user experiences. The market for application dev tools is beginning to change though. The next generation of app dev tools will:

  • Dramatically increase developer productivity.
  • Allow developers to delegate change to business end users.

You Must Transform To A Lean, Mean Change Machine

Application development teams should create a three-year application development strategy and road map to include architecture, process, talent, tools, and technology. All options and trends should be put on the table and up for discussion. Development platforms are not the only items to consider. Cloud computing and mobile, to name a few, are other trends that must factor into your new strategy.

Learn how to apply customer-centric practices to develop killer mobile apps with our complimentary report: Design Mobile Apps From The Outside In.

Categories:

Comments

Capturing Business Intent

Ian, I could not agree with you more that finding easier ways to "capture business intent" is the goal. Thanks for the links to your articles.

in Japan, Wagby.

Enchanté(Kon-nichi-wa)

I read your blog with much concentration, and that wad interesting.
"4GL" which you mentioned, like Powerbuilder and others, is interesting too.

Recetly I am getting interesting in the product, WaveMaker. Because my company retails the similar developper tool like WaveMaker, it is called "Wagby" based java language, it automatically generates the application.
We are a software distributor of Wagby.

Thanky you very much.

Este artículo es poco

Este artículo es poco profesional y sinceramente nos deja una gran incertidumbre a la hora de que un profesional hable así de java.

Cuando hemos visto a un .net apollado por IBM, Oracle y otros.

Cuando hemos visto que facebook utilice .net he implemente MapReduce.

Sinceramente decepcionante este artículo.

I don't care about java or c#

I don't care about java or c# as none is adequate to satisfy the customers. I hadn't heard of the alternatives and therefore this post has merits.
Thank You

Qwerty is dead.

As a technologist, you may rightly assume that technical merit determines success. Have a look at a qwerty keyboard and tell me that it is the most popular english keyboard because of the way it was designed. Do you expect it to die out any time soon?

People have been predicting that Java is dead since 1.0 and they have been wrong as it is perhaps more popular than ever. Perhaps it is time to learn from history and move the discussion on.

Please read the post before commenting

Peter, If you read the entire post you will find that I didn't say that Java is dead. In fact, I used the data chart to show that it is in fact the goto language for enterprise java development. I do say that it has become a dead-end for new custom application development just as Cobol has. There are many, many Cobol apps still running mission-critical apps. So Cobol is not dead either. We must find a better way to develop enterprise business applications.

Not sure I agree that Java is

Not sure I agree that Java is the new Cobol either. Java has more general interest than any other general purpose programming language and the new interest in Android with help Java rather than hinder it. IMHO. There are plenty of green field projects starting in Java.

I would agree, that just because Java is popular doesn't make it the best choice for all applications. One should have a good understanding of what the alternatives are so the right tool for the job is used, rather than the "safe" option.

I'll bite

Yet another link-bait title. Having been to Devoxx last week, this article couldn't be more wrong. I'd like to know the demographics behind that graph. If it's only CIO's and upper management in IT firms, then the graph is seriously misleading. Most of those guys will probably choose Microsoft as it is the easy choice. But if they are the ones doing all the technical decision making (such as choosing a platform), then there's something seriously wrong with that company. Most architects I know take a more pragmatic approach in which Java still plays a more prominent role than Microsoft. But I do recognize a shift for Java going more and more towards the backend side of software development. It is a fact than Ruby (can you say, JRuby) is more productive for web development, but you won't see me writing a service layer in it. 4GL languages are the way forward? I don't think so. The evolution to higher generations has always been with the idea in mind that the higher the generation of the language, the less technical the 'developers' need to be. There is a case to be made for DSL's, but these are implemented in 3GL and serve a niche within a company.
IT software companies should base their platform decisions on the experience of their technologically proficient employees, not on graphs, polls or the latest article in Newsweek sponsored by software company X. That kind of thinking led to the adoption of MUMPS, and we all know the consequences. Developers should have the freedom to pick the right tools for the job, not hindered by opinions and polls but backed by technological facts. In my case, I'll pick Java any day of the week, with some Ruby on the side and perhaps a dessert of Scala or Groovy.

This is not a Java versus .NET post

Lieven, It appears as though you looked at the data chart and have not read the post. My point is that adoption or usage of technology is not the indicator of the way forward. Instead developers must think for themselves and find a better way to develop enterprise business applications. If Java is the way forward for you, then go for it.

10 Yrs Java Dev ? Really ?, BullShit

i doubt if you really have credible 10 yrs experience in java. You are talking like me, when i began learning java the wrong way.

So get your facts straight and stop talking nonsense to attract crowd to your blog.
Just like someone can write crappy java code, same can someone design a crappy software with your so called (not so heard of) 4GL languages.

This article is full of shit?

Yes Really.

Yes really

OK Mike, explain what a

OK Mike, explain what a dynamic proxy is then, how you would use it and why you would use it.

Anyone with 10years of java will have most definitely come across them

Dude - you are so off base with this

First rule of holes - stop digging. I'd bet a steak dinner Mike's made more money off his Java and App dev skills than you have. Why all the vitriol? This is just Mike's opinion based on his information. If you don't like it - ignore it.

If Java was far and away the best option out there everyone would be ignoring Mike as a crackpot. The fact that this post has generated so much vitriol seems to indicate that there's some kernel of truth to what he's saying.

What do you like about Java?

What don't you like about Java?

Oh boy...

Oh boy, where do I start with this nonsense.

Firstly, try hauling yourself out of the 80's (probably when you last developed any code), 4GL's are now dead, the latest incarnation of code development are called modelling tools. Care to take a look at eclipse modelling framework and the whole IBM rational toolchain built on top of it? They support UML, code roundtripping, visual design - and all based on top of open standards not some 4GL proprietary wet dream.

Secondly, requirements have also moved on since the 80's. There is a reason why frameworks like hibernate are big and complex, and that is because requirements are big and complex. No one spends all day knocking out simple CRUD code any more, which is all that 4GL's were good for.

Thirdly, java is not a language, it's a platform for all sorts of other higher productivity tools and languages. The list is endless if you can be bothered to do any resaerch: grails, spring roo, ruby, ruby on rails, groovy, scala, lift etc etc

A typical analyst puff piece that goes into misleading detail when making criticisms of existing products and tools, but then is rather vague when it comes to spelling out the alternatives.

At least you agree with me that Hibernate is big and complex

Jonathan,Hibernate is an object-relational (OR) framework and is evidence of the wide gaps in the Java *platform* that must constantly be filled and learned by developers. There are many, many framework alternatives for Java including Spring and Java standards such as JPA. Since Hibernate is an OR framework you must mean that data requirements are big and complex. I agree they often are as is integration and many other aspects of business application development. The proliferation of additional frameworks such as grails, RoR, etc.. are evidence that developers are trying to find a better way. I don't think the way forward is absolute at this point. I am asking you to think beyond the Java *platform*.

The impedance mismatch

The impedance mismatch (google it) is nothing unique to java, there is no language/platform that maps the object model to a relational model in a fully transparent manner. period.

Until then, java developers will continue using JPA and hibernate, and other languages will use their own ORM tools, and people like you will continue bleating about the complexity without offering any alternative.

NOSQL

So, just stick with what you know? Don't look at anything new and different such as NOSQL (google it)

what does NoSQL (a data

what does NoSQL (a data layer) have to do with Java?

NOSQL

Yes, I work with apache cassandra in my spare time and there is still an impedance mismatch between in-memory objects and the hash maps that NOSQL stores it's data in.

If there was some magic bullet, how would it know which objects need to be persisted and which are transient (only held in memory)? how do you optimise the retrieval/storage of these objects?

It's extremely easy to say that the existing tools have major gaps, until you look deeply enough at the problems and come to the realization that the gaps are there for a reason - physics - the physical differences between objects stored in main memory and tables/pages/hashes stored on disk/ssd.

Jonathan is right

I fully agree with Jonathan on all accounts. In addition, I think in the interest of full disclosure you should mention any business or financial relationships you or your employer have with the companies that you mention as alternatives (such as Progress Software Corp.). Honestly, I can't see any other reason why you would think that a 4GL is a viable alternative to any of the other mainstream solutions (Java, Ruby, C++, etc.).

I know the weaknesses of 4GLs quite clearly because I currently work full-time at a job where I code in a 4GL: Progress OpenEdge ABL. It is an absolute nightmare for someone who has a BS in Comp. Sci. I hesitate to even call it a programming language; it is absolute garbage. Basically, the idea of a 4GL is you have a bunch of global keywords (oriented towards top-down, procedural programs) that "magically" handle common tasks for the programmer. The programmer is stuck with this one, predefined method of handling the task. If they want a different way, they need to make a formal Feature Request, and wait for version n+1 to be created (assuming that their request is accepted). These types of languages are generally no longer around FOR A REASON! Nobody programs like this anymore because it leads to absolutely trash design. My guess as to why 4GLs appear to be growing is the same reason COBOL appears to be growing - companies that are stuck with the legacy language can't afford to migrate away from it, so have to invest more in expensive programmers and legacy software in order to continue developing in it. Of course, the antiquated languages breed poor design, which leads to increasing development costs... it's a sickening cycle.

I agree that Java (the language) is not a silver bullet. One has to be quite knowledgable about OO design as well as Java's multiple-inheritance-through-interfaces strategy in order to write good, clean Java code. However, I really do think that this is a Good Thing for the most part; clean code requires good design, and all artificial languages have their core design decisions that make them unique and powerful/weak in their own ways and require a little effort on the part of the developer to get started with.

I also think that any talented developer will just consider Java another tool in the toolbox, and will use other tools when appropriate. I vehemently disagree that any "Business Language" (I despise this phrase) exists, i.e. a language that enables someone with little programming knowledge (i.e. a "business user") to write clean code. This is how OpenEdge markets itself nowadays. Frankly, I think it is bullshit.

Just to prove my point, here is, in OpenEdge ABL, how you would find all customers that bought any blue items (assuming the item sku has "blue" in it), which is a very simple query:

DEFINE TEMP-TABLE ttCustomers NO-LOCK
FIELD iCustNo AS INTEGER
FIELD rowid AS ROWID
INDEX IXPK iCustNo IS PRIMARY UNIQUE.
FOR EACH item NO-LOCK
WHERE item.sku MATCHES "*BLUE*":
FIND FIRST order-line
WHERE order-line.item-no EQ item.item-no
NO-LOCK NO-ERROR.
IF AVAILABLE order-line THEN DO:
FIND FIRST order NO-LOCK OF order-line.
FIND FIRST customer NO-LOCK OF order.
IF NOT CAN-FIND(FIRST ttCustomer
WHERE ttCustomer.iCustNo EQ customer.cust-no) THEN DO:
CREATE ttCustomer.
ASSIGN ttCustomer.iCustNo = customer.cust-no
ttCustomer.rowid = ROWID(customer).
END.
END.
END.

Contrastingly, here is how I accomplish the same thing in Ruby, using the DataMapper ORM:

Customer.all(Customer.orders.order_lines.item.sku.like => "%BLUE%")

This isn't really a fair example because the OpenEdge example is weaker: I am only keeping track of a ROWID and customer number, whereas in Ruby I get an array of objects that contain a full copy of what is in the table as well as the table rowid (or pointer or whatever you want to call it). If I wanted to do the same in OpenEdge I would have to define every field in the table inside my temp-table definition, then tack on the ROWID field. UGLY!

So, can you explain to me again how a 4GL like OpenEdge is better? Is that Ruby one-liner too complex and unwieldy to use? How easy do you think it will be to maintain that OpenEdge code into the future? Does the OpenEdge stuff look flexible to you?

I also wrote an entire blog post about how terrible Progress / OpenEdge ABL is in detail:
http://www.abevoelker.com/blog/2010/08/21/progress-openedge-abl-language...
I hope you find it enlightening.

P.S.
The complaints you have about Hibernate and the other ORMs in particular are no longer valid. Java pretty much unified the ORM framework syntaxes into JPA 2.0 almost a full year ago. Hibernate is now an extension of JPA 2. If you write an ORM in Java nowadays using JPA 2 syntax, it is braindead simple to port it to another JPA 2 ORM framework.

I have been criticized for not recommending alternatives

Abe, Where in my post do I recommend alternatives? Some have been critical that I do not recommend an alternative. Anyway, the key point of the post is that Java is not the end all be all for enterprise app development. I do mentioned what I think Java is good for (in the post). It is time for Java developers to look beyond Java for enterprise business applications.

Quote: "Java has never been

Quote:
"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. "

I object to the recommendation of these 4GLs, particularly OpenEdge. Have you seen the "updates" to OpenEdge that you speak of? They basically try to do OO exactly how Java does it, albeit wrongly. They started with no garbage collection (later added it, which doesn't matter now if you have to support older non-GC versions), no abstract classes or methods, no interface inheritance... I could go on and on. It's just garbage.

How much did Microsoft pay

How much did Microsoft pay you for this article? I would like to be one of Microsoft's blogging army that receive $$$. Is the payment per-article or according to popularity? Would I receive more bucks if my article was more convincing than this one? Please let me know. I'm really so interested. Thanks.

C# is not the alternative.

Bill, Did you read this in my post "C# is not the alternative."?

yea right? your p

"...Bill, Did you read this in my post "C# is not the alternative."?"

why didn't you title your blog "Java and C# Are A Dead-End For Enterprise App Development"
i bet microsoft wont pay you then. if you look at response to your post at theserverside, u realize your loosing credibility men?
better stop writing shit like this.

Yep

Reading the posts I get the impression that most seem to be from developers who have spent many years building up skills in their chosen technologies and as such I can fully understand their reactions to your blog - but is the article aimed at developers, however experienced?

For years, many organisations have not made the decisions of which languages or tools they will use to develop their mission critical applications based on business reasons such as return on investment, the ability to change, or even the long-term maintainability of the resulting code. Instead the decision has been delegated to those which have already invested heavily, throughout their career, into particular technologies. When a development manager looks out of the window only to see a team of 100 developers whose job it is to maintain an application, however large and complex, the wrong choices have been made. It is not an application that has been build but a millstone - one your organisation must now carry.

I believe, like every tool, JAVA is not a panacea, it has its place but that place is not all encompassing. Organisations, if they wish to succeed in developing their applications, must take more care in the tools they choose. The right tools are the tools which give you the greatest benefit over the whole application life-cycle.

A dog is not just for Christmas!

Java - the revolt of working class against ruling class

Nice post

Mani, Nice post.

Use JVx for application development

It defines a standard way to develop business applications.
It is a full-stack app framework and defines a technology independent UI - Desktop or Web or RIA.
It uses the Single Sourcing principle (different UI technologies, no source changes).
It runs on Android.

Developers don't write same things again and again.
Developers are highly efficient.

Is open source and does not need fat configuration files - Keeps things simple.

good post.

good post.

Java is the most innovative platform out there

Interesting article because it reflects completely the opposite of what I think of Java. It looks like the author has no real connection with what is happening on the Java platform. If you would only consider what SpringSource/VMWare and Google are doing on the Java platform. The most innovation is happening right now on the Java platform in the form of Java, Scala, Groovy, Phyton, JRuby and so on. Complexity for Java frameworks do prove that software innovation is complex. The only point where I do agree on with the author is his concern about the bosses of Java.

Innovation in business apps is what is needed

Erik, I agree with you and am well aware of the innovation going on in the Java world. I am calling for developers to be innovative in the apps they develop for business. Java may be appropriate for some situations (as I stated in my post), but other app dev solutions can dramtically improve developer productivity for certain types of apps.

I am a thrilled beneficiary

I am a thrilled beneficiary of this discussion since i am in a predicament of which platform to take for my full time development if ever i have to confine myself to any platform for Enterprise development that is

Stop It

Please, stop with these silly titles for blog posts. i'm getting tired of this crap.
yes, we know java is not the best place for web application development. yes, i know java is cumbersome. yes, oracle ... yes, ibm ... i know, we all know, ...

if you really want to contribute to the discussion: write a paper about it and clearly explain everything instead of just repeating what almost everybody says/knows, in a couple of lines.

just stop using stupid titles to get attention. i wouldn't even write a post and title like this when i'm drunk

soory for the tone, but it's hard to keep my cool in cases like this.

Alternatives

Mike,

I think if we all sat down and thought about it, every one of us could come up with compelling arguments as to why a chosen platform is dead or at least pinpoint its weaknesses.

Having said that, all of it is mute unless a viable alternative or new solution is proposed to solve highlighted issue. In the absence of such proposals then I would suggest that this is all really subjective and pointless.

Damien

#1 The criticism of

#1 The criticism of complexity misses the point. Successful higher level languages built on top of Java do much more and dramatically extend the language. Take something like Grails and Groovy - they hide complexity, make web app development considerably easier and provide easy avenues for creating narrow domain-specific languages. However, maybe others might not find the solution-set offered by Groovy/Grails to their desires or needs - so other languages targeting different needs are built on top of the platform targeting different needs. Java constitutes the base platform that offers a rich set of diverse APIs for language development and that includes 4GL developers. The mistake is believing that a flexible enterprise language is the same thing as a much narrower-focused 4GL language. #2 The availability of frameworks doesn't prove complexity - rather the opposite - it acknowledges that developers serve different domains and needs and as a result multiple frameworks are rather a symptom of a healthy ecosystem that serves up different solutions for different commercial and open source needs. And yes there will be overlap - as it is a competitive ecosystem. #3 On Java extensibility the author is simply wrong. Java is flexible enough to offer extensions that extend the underlying language. For example - if you desire extensions - there is a Java Extensions Mechanisms and Java Native Interface (JNI) that are offered - they have been around for a long time and have been used in a number of settings. In point of fact, one can build a non-Java syntax language that is radically different from Java - Scheme (Lisp), Clojure, Scala and many others which serve to substantially extend the language well beyond not simply syntax but also language behavior are examples. It doesn't stop there we see even the area of rule-based expert systems (such as JESS, J.MD, etc) built on Java. In point of fact a lot of today's enterprise middleware today is built on Java for a reason - it is flexible and feature rich.

We need to refactor the way we develop business applications

Charles, I think we are in basic agreement. In the post I said "Java is still a great choice for app dev teams that have developed the architecture and expertise to develop and maintain business applications. It is also an excellent choice (along with C#) for software vendors to develop tools, utilities, and platforms such as BPM, CEP, IaaS, and ECP". We do differ on the analysis of what the proliferation of frameworks mean. You say it is evidence of a "healthy ecosystem". I say it is evidence of gaps and complexity. Most of us have had the experience where we tweaked and tweaked an application until finally we had to refactor or re-write it. That is the point I think we are at with Java for business application.

Java and Java-Based Tools have changed the landscape.

Yes, we do disagree on this point. Java is in a sense refactored periodically with new releases. Java EE 5/6 looks very different in it's feature-set from the J2EE when it was first released. That wide range of enterprise and business software uses Java as its development language leverages on the new features between releases. There is a reason why 4GL went into a steep decline after the release of Java. No language can do it all, but Java has consistently offered not only a fairly complete base platform from which considerable business software has and is being built - but it has offered substantial benefits to developers versus the more restrictive 4GLs. 4GL languages while useful - are useful in a very narrow sense. Additionally,

Finally, Java based tools have utterly and completely changed the picture - Eclipse, NetBeans, IDEAS and Oracle JDeveloper 'extensions' (plugins) and business-focused software are for example toolsets that provide a superset of those things offered up in 4GLs. They have not simply papered over the "gaps" - they have provided a deeper level of support for a huge range of domain needs. Will there be gaps and sometimes complexity in Java ? Absolutely. No language can do everything - so there will be gaps... but those gaps are easily filled in Java (much more easily filled than a narrow-based 4GL language). Is there complexity in Java. Again, yes. Enterprise software can be and is a complex undertaking. 4GLs exist to fill only some aspects of this complexity. The Java platform gaps and complexity can be easily filled with extensions, plugins and frameworks. The scope of Java is quite large, the scope of 4GLs are fairly restrictive.

Slightly Flawed Post

This post provides little background info into how you arrived at your conclusion. We do not see Java going anywhere in the foreseeable future, but that is only half the picture. You claim Java is not right for Enterprise Development. How do you define Enterprise? Your post seems heavily geared towards web development.

I work within the Telematics industry which includes technologies from Smart Transportation Systems, Remote Sensor Networks, Voice Applications, Mobile Devices, Smart Vehicles, Smart Grid Technology, etc. I work with some of the largest Enterprise Systems in place today. Java is heavily leveraged for middleware messaging systems.

What we do see changing is a general trend away from Web Clients and a move back towards a more rich user experience such as thick clients, mobile integration and the like. We see multiple platforms being leverage today to achieve these goals. Typically the back end technology is not as important as the architecture of the system. SOA Cloud based applications are fairly common place; although there is some serious confusion about when to use and when not to use Cloud computing...and why.

We very regularly see Java backends with .Net thick clients, mobile clients, custom embedded clients, etc. There is also a move away from traditional HMI to HTML5 based HMI in embedded systems both industrial and consumer.

I find it interesting the number of replies to this post that indicate the same. It is difficult to hear people say such broad encompassing statements when in reality they are speaking about something much more specific. It is information like this that can lead to flawed decision making at businesses, especially those that do not have strong technological leadership.

Java is evolving (Android is going nowhere soon I guarantee you); dot not has gotten progressively better; Apple has produced a compelling mobile platform; programming is in general is changing as we change how we do what we do. I do not believe posts such as this are as beneficial as posts that show how technology is evolving in a more constructive fashion. What was your goal in writing that Java is a dead-end? If not for lack of input, then there must have been some ulterior motive.

Enterprise App Dev is mostly challenged

Scott, You referenced the Standish report in your comment on my other post about software quality (Thanks for that comment too). Application development teams have been struggling for years to deliver better and faster. But according to Standish most #fail. Java has been evolving for years to overcome its shortcomings for enterprise app development. In my post I distiguish between enterprise business apps and "tools, utilities, and platforms such as BPM, CEP, IaaS, and ECP". My goal is for application developers to step back and assess where we are and where we need to be. My conclusion: Java is not the way forward for enterprise business applications. I see Java or C# as excellent choices for Telematics applications. However, even for those applications platforms such as complex event processing (CEP) have emerged to make it easier and faster to develop. My motivation: help application development professionals find a better way to be more competitive.

business apps

Wonderful motivation! Last 10 years, I developed business applications - with Java... Of course, I had a lot of problems to solve. The problem was that most frameworks solved problems but produced a lot of other problems and the result was that applications were not easily understandable because of the number of frameworks used and the LoC produced (big problems for maintenance).

Java has pros and cons and other languages, technologies have other pros and cons. I agree with you when you say, that there must be a Better Way To Develop Apps, but you have the same problem with all other technologies: We need "Tools" which allows us to develop faster/better/more efficient/....
The Java UI s are not perfect compared to .NET or e.g. QT, but it is OK for most business apps.

With Tools I do not mean better IDEs or IDE like app designers. There are enough of them in the world, but they do not solve daily business problems. And not all developers are top-class developers.

We need ready-to-use business application technologies.

We need ready-to-use business application technologies

René, Thanks for your comments and insights. I like your conclusion that "We need ready-to-use business application technologies."

Business apps are a different ball game

You should have entitled your article: "Java is a Dead-End for Business Apps"...

...and you should have promoted Java for providing a stable _enterprise_ platform for business apps that need a decent platform to ensure that they can be fluently developed...

'ready to use' means someone else has provided the spring-board for the readiness...

ready to use is about providing a variety of options so that a _business_ _APP_ developer can make a budget call on a project to project basis without worrying about the stability of the platform they are developing on...

There is a large scope of business app 'classes', the serious ones need to allow extended growth, this takes asset development expertise - way beyind the scope, or concern, of a shooting-from-the-hip app developer...

Leave the enterprise platforms to the asset developers... they certainly leave the business solutions to the app developers - two different, yet inter-dependent worlds...

Give the enterprise developers _valuable_ information, and your dreams might just come true.

Mike, I understand your

Mike, I understand your intent, however in my experience (20 years) I have found that the technology is seldom to blame for a poorly executed project. I am not sure how one can say Java is to blame for these failures. If Java (or anything else) was not the best choice or if framework X was not the right choice, then that is the problem.

I work with middle management and executives to help drive the business to become more value focused in everything they do, technology included. I have done many postmortems on projects that failed and in almost every case technology itself had little to do with problems encountered. I would suggest that the failures of any particular technology, programming language or project management methodology can be found at a different root cause. If you use the three-whys on failed Java projects rather than just looking at fail/success I think you would see there are typically deeper problems.

A company needs three key leadership concepts: vision, message and execution. Typically at least two of these are missing where projects have failed.

Java is not to blame; frameworks are not to blame; use of inappropriate technology (among others) is. Technology is like capitalism, if there is demand for a product it will survive, if not, it will die.

Frameworks will be 4GL aspect of Java

We've been developing web-based ERP software(which is best example of an enterprise application development) with Java EE and we are very happy to be in Java platform. Language features don't matter so much in enterprise development. The problematic aspect of enterprise development projects are generally requirement analysis, design and implementation process but not the technology or language. Primary advantage of Java is freedom. There are many options, you can also develop your own middleware and tools.

One valid point in article is development productivity and platform complexity but it depends on your technology(specification) selection and tool assets. We had to develop a new toolset(frameworks) to develop ERP appications to ease development. On the other hand, platform complexity shows maturity as well. Enterprise development teams are responsible to build a development stack for themselves by selecting frameworks or making it, that's the freedom with some cost.

Finally, world's top 2 ERP vendors(Oracle,SAP) support Java, that's the answer to show that it is not dead-end in enterprise development.

4GL are a dead-end

The problem is not Java, the problem is the development process. An agile development methodology and a good set of tools to help you along the process is as capable of keeping up with the change rythm as any 4GL.
4GLs are a dead end - they only provide a certain number of features, a certain way of doing things and a certain GUI Filosophy.
Having said that, I think the purpose of your article is purely commercial and are completely biased. That's why you fail to mention the biggest contenders in the 4GL markets - companies like Oracle, with products like Oracle APEX - or to mention the biggest mini-Apps builder tools: Microsoft Access, closely followed by Microsoft Excel.

When someone releases a bad movie we don't blame the camera

Joel, I agree with you that development process is part of the problem. I also think design is a big underappreciated part of the problem. Tools are only part of the picture. When someone releases a bad movie we don't blame the equipment, we usually blame the talent: screenwriter, directory, actors. So we are in agreement that process such as Agile can help. But it takes design, process, tools, and talent together to make a development effort successful. Also, I did not reccommend any products in this post. I used 4GL's as an example of the focus on developer productivity in the late 80's early 90's.

Hoisted on your own petard.

Blaming the camera is exactly what your whole article does.

Object-oriented-to-relational-DB-impedance-mismatch got you down? Blame java!

Accidental complexity in real world framework-hell ridden Java codebases got you down? Blame java!

Warren

Tools that take you farther

Tools that take you farther away from what's really happening, like Lightswitch, Wavemaker, etc. are not the future. Developers like the happy medium that languages like Java and C# give them between the "bare metal" and the glossy abstractions you mentioned. I do agree with you about Java's weak presentation layer, but it's not going away any time soon.

Fix the Java presentation layer

Allison, As I said in my post "[Java] is also an excellent choice (along with C#) for software vendors to develop tools, utilities, and platforms" because you need this type of control for that kind of software. But, for enterprise business applications I think more abstraction would free the development team to focus more on the business requirements and less on the plumbing. There has been a lack of leadership from the Java community and Sun on the presentation layer. JavaFX is a #fail. I think they could fix this by designing a new framework based upon HTML5 for the Web and mobile. Not sure about the fat client because Swing is difficult to learn.