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

Couldn't agree more on this one

I totally agree with you, coding business applications without the right tools and frameworks are just plain stupid. The presentation layer is a good example, just take a framework like Struts, it's widely used, but hardly provides any abstraction at all, it's just a bunch of handy tools and structures you can use when interacting with "raw" http and html. Great if you need that level of detailed control, but not effective when coding presentation layers for business applications.

But there are exellent Java frameworks out there, providing high level apis. I'd like to mention one of them, because it really illustrates how wrong you are when recommending against Java. My example is Vaadin, wich allows you to code nice and clean user interfaces. One of the major features of Vaadin is that you code 100% Java on the serverside. Behind the scenes ajax/gwt is heavily utilized, but you never need to know that. You just code plain Java, no xml, no css, no javascript, no browser detection, the entire web-layer is at a lower abstraction level and you don't need to bother at all (almost). That's the kind of tool a seasoned Java developer need to code a good, web-based presentation layer for a business application.

And again, the Java ecosystem is full of both predators and sitting ducks. Best-of-breed is a proven strategy (just ask Darwin), and in that perspective you clearly understand that you are bound to find both exellent frameworks and technologies, alongside others that just deserves to die. Using the latter in an argument against Java is just not valid.

Nothing new here ...

First of all I'd like to say that I don't totally disagree with the author, Java can't cure cancer, can't restore world peace (have we ever had that) and it is rightfully associated with the term legacy in many cicumstances. However, I think the article better describes the java-situation on Mars, not on Earth.

Now, let's look at some of the statements in the article, in the order they appear:

>>>The Internet forced developer productivity and 4GL’s to take the back seat

Internet is just another presentation layer in many ways, the emerging Internet was a great opportunity for the 4gl toolmakers to advance their platform further. Compuware for instance did this (maybe it was easy for them because their tool was implemented on top of java?)

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

Are you refering to java applets, hehe ... need I say more? Right place and time maybe, maybe not. Java totally screwed up the first time around. Servlets were spot-on, because they run directly on top of http and thus can't be avoided in a web-setting, but they were by no means a killer feature. Actually, when applets were introduced, nobody really knew what to use them for, they were mainly used to produce visual noise on webpages.

>>>Most other software vendors were caught off guard and Java became the de facto Internet development standard for enterprise Web application development.

Microsoft often are caught off guard, but their visual toolchain has always had a significant market share (even though it has been a pain up until .Net came along). However, java and microsoft have dominated, along with others as well.

>>>Java development is too complex for business application development.

Java is a verbose language and has lot's of complex interfaces. Java provides building blocks. For effectiveness you need frameworks and tools on top of that. For GUI look at ZKOSS, business processes and integration; Progress DXSI.

>>>A future platform shouldn't need a cacophony of frameworks just to do the basics.

You don't approve the best-of-breed-strategy? Well, when implementing a business system in Java you really need a pre-project to settle on a framework, not just for gui, but for persistence and pretty much any other application area... In a best-of-breed-scenario you will always find the most brilliant solutions alongside the worst imaginable. The problem is not really the available alternatives, but peoples inability to make the right choices.

And as a side-point; the monolithic one-size-fits-all-strategy is no better.

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

It even runs on cpus in terms of machine level instructions. Oh, my, let's run for cover ... :o)

>>>updated 4GL tools such as Compuware Uniface

Uniface runs on top of Java. Is this really the best way to develop enterprise business applications? (Yes I know it'll support .Net as well, but why care about the facts ...)

>>>and Progress OpenEdge

Oh, I really, really wonder what that one runs on top of ... did you even bother to check the facts here? OpenEdge runs on top of nearly any available platform, because it is based on Java. Which is based on C++. Which is based on machine instructions. So I'm afraid we'd have to dismiss it ...

>>>Application Development Teams Must Find A Better Way To Develop Apps

That's for sure, and Java is a great tool for that, as your Progress and Compuware examples clearly illustrates.

What you really try to say is that developers should use high level tools and frameworks, not that they should abaondon Java, and that's exactly what any analyst has always been saying. Nothing new here ... :o)

"need a pre-project to settle"

Jon, Thanks for your detailed comments. I did want to clarify that I did not recommend any products in the post. Rather, I mentioned products to show: 1) a focus on developer productivity in the late 80's and 90's and 2) a return to that now with some new development tools. I agree that Java developers "need a pre-project to settle on a framework(s)" etc... That is advice I give to Java shops all the time. But, I still implore enterprise application developers to find a better way. Instead of "pre-project" of Java frameworks, what about a "pre-architecture" of event processing, business rules, bpm, collaboration platforms, etc....

Nothing new here ...

"I did want to clarify that I did not recommend any products in the post. Rather, I mentioned products to show: 1) a focus on developer productivity in the late 80's and 90's and 2) a return to that now with some new development tools."

Well, actually you dismissed Java because it runs on top of C++, and instead pointed at products running on top of Java ... which clearly is ... biting yourself in the tail.

I don't care if you recommend the tools you used as examples or not. I surely do not recommend against them. I just point out that they run on top of Java, which I do not exactly get the impression that you recommend ...

If you really, really, really, want to avoid Java completely, you're very likely to end up with something that's running on top of C++ or even C, anyway, which for some reason I can't imagine is bad for your business.

When all contradictions and confusion is removed, you're only saying what analysts have always said; Use high level X-generation languages and tools.

Uniface runs on top of ...

"Uniface runs on top of Java. Is this really the best way to develop enterprise business applications? (Yes I know it'll support .Net as well, but why care about the facts ...)" As far as I have heard Uniface is based on C - remember Uniface is an older product than Java.

Hmmm...

The the cacophony of frameworks is choice. There is only one framework that I would not leave home without and that is Spring.

My experience with "more productive" platforms like Dynamics CRM left me cold - these are not platforms for serious software engineering.

Business application development should not be programming for dummies. Software is a corporate asset and if you are not capable of professional development practices instilling productivity and quality then, well... it is hard finding good developers these days.

I do not agree

A very biased and partly weak article. Just because there are too much inexperienced or poor developers out there you just can't reason that Java is too low level and complex. I agree that many projects are doing it wrong, but that doesn't mean you can't do it right. Swing is a nightmare? No! It's not that bad, if you do it right! Frameworks are too complex? Maybe some of them, but the art here is to choose the right ones and use them in the right way. 4th GL dissapeared because the CASE-Tools of the 90s failed to deliver!

Swing. JVM. Frameworks.

Swing: one of the better GUI frameworks ever made: it's not a nightmare at all. It can represent complex things, and is therefore complex. It doesn't *have* to be complex; re: SwingBuilder, Griffon, etc. LnF is a different issue, and has been addressed. And if you don't have the time to learn Swing, or want "real" native, SWT.

JVM: There is very little the JVM can't do well. A couple of them are being fixed (not sure when tail recursion will jump into the fray).

Framworks: you don't need a "cacophony of frameworks", you need the ones you need. Java-the-language *does* have an impoverished model of abstraction. You never *need* Spring+Struts, although you might *want* it. Why the rest? Because there *are* different ways of doing things, and some are more situationally-appropriate than others. I'd rather mix-and-match than make do with something I have to tweak.

Java may not be the "best" choice for writing software (it certainly isn't for me), but I don't see several of the reasons you provide as being the biggest issues.

Replacement for Java

I think that Python might be the way to go forward. It seems to me I use Microsoft at work because business uses Microsoft products for internal use so .NET specifically VB.NET (Same as C# get real) isn't going away soon.

As far as functional programs go I think they will become far more utilized but the paradigm is so foreign that it requires rethinking how you look at things. While I love the paradigm I think it is useful for only certain things.

Python is informal... on purpose.

Most of the linux distros today use python to glue their components together... and many python modules are simply wrappers to provide quick and dirty access to system functions where the apps aren't mission critical...

Python in science and academia - great for prototyping, one-off apps that only ever get used by the coder, or maybe a few others

Python in the OS - as i mentioned - a perl/shellscript substitute, for the same reason one would use perl or shell scripts, only easier for some apps

Python in a mature enterprise system - only for the disposable/bespoke aspects of a stable core that no asset developer in their right mind would never code in Python.

Python is not new in paradigm: it draws on fortran heritage in syntax - so that all python codes with the same expressions will be formatted the same - easy for reading... interpreted/compiled.... um, again with the fortran... object oriented - hmmm... methinks python is may be the youngest oo scripting language (perl could do it loooooong ago)...

It can't be compared to Java...

For the record: we teach python to scientists because of its simple syntax, and they can all relate to its principles because most of them know fortran... e.g. PyCUDA is the quickest way to get a non-programming scientist to speed up their algos with GPU technology. But I certainly wouldn't like to maintain a python system for a transaction gateway, clearing house, data warehouse, .... There is plone, but look how fiddly!!! If you're considering python, you should rather consider php, but certainly not for enterprise development... maybe for the ubiquitous 'presentation layer' of a _business_ _app_ that can leverage and _enterprise_ back-end... but if that app becomes successful, don't expect the python/php components to scale up in proportion to the _enterprise_ platform...

Java is not a dead-end

Is mr. Mike Gualtieri a

Is mr. Mike Gualtieri a programmer or just somebody that reads articles somewhere else and then spits an opinion after something he does not know? things like 'because is a language and there are already other languages', or 'because it was written in c++'.. like, what the heck was that? if a language does not exist, of course i have to write it in another language, even if is assembler, unless you really believe that to prove you are a top dog you actually write in hex, or with a magnetic needle changing magnetic nodes. App0s are written in java because it provides layer of services that are not available in, for example, c++. If you know the system you are writing for, and count with all required service layers, then go on, write in c++, is that what you were trying to say? if you dont, then you use Java or something that provides and abstraction layer so you dont care of details, versions and stuff of things that may slow down the process. Is like saying that counting with libraries, third party components and so on is not an advantage because 'the business is not static', or there are other languages (does the author even understand what he wrote?), or no hey, why not go back to assembler or fortran, after all c was written in those no?, lets make aside re usability and all that stuff that was developed during decades for a reason. does the author even know that the syntax of java is nearly the same as c++ but without pointers, and that c# was a copy of that? so basically anything that can be written in many other languages as imperative sentences can be written almost in any other language? or was he aware that the fact that java binaries can be distributed for different platforms? which means they do not require windows to run, neither to distribute source code? yea lets move on, those are not competitive advantages, and i am cool because i talk about cliche terms even if i dont know what they mean or what they imply..

End of Java

Let's face it, the Web was never intended, nor is it, an appropriate platform for enterprise application development. HTML, and the Web, recall are for hypertext linking. Of course, for organizations with an unknown customer base (any person, any where, any client), such as Amazon, the web server/browser architecture provides a solution nothing else could. I don't care who my client is, as long as it's a supported browser and the user has an id and password; I will authenticate.

But, for internal employees and know clients, why whould I ever develope a clunky, insecure, web solution? Instead, let's be adult and write up in ADA and serve with Citrix, or terminal services. I can do it faster, better once I pay the entrance fee, and even let the user use their browser shell so they have the web-wennie 'web based' requirement.

yeah, tell that to google,

yeah, tell that to google, m$, yahoo, or as you mention amazon, or any other company now days that is investing millions in 'cloud computing', because they don't think this is a part of the market that can give high enough utilities (even if for some of us cloud computing, not as a service but as a business, is just another name for hosting with another business model), or tell that to adobe which now releases not only Flash, but also flex and other tools including server platforms to develop and deploy web applications; have ever heard of php, pearl or web services? if so, why do you think those have grown, if they were a no end? and even if no web, there are still many other things that java can do for desktop, ever heard of java 3d or java looking glass? probably not, but you may have heard many times the names other companies release the same thing once they see this done and try to release a copycat product with another name. so you are saying, web is going back to 'geocities', just static text with no procedures behind them. once again, do not thrust 'opinions' of 'consultants' that never write a line of code besides of 'hello world'

Must be a DoD contractor

Because the web is ubiquitous and widely accessible and lower cost. You can have web-based solutions that are secure and use more stringent authentication. The majority of applications are not internal or real-time. I thought your condescending attitude (you're the adult and we're just kids) was in poor taste, since you get to define what adult is. I used ADA a quarter century ago and talk about clunky.

Don't be shocked some day when "Cloud-based Android" really does run on your airplanes and starships.

Java will become even more important

The future of computing is mobile computing and embedded systems and The Cloud. Android is rising up as the platform of choice for mobile development and it is based on Java. It is an excellent client for the Cloud. Desktop PCs are getting displaced by mobile devices.

Analysts are basing their predictions on an old paradigm that is going the way of the Dodo bird.

Welcome to the Post-PC era, folks.

Agree with most of this. For

Agree with most of this. For mobile there are currently the next development platforms: .net (windows mobile), symbian which is plain c with specific libraries (and most symbian devices support java anyway), iphone os (cocoa is also somehow based in java mixed with mac os), and android. If you want to develop once instead of assuming costs of rewriting code for different devices, you go with java; also if you want your code so it does not look so different from c# so the translation is not very expensive (or even automatic), you also go with java. The business of apple is not itunes, is the devices; and the 'magic' only lasts till the devices are different from what is already there, so unless mr. jobs can keep mesmerizing people releasing each year an iphone with different size, itunes, and ios as a development platform, can not survive, .net for anything that is not desktop windows or xbox, is already condemned -like showcasing as success cases where they had to pay for those to be developed in their tools- (and the only thing it makes it survive for windows is its beautiful ide, one of the few things m$ got right, even if sacking people from sun), and for xbox, kinect may look nice and everything but it looks like a rope around xbox's neck: when people wear off the novelty, they may want to go back to games where they dont have to move the arms to select options in a menu (or when web cam games for desktop become popular), or people who don't fit the requirements (like a living room large enough), or find it too buggy, may move again to ps and nintendo, instead, since is new and is the novelty and all the sum the spend in publicity, m$ is gonna push so every game gets released for kinect; most ocassional gamers will move to nintendo, all serious gamers will move back to sony.
nokia does not seem to have its feet on the ground with their platform (symbian? meego, maemo? which symbian, and what does the device support?), but they will still keep supporting java, so yeah, i guess java is where most mobile development is going, and this i agree with you

Analysts have lost the plot

I agree mostly with your points... but want to clarify...

Android is based on Linux, which is based on UNIX, which the JVM is based on (Sun originally modelled Oak on the Solaris OS, which is related to Sys V). Java is the _language_ that represents all this heritage.

The next best language/machine will be based on Java technology. Don't resist it, go with it; or one will have to redo the work of thousands of intelligent minds all on one's ownsome...

End of Java

Boeing is not developing cloud based Android softwarre for its 787 Dreamliner. I am talking about mission critical stuff, not cell phones.

Close to the metal

Mission critical in 4GL? (ha! ha!)

If a 3GL can't provide your mission critical requirements, move _down_ a layer - closer to the machine... this has nothing to do with how you model the solution, nor what language you use - Java can be used as a modelling language, and can _easily_ be compiled 'down'... and it has the benefit of an extremely high quality of abstraction so that you can _verify_ your solution in a mission critical sense... ever heard of formal methods?

critical point

Didn't this post originate on the topic of enterprise development? Mission critical enterprise solutions are complex and need a lot more than a 'cool' presentation layer...

Also, if you don't think mobile computers are viable platforms for mission critical enterprise development, then why are you still pestering the market with your ignorant opinions? Ever heard of digital cash? I mean, honestly, do you think there is a more secure technology than SIM cards? If so, then maybe you should become the CEO of HITACHI, or TOSHIBA, and realign the way they are thinking... then you wouldn't have to waste our time and effort in having to play these blog games.

I am only posting here because of the absolute absurdity of your original post; and the fact that after _thousands_ of protesting posts, you still don't want to admit that being in the industry for 20 years means that you could do yourself a favour and tune in to those who might not be bogged down by so much twaddle. I mean, I feel the need at least every three years...

Mobile phones are extremely 'critical' to business, or hadn't you noticed?

Um...

Isn't the "post-PC era" potentially just as hyperbolic as "the post-Java era"?

I believe so. In an article i

I believe so. In an article i believe i found in zdnet (as i say, i think, i don't remember for certain), somebody said that mobile market, including tablets and stuff, was a consumer market, and pc market was a producer market (a mobile only uses the apps and stuff already developed for that platform, and for all development, including game consoles, all development is done in a pc, so if there are no pcs there is no mobile market either). i agree and some comments seem to go that way also, that this post was written to get hits, more or less like a troll post, written specifically to create a discussion or a flaming war (in this case, probably to get hits, in the troll case, to get attention that the poster does not get at home or anywhere else, hey people reply my post, I am popular!). the backdrop is this is done at the cost of the 'consultant' credibility

Fluff

Not much of a crystal ball...

Predicting that Java is a dead-end is not much of a prediction. Anyone of us out there thinking that Java would be a choice technology forever? No. If you want a prediction that means anything, tell us when...a year from now, five, ten...predictions without timeline are either obvious or worthless. Take your pick.

language - model - machine

Please don't tell me the originator of this post, and his sycophants, can't see the relationships between a programming language, a solution model, and the machine that the language implies!!!

* Business requirements have changed.

The pace has increased due to the _success_ (hence, increased business expectations) of OPEN STANDARDS. The 'software crisis' of the 90's is not over, but _has_ been muchly mitigated due to the evolution of the operating system - the JVM being a utopic 'UNIX' - we have progressed from 'everything is a file' to 'everything is an object', but no more than that (APIs are _just_ APIs...). Splitting hairs about programming languages being more or less suited to business requirements is painfully narrow minded.

* Development authoring is limited to programming languages. ... You can invent as many new programming languages as you want, but they must all be implementable in the underlying platform.

DUH! Again, the relationship between language and machine... why the 'but'? What is the value of the 'but'? Please enlighten me on the platforms that the 'underlying platform' is unable to represent... please enlighten me on this (MONUMENTAL) breakthrough that has resulted in a severance of language from machine... if you tell it's 4GL, I'm going to to have to remind you that 4GL languages still need 3 meta-layers of abstraction below them, and that there is no need for anything more that TWO layers to 'bootstrap' upward as high as one wants...

If one _can_ implement any language on the JVM (which is an OPEN STANDARD), why not educate yourself a bit more an implement a 4GL language on it?

* Java bungled the presentation layer.

_Who_ is this 'Java' entity? For that matter, who hasn't bungled the presentation layer? I hate 'architects' who can come up with nothing than a few 'layers' of technology - no wonder your 'presentation layer' efforts have (obviously) failed to deliver...

* Java frameworks prove complexity.

(sigh...) Frameworks are not a Java thing... they are mechanisms that separate the operating system (or computing platform) from applications. They 'focus' the quality of abstraction of a technology for a specific set of responsibilities. Frameworks separate non-functional requirements from functional ones... if you don't know what a non-functional requirement is, I'd hate to be subjected to code of yours...

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

OMG...

* Java’s new boss is the same as the old boss.

The new boss obviously has a better sense of Java's value than the author of this post.

* Java has never been the only game in town.

BPM has NOTHING to do with programming language. I'm beginning to think the author of this topic (in all his years of hard-boiled pig-headed experience) never really got the memo - object-oriented methodologies ensure that you don't have to commit to any particular 'game'... maybe the author of this topic should re-engineer her business process of software development to include the things that actually matter - the whole _point_ is that Java does not have to be the only game in town - it doesn't need to be, and never wanted to be...

I've had enough... flame(-grill) me with napalm if you want, but it won't make you any wiser...
P.S. I have worked on projects that involve +1000 developers scattered accross the globe, and I promise you, you are in danger of reinventing the invention, never mind the wheel!!!

Yes, it is incoherent.

Luke,

Good job pointing out the incoherency in this article. I don't what to insult the man's understanding of Java and its relationship in the world of application development, but the points he makes seriously cause me to doubt that understanding. Especially the bit about dependency on the underlying platform. Perhaps he thinks the new stuff has a layer of magic which insulates it from having to be "implementable" on the underlying platform.

Glad you took the time to point out the nonsense. I hope there aren't CEO's out there making important decisions on the basis of this kind of opinion piece.

Java bungled the presentation layer

Luke, Ok. perhaps saying "Java bungled..." is syntactically confusing. I use it to represent all parties that have failed to provide easily expressable and rich user interfaces. Sure we can list out all the Web frameworks starting with custom MVC, then Struts, Spring MVC, JSF (and the various implementations), Wicket, GWT, etc, etc... For rich client applications Swing is a nightmare. I have been forced to develop Swing apps and the programming model is certainly rich but there is a steep learning curve for most. And, then there is JavaFX. So "Java bungled" means that Sun failed to provide leadership and the Java community failed to come up with a great alternative. To be fair it has been tough because ui technology has been changing very rapidly.

Politics is emotional, justice is political, so politics is not

Politics is emotional, justice is political, so politics is not rational...

With Gosling resigning (shortly after Oracle took over), and stating (eventually) that his reason was that the JCP is a nightmare, led me to realise that the Java community is _vast_ and diverse... huge. Bigger than any other technology out there. It outgrew Gosling, or at least, bogged him down with too much pressure to remain the visionary of something that had superseded anything he could have predicted... In my opinion, this is good, this is why he developed the language with the principles that he did...

It is correct that Sun, and Oracle, stay out of it - you can't hold them responsible, because that would undermine the open-ness, and integrity of the technology, thus clipping its wings. If they were responsible for leadership of Java, we would never feel a sense of ownership, something to invest our valuable ideas into... and you would never have had the opportunity to write this sensational article for forrester...

_We_ own the directions Java technology takes... we need to sort it out amongst ourselves... this is, in my opinion AMAZING... incredible... teething problems, yes, but I am not aware of any other such community... it is a phenomenon that _almost_ outshines the impact UNIX has had... (Linux, a few years ago, represented the largest online community ever... at least prior to FB, twitter, etc.)

So, again, don't judge, celebrate... bootstrap the technology up to the level that it can cope with the fluidity we require (we wouldn't be this high up the 'semantic stack' if it wasn't for the Java phenomenon...)

In computer science, we are always deliberating which language to focus on in our curriculum - some hard-core comp-sci folk swear by C... some swear that C++ is the most valuable to teach students... at our school, and others, we take the following approach:

One 'serious' language that gives the students insight into the most important aspects of a heavy-duty language. (e.g, java, because you can get them to appreciate the heritage contained therein - assembly, C, C++, and then Java as an extremely high _quality_ of abstraction built on these principles...)

One 'fluid' language that allows for rapid prototyping and experimentation. (python, object oriented, interpreted, integrated with most 'otherwise difficult to program' technologies...)

In parallel to this, we expose them to every single programming paradigm out there, but only as an awareness exercise... because we know they have the grounding, the appreciation to use any of these other languages when the need for them makes sense... but they don't forget the 'why', and more importantly, the 'how' it all came about...

Anyway, I guess the previous generation of computer scientists would promote C/C++ and Perl for the same reasons...

Anyway, my point is that given a large enough body of people who truly understand how things like Java came about, and what the culture behind it is worth, we as computer scientists feel that the 'higher' semantic layers have a brighter future as a result...

Rather than submit an abandonment, submit the idea of (and acknowledge) how we got this far in the first place... otherwise, we are bound to repeat the past due to an extreme sense of nostalgia... analyse, don't criticise... understand and appreciate the work that has been done, and the spirit in which it was done... if it is kosher, build upon it.

BPM, BPR, RPM, and more old-school, CMS, CRM, concepts have underlying technological histories.... it is important to make those acknowledgements. They are the macro-design patterns (IT theorums, and proofs, if you like...), they are the frameworks that guide our thought processes in ways that allow for fluidity, agility, etc.

Anyway, in my opinion, the successful development of any of these kind of acronyms with 'M's in them, are owed to the quality of abstraction OO allows. That is the cold, hard, truth... One has to use one of the mature OO languages as a reference to appreciate all this... to appreciate how we can build tools to cope with business needs...

The Java UI technologies are a storyline of _progress_, and, it seems to me, the most active arena of this 'presentation layer issue'... I foresee the end of the presentation layer as a human artifact due to all of this progress... UIs should be declared by their desired aspects... but, you cant do this without the underlying stabilty something like Java delivers (again, and again, and again)... when the list stops - when the JCP runs out of new approaches to presentation, and becomes stagnant, give me call and I will give you my re-evaluation with pleasure.

UI technology has been changing rapidly, yes, of course, but only Java technology seems to provide the foundation for such a constant change... all other trends I have seen in the previous ten years, have either leverarged off Java, or been isolated islands of narrowly scoped values (which makes them brittle, and limits their lifespans...)

Its a tough life being a trend-setter, but its worth it...

... if you can. And Java can/has been a trend-setter of monumental proportions. Microsoft couldn't even pull anything off other than a feature for feature match of the ever expanding J2EE platform with .NET. Their original VM (MS) was actually implemented with pointers (!), not references... they simply _had_ to catch up... like they have been for decades... NT, W2K, etc. all attempts at converging on POSIX compliance so that .NET could be realised... no?

Please admit that each of the UI frameworks you have debunked were, in their time, were paradigm shifts that lead those who could not lead... and allowed us, due to the incredibly high value of effort put into making the technology accessible (without cost), and thus bring us up to the higher levels to imagine even higher ones...

This is a brilliant aspect of Java technology - it has evolution built into it.

Aspect-oriented approaches, modern declarative languages, etc. all need stable, sound lower-level languages to pull off...

... if you are not careful, you're going to get a ShootYourselfInTheFootException.

From a developer

Read the article.

Java developer

Read the article.

I did...

... but still don't get the point.

However, maybe I _am_ being too aggressive here for my own good:

I would love to gain more insight into this issue because I am deeply invested in the enterprise market for the sake of those that learn from me...

suggestions?

From a Java Custodian

... for the record, I used Java professionally (as an architect on globally-deployed enterprise solutions) from 1996 to 2001, and then 'withdrew' to academia... the only 4GL, as far as I am concerned, is UML ;)

However, Java technology never was a 'must' for me, it simply made sense...

... and still does.

Eclipse/Netbeans to me, are the closest I have seen to 'side-stepping' the OS entirely... does this make me 'old-school'?

I have used UML (and ontologies recently) to 'program' not just software, but high-level AI heuristics... the prototypes were Java, but the final solutions were a mixture of appropriately applied technogies, with Java as the 'glue' between them... does this make me 'old-school'?

Still confused...

Having read the article at least a dozen times, I still don't see anything new, nor anything that can be pinned on Java technology, nor the reason why Java as been selected as the representative of the issues we have faced in adapting and evolving enterprise software assets...

A 'lean, mean, change machine' has been the Holy Grail of enterprise solutions ever since the term 'enterprise software' was coined...

Java is the glue that binds most decent tool-chains together...

Final thought: I am also not sure this is a Java issue in the sense that it is simply the most mature, pure, _object-oriented_ language - OO has the richest quality of abstraction, which means it can be used to model the most intricate functional (and non-functional) requirements... with OO languages being so generic (everything is an object), it can easily be argued that OO is not 'focused' enough to develop all components of an enterprise solution, which is why we have design patterns, frameworks, and methodologies... the IDE (my first love was Visual Age, then Eclipse...) is where the cost of development and evolution can be realised... given that a decent architectural core is in place...

Design - separating the things that change from the things that stay the same... _including_ functional requirements... three year plan... etc. etc.

So what is the breakthrough value of this article? (P)RPM? Why has this got to do with Java, or any other platform for that matter?

That's because the arguments

That's because the arguments are flawed. The conclusion is OK, obvious, but OK, the arguments are just there to draw attention, and it seems to work :o)

We're the suckers...

Your are so correct - imagine how much traffic (i.e. money) forrester have made from this single article...

I feel like such a small fish in their big pond right now, a real sucker for taking the article so seriously. ServerSide brought the link to my attention and I just dived straight in, like a pig into mud...

Once the search-engines get a hold of this blog (im sure they all have already), forrester get to climb up the priority ladder, and we _all_ got them there...

So who is big (popular) enough to host an article debasing (P)RPM and 4GL? Just to restore equillibrium...

productivity?

Give a try to Spring Roo, and then tell me what you think about developer productivity in Java, and ease of code change to accomodate to evolving requirements.

There are also very good MDA and MDD tools out there which, when used correctly, allow to develop at a lightning pace in Java (or any other "low-level" language) whilst keeping a much higher degree of control than using 4GLs.

4GLs are useful il about 10% of real-world cases. But as soon as requirements become complex, they are a nightmare to use.

Glad you also mention BPMs in your article. Most BPM systems out there are written.. yes... in Java :)

Yes!

Exactly!

Okay, I think I'm getting the hang of this topic...

The issues (enterprise developers need to find a better way, etc.), has far less to do with language than it has to do with 'method'.

Don't blame Java for enabling the most value contributions towards the original article's to date.

Don't judge, celebrate...

Yes!

Exactly!

Okay, I think I'm getting the hang of this topic...

The issues (enterprise developers need to find a better way, etc.), has far less to do with language than it has to do with 'method'.

Don't blame Java for enabling the most value contributions towards the original article's 'issues' to date.

Don't judge, celebrate...

3 year Application Development Strategy

So we learn a new language now and another one in 3 years and every three years. Obviously this man must be a real application development programmer. I mean like wow man, No Problem. We can learn a new language every 3 years, all of us, the whole world.

What is wrong with this picture???

I love it when these experienced software masters know so much more than us programmers about our jobs.

I wanna be an analyst too!!! So I don't have to learn and really, truly master 13 languages in my career lifetime.

Not about another silverbullet programming language

Bill, The future of business application development is not about yet another silverbullet programming language. There are more efficient ways to develop certain types of business applications.

Swing is a nightmare...

I've used many different GUI APIs and I can tell you from first hand experience Swing is NOT a nightmare.

No doubt a server developer who doesn't know the first thing about writing a Swing application told you Swing is a nightmare. I think you should take this to mean it's a nightmare for server devs who don't care about GUI and don't want to learn how to program one using Swing.

Swing is a nightmare

Stephen, Swing is has a very complete programming model. But, it is seriously a bear to learn for most mortal programmers. I have developed Swing applications and it is not as easy as it could be - mostly because it was designed like an elegant puzzle rather than a practical tool to develop rich user interfaces. Sure you can do anything with it. But, don't you agree that it is: 1) hard to learn 2) not very productive. When clients said they wanted it developed in Swing because it is "open" I dutifully told them it could be done faster in .NET. Another issue, early days it was so unstable. They fixed that now. And, what are your thoughts on JavaFX? Do you think Oracle can revive that?

Smalltalk is a development

Smalltalk is a development environment which is alive and well after years of being bashed for only producing bytecode and for requiring a virtual machine.

The Smalltalk news ranges from the Seaside web framework, the continuing success of mission critical corporate app's written in VisualWorks Smalltalk, the branching of Squeak Smalltalk as Pahra Smalltalk-with-Traits to royalty-free Smalltalk/X, Dolphin Smalltalk with Lesser, Smalltalk/MT and the return of instantiations.com to VisualAge Smalltalk.

And Smalltalk did not just give us Ruby - it has now given us Io at iolanguage.com

As a programmer I prefer Oz, Rebol, Curl (www.curl.com) and ObjectIcon as languages and would rather work in Prolog+logtalk than in most class hierarchies, but for corporate app's that can be maintained and that are very adaptable, it is hard to beat Smalltalk as it is the environment that gave us decelopment environments in the first place - not to mention the refactoring browser, UnitTesting, eXtreme programming, pair-programming ... and now with one simple addition, Seaside continuations; another simple addition, Pharo and Traits. And not running multi-core.

Or will it be the JVM which persists?

A series of failures needing an explanation is Struts; compare the changes that have come with VisualWorks Smalltalk 7.7 from CinCom ( although I still liked Dolphin Smalltalk from Obect Arts best of all.)

all the things you mention

all the things you mention (prolog for starters) are things people use when they have assignments while learning, same as functional languages, which inside turn everything into imperative statements. They are used to make exercises in academy, not in real world, smalltalk was something done to prove the oo concept, also it is not better than c++ or any other (but probably clearer, and in this note, if it was clear and fast and not interpreted, i would go with delphy/ oo pascal, but borland screwed in the ide, end note) and about '4g' or '4l' languages, lets not turn this into another cliché, java is supposed to be a 4g languaje, other things are just case tools, which may create pieces of code for many languajes including java, and that can spit the code for certain problems, if the problems are those already set as default (just like changing parameters in a function in any language, if the function exists already)

Smalltalk in Industry (USA)

VW Smalltalk is doing well at one major bank, in natural gas, in other financials - but perhaps only in the USA - and not widely advertised. Prolog is used in the real world as prologia.fr was purchased by Air Liquide and as can be seen at pdc.dk
Prolog with Logalk is not an academic exercise, nor is distributed Oz or Mercury. Constraint Resolution has given Prolog a role in several important projects - as is also the case with production sustems such as JBoss rules or 'Drools" and IBM J-Log (former ilog )
Even the ICON language has found an important realworld application in the USA.

4GLs are quick to market

an application build needs to be in line with business requirement and business change so it makes sense that using tools such as Uniface to alleviate the programmers working on mundane under the covers development. A lot of developers and teams forget the big picture of business needs and 4GLs helps the whole team get solutions to market faster than most. These applications have stood the test of time and if you have a look at the Petshop written in .Net and Pet store written in Java and compare it with Pet Plaza written in Uniface you will see that the number of lines of code to develop exactly the same application was less with .Net and substantially less with Uniface than Java. Uniface completed and tested the app 10 times faster than Java. The apps are exactly the same and look and feel the same.

I see a lot of people using 4GLs with a Java front end/ .Net front end. Uniface now embraces this by including Dojo into the development framework.

Developers need to keep their eye on the Business goal to see what will get the them there the best possible way and the quickest to market. Its better to have the edge on your competitors than be worrying if you are using the latest and greatest.

Some people use their tools correctly and get good results, but alas, there are a lot of people out there that are costing their companies plenty due to inaffective usage.

Companies use Uniface because they can sell the application to customers who have a variety of platforms and OS's. Uniface is indepenant of these and this makes life easier for the companies to maintain and get there product to market quicker.

4GLs such as Uniface "just do it" ( to borrow a catchphrase) with minimal fuss.

And if something doesn't work?

When your app falls smack bang into the paradigm of a 4GL, great... but how are you supposed to get an edge on the competition if you can't drop down a layer and innovate?

For the record, Java, as a pure OO language, can be used at meta, and hyper, semantic levels... and this was before Annotations...

I have seen projects where a few POJOs were reflectively 'parsed' to produce thousands of sound libraries on higher-level platforms...

Companies that use Uniface are limited in their ability to innovate, to move forward...

A Real Man's Language

If you want a programming language that will never go out of style ever, then learn assembly language programming. It will never be replaced by any young up and coming whippersnapper language currently in vogue. And if you have real b*lls then you will program in machine code.

But seriously, Alan Turing proved with his Turing Machine that any function that is computable by an algorithm is a computable function and this is equivalent to a class of languages called unrestricted grammars. All programming languages exhibit this quality and are thus equivalent.

The question is, why are we constantly replacing one language with its equivalent? There is no difference, from the computational perspective, between languages. To say that a language is dead is to fall prey to the notion that the fashion industry perpetuates on us, namely that we must get rid of the old and make way for the new. So let's trade in our old jalopies for the new Ferrari model and replace our wives with a sleek younger hottie. Yes indeed! I'm all for change for change's sake!

I hear you

Mike, I started my career writing operating systems in 8080/Z80 assembly language. So I am with you on that. Talk about a simple language. Since you only had a few registers and operations there wasn't too much to learn. I used my hexidecimal calclulator a lot.

One clarification, there is a difference between "dead" and "dead-end". In my post I said that Java will live like COBOL (and assembler still lives today. I just spoke with someone yesterday who is doing fluid modeling in the cloud running Fortran). Dead-end means you will hit a wall and you should look for something new.