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

Application lifespan

Reading this discussion i see over 20 java related tools and languages. As a business application developer i don't have time to learn all of them. I need to deliver functionality so my customer can make money. A 4GL enables me to do that.
That aside, what is the life expectancy of Java and .Net related tools and languages?
I am adding new functionality, and technology, to Uniface applications up to 20 years old. No problem. Would be happy to do the same to a 40 year old application.
I am also very sure that 15 years from now a lot of developers will be extremely unhappy maintaining legacy applications build with acombo of Java, J2EE, struts, ruby. Phyton and 12e other tools everybody has forgotten.
Who has answers or opions om lifespan issues of Java applications?

Meant to type: 40 year old

Meant to type: 40 year old COBOL application

Old Languages never die

I see that Fortran and Cobol are still kicking around. There's quite a demand for Cobol and RPG types. Lisp was invented in the 1950s and it is not in danger of being taken down anytime soon. An old 4GL like SQL should have been long gone, dead and buried by now but it's still out there doing business as usual. And look at C, by golly, it can't die like the monsters in horror movies. It even has progeny - C++, Java, C#, Objective-C. A rule-based language like Prolog isn't going away. Most of us have to learn several languages for our jobs.

The point here is that the issue of language X being dead is very moot and totally irrelevant to us programmers manning the front lines. Just another blog post to generate hits on the web that some people qre quick to criticize.

Who cares if Java is dead. Don't bother me with such trivial BS and let me go back to my job coding Java and a few other languages to help me make some money to pay the bills. Now that's the bottom line!

Requirement lifespan

I think it doesn't matter which lang/tech, if you have a model everyone can understand...

Having worked on one or two 'mature' software assets, I have seen systems evolve from C-style CGI, to C++ middleware (on DB2) serving Lotus Notes frontends, to wrapping the middleware with Java technology to serve both Notes solutions and web Applets, then Flash UIs, then EJB backends instead of the C++, then JSP presentation, then Facelets...

The point being that the introduction of each new tech/lang was a calculated budget call based on making money from the _asset_, not so much the technology... but more importantly, each component is chosen and then integrated without breaking the other components (impl'd in other tech/langs...).

Some folk see Java as an extension of previous things - C, C++, Smalltalk, etc. So I guess they expect it to evolve, and are okay with that because it has mechanisms to manage it's own evolution...

Having said all this, I want to emphasise that it all depends on the quality of the software design, and how the design is captured (in someone's head?) - so I have also seen projects that were easier to recode from scratch in , simply because the systems were badly designed in the first place, or the knowledged got lost somehow...

I wouldn't feel too bad about working on a legacy Java system ten years from now, provided we make no significant breakthroughs beyond object-oriented languages... and if the software has decent documentation (traceable model from analysis to design to implementation). But that goes for many other languages out there.

I do find it hard to imagine that Java systems will become 'foreign' to future programmers though, given that the syntax of the language has such a mature history... but I am excited at the concept of Java++, because Java has not let me down to date - it keeps up with trends, but if designed properly, allows for a 'graceful' migration from one trend to the next...

That the JVM can host a usable Java implementation of nearly every type of language to date is a significant aside.

I think systems are easy to 'revitalise' becuase of their heritage and whether that is exploited properly.

The way to kill language x

As an afterthought, I seem to remember one of the primary reasons for switching from one lang/tech to another is often the case of developer skill-sets. It might be too expensive to train someone in a language they don't know... (although committed developers learn new languages for breakfast, the language might be froma different paradigm, so building _decent_ code still takes a fair amount of experimentation, which is not cheap...)

So you kill a language by not learning it. Eventually legacy systems in that language will become too expensive to maintain. This is a theoretical point, because in the industry we tend to learn languages that we can make money from - if it is an exotic language that most young programmers don't care to learn, the experienced programmers will capitalise...

In scientific computing, for example, Fortran is heavily used in comparison to any other language. C/C++, Python, and Java are the other dominant langs, but pale in insignificance because most scientists aren't interested in anything other than their algos, which are typically simple (in structure) codes, with few dependencies on anything else.

The GPGPU arena has resulted in new fortran compilers, and some of the more successful FPGA platforms involve a LISP interpreter... so these languages have found their way into platforms that don't even look like Von Neumann machines...

Economic versus technical reasons for adoption

Luke, To add to your point about "we tend to learn languages that we can make money from": Application developers who look for jobs on dice or monster or whereever see what firms are looking for and that drives what people learn. And, what they know drives what they want to use. There was a wave of people learning ABAP because it made them valuable to SAP shops.

the content is garbage, Java

the content is garbage, Java is not going anywhere...it's always going forward

Fork in the road

Sure Java is going forward. But, there is a fork in the road. Take the path you must.

Hi Mikael, I think that you

Hi Mikael,

I think that you really don't know nothing about the Java "platform", as you clearly refers to it as a language.
You should learn more before write some crap like that.

Regards and luck (you will need a lot).

Java is a language and it is a platform

Carlos, People often confuse Java the language with Java the platform. I am talking about both in this post. With the proliferation of additional languages such as JRuby, Scala, etc.. on the Java platform I think people are beginning to understand what a platform means. There are many developers that think of Java as a language. They don't get all the other pieces such as the JVM, the container specifications and implementations etc..

I think that you are wrong

Hi,

An opinion is an opinion, but it doesn't mean that it is good.

"Java bungled the presentation layer"

It's possible, Swing is not a great help in developing, but it has never been it.
Today, you have the possibility to use GTK+ for JAVA, for example, to develop your desktop applications.
But, how much desktop applications are developed?
Everybody uses to develop web applications, and you can use JAVA at server side with any alternative for the client side (JSF, Google Web Toolkit...)

"Java frameworks prove complexity"

Oh my God... any framework is complex, because you have to give a lot of 'generic' funcionality for a lot of different applications.
You can use 4GL Tools, but you will still need that funcionality.
The advantage with JAVA is that you can choice the framework to use.

"Java is based on C++"
So... wich is the problem?... i don't understand you.

C++ is powerful, object oriented... JAVA is similar, but without the problems of of managing pointers.

I worked a lot of years with Powerbuilder, and it was good only for desktop applications with database.
But we had a lot of problems with Powerbuilder. The visual components were ugly and limited, if you wanted to make something more powerful, you have to do a hard work to get it.
It was not bad for Desktop Applications, but it was a poor tool.

JAVA lets you to make a lot of thing that you can not make with 4GL, it makes easy to develop concurrent applications, it has a great support, you can find a lot of things on internet that you can use and integrate in your project...

If using JAVA is complex is also because we want to make more complex systems.

Complexity is just a whole lot of simplicity...

...if you are using a language that can model it!!!

OO is different to all other languages in that one extends the language simply by adding more classes...

OO has minimised the distinction between language and API, problem space and solution space... this makes Java (the pure OO language), a non-trivial language to learn... but you will increase your market value (by being able to go anywhere your business vehicle requires), simply by cutting out all this noise, learning some design patterns, and familiarising yourself with a few frameworks, and component-based platforms...

Really, after that investment in your own education, the higher-level extensions (that the author seems to promote as 'alterntives'), will be trivial for you to pick up use effectively on a product to product, and project to project basis... I mean, really, when do we ever have the luxury to use the latest 'hammer' the analysts claim to be the next revolution on a real project? Things are way more messy than this 'spheres in a vacuum' simulacrum... these things have to be phased in, without causing excess cost... anyone know how to do this without technologies like Java?

How many previously-C-now-C++ backend systems survived the millenium? The only one I can think of, that actually yielded value, is the JVM...

Not Grounded in Reality

Wow.

I've only had two intereaction with Gartner and Forrester and both times, the experts were just dead wrong.

I'm a huge fan of non-JVM, non-Microsoft technologies. I'm also realize there are huge productivity gains to be had by not programming business apps in Java. However, I've experienced first hand the productivity gains using Grails and Groovy. Its the best of both worlds. Scalable foundations with a powerful framework and 4-GL like language that can be used by technical, non-professional programmers. It works - for real - already.

I lived through the "productivity" gains of Powerbuilder, Notes, MS-Access/VB. You build 80% of the app in 20% of the time and 80% finished the rest - if it ever gets finished at all.

There's a reason why Grails (and others like it) business is booming right now. I know of two Fortune 500 companies to replace those PB/Notes/VB apps with something else that is productive but also scales well, has management tools, etc... There's so much more to the story than developer productivity. The JVM as a platform has plenty of innovation happening on it for developer productivity - right now.

Grails - What is the sweet spot?

Scott, Thanks for your comments on Grails. In your experience what types of applications would you recommend using Grails? What applications would you use something else instead?

The Sweet Spot is Business Apps

I know, I know everything is business. Business versus Scientific, Image Processing, etc...

Grails is perfect for data pumping screens to databases with non-trivial business logic in the middle. I led a project that built an insurance rates calculation engine, with 25,000 SLOC in Groovy with about 300 or so in Java. The Java was added after we profiled the app. Because its so seamless to "drop down" into Java - Groovy classes are Java classes - adding some performance enhancements was trivial. It would have been a lot more work if I had used another language that then required me to use a C foreign function interface and write a C lib (which I have experience doing).

In Groovy/Grails, everything is an object, including numbers. You don't get the optimizations for number-crunching. However, *every* business app I've done in the last 25 years, even calc-heavy insurance rate calculations, needed BigDecimal so using primitives wasn't an option anyway.

Using Groovy as programming language is perfect for the business logic. You get BigDecimal math by default, operator overloading and the list/map syntax is super-simple. For the apps I've built, Groovy out of the box has worked as a psuedo-DSL. It is way more flexible that the rules engine I've seen. I've had two projects where technical, non-professional programmers write and/or modify Groovy code.

customers.each { customer ->
def monthlyInvoices = customer.invoices.findAll { invoice ->
firstOfMonth >= invoice.dateSold && invoice.dateSold <= endOfMonth
.....

Keep an eye on GWT

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

The pace will keep on speeding up. I don't see why Java is not comfortable with that? I mean comparing what is comparable. Java is not a L4G.

* Development authoring is limited to programming languages. (…)
Jython is worth mentionning too.
The traditionnal services provided by Java keep on growing. There is no inner limitation. Look at JDK7 and the new IO and network packages. It is still improving.

* Java bungled the presentation layer. Swing is a nightmare and JavaFX is a failure. (…)

What's the problem with Swing? Don't like MVC ? Swing is great and fast for desktop GUI dev but one has to invest some time at the begining.
JavaFX is a failure I agree. But GWT evolution along HTML5 will likely provide a good remplacement.
Java Ajax future looks like GWT. GWT kicks out JSP, JSF, Springs and the likes. GWT make Web GUI developpement as easy as Swing dev. See SmartGWT and the others.

* Java frameworks prove complexity.

What's the issue with Hibernate ? Using it with @annotations brings simplicity for persistance.
DB4O is a so simple to use too.

* Java is based on C++.
What's the point? It's good to rely on past experience. Java is much easier to maintain than C++.

* Java’s new boss is the same as the old boss. Oracle’s reign is unlikely to transform Java.

I agree : Oracle is probably bad news for Java future.

* Java has never been the only game in town.

What's the point to compare a L4G to Java ? A L4G could rely on Java. There are L4G based on JavaBeans, some of them being very visual, that can compete with L4G. But one cannot compare a brick to a wall.

App Development professional

App Development professional

What about JDEVELOPER????

Hey guys -- what about the latest version of JDEVELOPER from Oracle??

Has anybody used or seen version 11 of JDeveloper?

It is very high level and generates Java code and can import Java code into its model. You can develop entire applications -- from Database interface to browser interface with almost no coding. Basically, you can do in 30 minutes what takes a week to do in straight Java.

Anybody? Anybody used or seen this????

Dennis M

I believe you

I have looked at the feature profile of JDeveloper, and agree...

But, the faith Java technology has instilled in me time and time again (Visual Age, Eclipse, Netbeans, JSDK tools, etc.), makes me feel that OF COURSE Java-based IDEs lead the market in the most valuable tools for almost any aspect of enterprise development out there... in fact 'enterprise' is simple stuff for Java technology... what about grid, cloud, and webservices (with round-trip engineering)? Java is the only technology that has taken these concepts in its (usual) stride... no?

So I re-iterate your desperate call for sanity: Anybody? Anybody out there? To quote WIll Farrell in Zoolander - "... or am I taking crazy pills?!?"

The sheer velocity (which is also the name of a fantastic Java technology that is the predecessor of Java Annotations...), of Java-based IDE evolution and the value they bring is astounding...

Eclipse, Netbeans... for those of us that like flexibility, but can gain control beneath the wiring board if we need to innovate, can't be criticised by anyone who has ever taken the time to appreciate their value... both IDEs have been laundered by the FOSS community too... and adopted with open arms...

If you want to be a 'script-kiddie' and knock out the latest 'no-brainer' boilerplate I 4GL _framework_ has to offer, be my guest, but don't expect to be in a position to troubleshoot and fix anything unforseen that happens... 4GLs also make it excruciatingly difficult to integrate with other platforms, as we often need in this _real_ world of enterprise development... and, about that 3-year plan point... stick to the mature technologies, not the trendy layers built on top of them... I mean make your budget calls, but be aware of the tradeoffs...

Enterprises don't lead or prosper by using the same boilerplate solutions as everyone else... they innovate, and need to invest in mature technologies to guarantee that their solutions become assets....

Declaring the aspects of the app you desire (rather than coding them) is a powerfull experience, but only if the 4GL is sematically matched to your problem... 4GLs are meta-models... easy ways to manage frameworks... but only within restricted solution spaces... 4GLs are brittle by the virtue of the fact that they are so 'high-level'...

Asset developers, not bespoke developers, understand this... they know that 4GL components are disposable, and so they develop their architectures to keep the 4GL aspects of a system the h*&^ away from the core system... otherwise they just end up developing liabilities...

Use an IDE that can 'bring everything back' to a stable platform, now that's what I call added-value...

Oracle 8i

Anyone remember Oracle 8i?

The first end-to-end development environment for high-level enterprise development...

... I'm not even going to point out which technology they adopted to pull this off... and now look where they are!

Some of us feel Oracle is bad for Java - don't believe what the analysts say unless you have tried it out for yourselves...

Oracle have been adding value to their technology via Java since the late 90's ... otherwise they sould have lost out due to IBM's DB2, etc... (who also java-fied to compete...)

UNIX was the OS of the original internet... Java is the current one... and I don't mean applets, JFX, etc... I mean grids, clouds, and other scalable platforms... there are very few semantic-web technologies that aren't enabled by Java and its ability to liberate the _app_ developer to use pretty much whatever they want... it is Java that enables this!

Love your use of the Will Farrell Zoolander quote

Luke, I agree with you that "enterprises don't lead or prosper by using the same boilerplate solutions as everyone else". Guess what? Most enterprises are using Jave or .NET to develop custom apps. We have to move forward to develop applications faster, change them faster, and make it easier to differentiate them.

Also, strongly disagree about the value of IDE. Sure if you are developing code they are essential. I actually prefer NetBeans over Eclipse. But, seriously an IDE is a super fancy text editor and debugger. Microsoft Visual Studio beats them all in terms of IDEs.

vi or emacs?

Mike, yes IDE's are fancy editors, and, personally I use vi most of the time ;) However, Eclipse products like the Rational Rose suite, or a more low-level technology like EMF/MOF... now that's powerful stuff - you can build software without writing much code at all... Netbeans _is_ great - GUI building, full enterprise development tool-chain of many non_java languages ;) Great profiling tools... and both IDE's can host projects that use many different languages - I recently had to configure Netbeans (6.9) for C, C++, Java, CUDA, and code-generators to create the JNA bindings that JCuda hadn't already... another example - we built an Eclipse plugin that generates Java apps (or applets), GUI included, from FSP (Finite State Processes) models, which is a formal method for concurrent mission-critical apps...

But seriously, IDE's provide a level where the developer can focus on meta-information (thus, avoiding ploughing through thousands of lines of code), and rapidly add higher-level development tools as the complexity of the projects increase...

Visual Studio rocks too... just not as... er... open.

The trick is to choose a tool that matches your methodology, and to be able to modify it if the method changes...

A question: these new tools that we should 'look for' in order to speed up business development - surely they will be better off if produced as plugins to exisisting IDE's? Heck, emacs, if you like... It's just that I feel there has been so much valuable work put in by IBM, Microsoft, Sun, and now Oracle - and tthey all seem to be adding this kind of value. In the UK, as an architect, I used to keep an eye out for projects that had similar development challenges (of the type you highlight in your article), and then flag potential assets our propellor-heads could build - e.g. business rule engines, UI generators, new refactoring patterns, etc.

One of the features that impressed me on Eclipse recently - you can perform a series of complex refactorings (to, say, port an app to a different project), and have them recorded as a templatised macro... wow...

However, if something went wrong, or something unexpected happened, we could always drop down to the lower levels and troubleshoot...

Anyway, what form would these new ways of development take, do you think?

JDeveloper IS going to take over the world!

Yes, you are correct....... JDeveloper version 11g (and 12 to come) is going to take over the business application market over the next 2 years. 15 of our 35 clients are currently moving to it.

Mind you, JDeveloper is NOT just an IDE. It is a comprehensive ADF (Application Developement Framework). If you are trying to compete against it with any other current tool, (Ruby Rails included), you will be blown out of the water in short order.

I suggest all of you take a few hours and take a look at it -- all on Oracle website. Download it - it is even free! (Not sure Oracle should be giving this away - it makes people think it has low value.)

(The only drawback is you need to buy the runtime framework from Oracle, but this is peanuts compared to development costs in general.)

Dave T.
Seattle

4GLs for Java

Java is a third-generation language. Its 'advance' was its ability to exploit the so-called 'OO' model, which is actually a failed model. OO's goal was to allow software engineers and systems product designers to 'model the world as objects'.

But this is not what OO languages actually do. They instead attempt to model the world as a system of passive, static class hierarchies. Static because their templates (class structures) cannot be modified at run-time. Yet run-time modification is the fundamental essential requirement of dynamic systems. As for hierarchies, this is a very poor way of modeling most of the real world.

Objects in the real world are predominantly concrete instances that can and must dynamically communicate (interact) with other objects based on the physical-chemical interfaces shared by these objects. The relationships between objects in the real world is not hierarchical and top-down but peer-to-peer. Furthermore, real-world objects cannot be modeled as passive machines driven by a central 'god-like' event-driven control process and instantiation factories . Instead, each natural object has its own active agenda which controls what it will do and can do from the moment of its birth (instantiation and replication) to its death (deallocation).

As for object type (classes if you will), these must be allowed to be composed through the real-time discovery of common properties form similar instances, thus allowing classes to be bottom-up and dynamically created and managed. That is, after all, how we actually form our concepts of the world. A powerful modeling tool must work with, not against the natural human process of concept and idea formation. This will yield a powerful tool for both thinking about and developing software/hardware systems that can more naturally interact with the real world (their ultimate interface) on the one hand, and the human mind (their creators) on the other.

Thus Java and all class-based OO languages fail in every fundamental way to model the world of real, active, self-managed, self-generated objects (from complex molecules, to cosmic clusters, to life itself, not to mention the need to model the emergent properties of vast collections (systems) of such objects, including the emergent properties of human action, such as economics, and market phonomena).

Ironically, some older languages modeled the active world far better, allowing us to design and manage a world of active, dynamic, self-managed entities. Look for example at the capabilities of Ada, especially its task types as active self-managing entities, with built-in state-transition and structured agenda (using rendezvous and queued entry points). Another example is Argus, a language for designing systems based on confederations of communicating processes. Look at Hoare's work on CSP (communicating sequential processes) and its later advancements into the world of communicating processes each with its own agenda and interaction rules. There is also Simula and Smalltalk, both noted for their dynamism as important properties of the worlds they model.

But, most sorrowful is Java's arrogance in demanding that not only programing languages but databases must model the world as passive, static class hierarchies. This, in spite of the revolutionary advances heralded by the emergence of relational algebra and its offspring relational databases. The flexibility, natural simplicity, and adapability of RDBMS launched the business world into a major new level of productivity. Yet Java is inherently anti-relational, as a language it has no relational operators or modeling concepts, features or capabilities. Instead, an ugly compromise that twists object hierarchies into relational tuples (and vice-versa by hiding the ugliness from the developer), has emerged in the form of technologies such as hibernate.

I agree: A new generation of languages must emerge that overcome the limitations of OO. Some such work is underway at such prestigious institutions as CMI, with its work on aspect-oriented programming. But a stronger marriage is needed between the next generation language and relational algebra as well as asynchronous communicating processes, executing and communicating across multiple machines in multiple domains. In this regard, the emergence of the Enterprise Service Bus architecture is exceedingly important and cries out for a language that embraces ESB as a built-in language abstraction. I can hardly wait!

OO

Umm... you can insist that the only value OO brings to the table is class hierarchies... without multiple inheritance at that... but methinks this is the "Learn OO in 24hrs" crash-course view...

Firstly: Objects can be used to dynamically compose constructs that were unforseen by the programmer... subclassing is a strong relationship that should only be used when needed - to write general code that possibly has to deal with unforseen, but scoped, adaptations in the future... subclassing is _how_ _we_ _think_ most of the time.

Secondly: OO is not meant to model only business logic (real world concepts), it is also meant to model algorithms as they are (and not how the machine executes them). OO is also used to model non-realworld concepts, in a natural way for humans, yet executable by machines. Objects are also instances of micro-machines...

Thirdly: byte-code compilers can be used to create classes on-the-fly that never existed before runtime (perl can even do this!). In Java's case, there can be objects, of byte-code-constructed classes of which there never was any source code.

Fourthly: OO goes so deep, in modelling philosophy, that it can _mathematically_ be proven to allow for any paradigm of programming you desire, and verify the implementation in comparison to the original model. The interesting thing is that OO can be adapted to any mathematical model, not just predicate calculus (though it can be used), or other formal methods and related calculi or algebras... the point is the scope of models that can drive a OO model is the broadest...

OO is human friendly. We often use OO to build conceptual models that create a channel of communication with the client, and then transform those models into whatever implementation approach which makes sense for that case.

You mention Hoare's CSP (1985). There is also Milner's CSS (1989) - but have you ever heard of Magee & Kramer's FSP? Besides the point... all of these calculi, algebras, etc. can be used whether one is using them to model OO or not... really...

There are so many design patterns out there that tackle problems we all have faced, and there are patterns that tackle problems most of us would love to have the opportunity to have to face...

Finally, aspect oriented languages see the world as a bunch of declarative aspects (narrow solution space), but since when can Java not be used for AOP?

Incidentally, concurrency is out, _parallelism_ is in - CSP won't cut it... concurrent state-machines aren't useful in a multicore, multi-computer, or dataflow context... petri-nets on the other hand... and, well when it comes to a relational algebra for distributed software in the spirit of ESB... hmmm... not quite sure which aspect of ESB you see it solving that previous mathematical models can't solve...

massively parallel - group-sequencial, loosely-coupled message passing, tightly-coupled message passing, generally-concurrent, and dataflow - have all had sound mathematical models since the mid 80s... e.g. Danny Hillis' Connection Machine ring a faint thud? Heck, even Collosus could perform hundreds of parallel logical operations at a time...

Concurrent is dead, process synchronisation (locks, semphores, etc. ) are dead. Interprocess communication is, therefore dead. Message passing models, however, aren't, whether through a bus, a queue, or an interface.

None of the above is outside the scope of OO technologies, so you must either be onto something so radically earth-shocking that Babbage would rise from the grave, never mind roll in it, or you are a bit lost in the sea of IT neuro-linguistic programming...

P.S. If you have issues with OO, take it up with Booch, Grady, and Rambaugh...

OO

Umm... you can insist that the only value Java OO brings to the table is class hierarchies... without multiple inheritance at that... but methinks this is the "Learn OO in 24hrs" crash-course view...

OO is human friendly. We often use OO to build conceptual models that create a channel of communication with the client, and then transform those models into whatever implementation approach which makes sense for that case.

Objects can be used to dynamically compose constructs that were unforseen by the programmer... subclassing is a strong relationship that should only be used when needed - to write general code that possibly has to deal with unforseen, but scoped, adaptations in the future... subclassing is _how_ _we_ _think_ most of the time. The broad strokes... but objects and be composed to provide exactly the same outcome without class hierarchies...

OO is not meant to model only business logic (real world concepts), it is also meant to model algorithms as they are (and not how the machine executes them). OO is also used to model non-realworld technical concepts, in a natural way for humans, yet executable by machines. Objects are also instances of micro-machines...

Java byte-code compilers can be used to create classes on-the-fly that never existed before runtime (perl can even do this!). In Java's case, there can be objects, of classes constructed at a byte-code level _in-memory_ for which there obviously never was any source code...

Another note is that with Java byte-code you can drop down to an assembly level is you like (jasmin?), only you're gonna get an OO program in the end...

Classes allow for introspection, programs can use this in a most active and dynamic way...

Fourthly: OO concepts goes deep into modelling philosophy, that it can _mathematically_ be proven to allow for any paradigm of programming you desire, and verify the implementation in comparison to the original model. The interesting thing is that OO can be adapted to any mathematical model, not just predicate calculus (though it can be used), or other formal methods and related calculi or algebras... the point is the scope of models that can drive a OO model is the broadest...

You mention Hoare's CSP (1985). There is also Milner's CSS (1989) - but have you ever heard of Magee & Kramer's FSP? Besides the point... all of these calculi, algebras, etc. can be used whether one is using them to model OO or not... really...

There are so many design patterns out there that tackle problems we all have faced, and there are patterns that tackle problems most of us would love to have the opportunity to have to face...

Finally, aspect oriented languages see the world as a bunch of declarative aspects (narrow solution space), but since when can Java not be used for AOP?

Incidentally, concurrency is out, _parallelism_ is in - CSP won't cut it... concurrent state-machines aren't useful in a multicore, multi-computer, or dataflow context... petri-nets on the other hand... and, well when it comes to a relational algebra for distributed software in the spirit of ESB... hmmm... not quite sure which aspect of ESB you see it solving that previous mathematical models can't solve...

massively parallel - group-sequencial, loosely-coupled message passing, tightly-coupled message passing, generally-concurrent, and dataflow - have all had sound mathematical models since the mid 80s... e.g. Danny Hillis' Connection Machine ring a faint thud? Heck, even Collosus could perform hundreds of parallel logical operations at a time...

Concurrency is dead, process synchronisation (locks, semphores, etc. ) are dead. Interprocess communication is, therefore dead. Message passing models, however, aren't, whether through a bus, a queue, or an interface.

None of the above is outside the scope of OO technologies, so you must either be onto something so radically earth-shocking that Babbage would rise from the grave, never mind roll in it, or you are a bit lost in the sea of IT neuro-linguistic programming...

OO is the model, the program, and an algebra all rolled into one. You can even use Java classes as a model (not the program), and via introspection, generate whatever you like from them...

P.S. If you have issues with OO, take it up with Booch, Grady, and Rambaugh, et al.

the author of this post

the author of this post sounds just like the author of the article, it looks like he/she read an article about object oriented programming, and then jumped to opine and generate philosophical discerning about nothing, and spit opinions about something he/she does not even understand. for your records, object oriented has not failed, and the purpose of object oriented architecture is that if i am developing a module, i do not have to think if another module, made by someone else, has already declared a var with the name i plan to use, that in a 50000 lines project i don't have to remember what is connected with what or what names have i used already, it means i don't have to grasp the whole project on my mind and know what everyone else has done or not done, and that i can make a part of my project separate from the rest, and i can reuse libraries that have already developed, and not start each project from scratch, and by the way, every single imperative language out there used nowdays, makes use of the oo architecture. no it did not fail, and you are lame for just writing things either to write something without knowledge, or to get flaming because you don't get attention at home; and by the way, about changing classes dynamically? have you ever heard of 'soa' or service oriented architecture? part of the 'services' thing are services that monitor the current classes, same with event oriented programing and guess what is behind all this? yes, oo, and guess who is leading and who started the soa thing? what a surprise! it was java, and if you are not careful with soa, you may end up with a thing like spaghetti programming, and even with no soa, yes you can create classes dynamically, but that would be like using gotos.

i meant aspect oriented, not

i meant aspect oriented, not service oriented, and i see this was mentioned above, my mistake.

I disagree

Sorry, no hand could hide Sun ;-)

WaveMaker technology is based on java

We can see that on the wavemaker's website.

Java can and is the foundation for many new platforms

Ilyas, There are many development platforms that are based on a Java foundation. Just as Java rests on operating systems written in assembler, C, and other languages/platforms. As I say in my post: "[Java] is also an excellent choice (along with C#) for software vendors to develop tools, utilities, and platforms..." But, is Java the best way for enterprises to *develop* business solutions such as CRM, Order entry, eCommerce, accounting, ERP, MRP, etc...?

The important thing is that

The important thing is that the majority of Web tool development happened by HTML developers that got sucked into the vortices of web application development as servlets and other technologies developed. Many of these people appear to have never trained in computer science/software architecture basics and thus have no idea how to create inter-working frameworks. The presentation layer is crammed into the output stream of the servlet components and then also embedded into the web page as scripting based on browser idiosyncratic behavior.

The disconnect of all these systems and the pain of that development cycle has pushed a lot of developers into the mobile device market where they can write real software in an environment that was designed for what it does great.

Sun had no idea how to design desktop software. The fact that the applet environment and the Webstart environment exist separately is the best indication that they were fighting about it internally as well.

The web application concepts are just broken overall by the browser model anyway. All the stupid clicking between pages and and context switching makes web applications so painful.

Look at what has happened with iPhone and Android app development where applications have been rewritten to replace web applications and when you go to these web sites, they just show the "download the app" page.

People are screaming about how bad web app development is...

Platform designers and vendors are just not listening as they haven't for a decade...

hmm.. when solaris 11 came

hmm.. when solaris 11 came out, it had slogans like 'it can run everything that runs for linux, and if it does not run, we make it run for you', or 'military grade security'.. you know, the solaris os? the one you can download and use for free on a pc? or probably you are talking about desktop utilities, like open office? hmm.. or you are talking about games.. and this i agree, i wish sun (i also wish sun would still be sun, not oracle) made games. it is not about making desktip utilities, is about marketing; on that note, you may have noted that the last publicity for m$ office is not about the good things of office, but bashing openoffice, and frankly, their arguments seem kinda lame

Sun did not think the desktop important

When you look at all the work that Sun did on Java, they spent far more energy on the server side than they did on the desktop side.

In particular note that there was never an integration of the applet/Java-WS environment into the DHTML/CSS environment. Instead of having to have JavaScript and all the other nonsense that exists today, we should have been able to just use an applet to do all the dynamic manipulation of the web page that is done today with scripting and other plugins such as flash even.

I interacted with many of the top people at Sun via that Sun Developer Advisory Council. Believe me, they had no clue what to do about a "user interface". All of them just wanted to sell servers and server software because that's where the money was for Sun.

Sun had no idea how to make money off the client application environment. Thus, they were not interested in it. They bought the JavaSE phone and many other technologies but just could not muster any level of negotiation nor business decision to make it happen. I'm sure that the JavaME licensees were like "what, you are going to compete with us using a different platform?" We'll stop paying you license fees then. And well, they just couldn't afford that.

Look at Oracle suit against Google. All the JavaME phone vendors are jumping to Android. Oracle just lost a large amount of income from their purchase of Java!

Others have figured out that if you have a place for people to go and pay for software, they will come and pay... Not everyone thinks or even believes that free is an essential component of useful software.

It isn't about the language exactly

While java may or may not be a "good" language. I think we are asking the wrong question - and we always ask the wrong question. We treat our applications as if they are tabulae rasae (I knew my classical education would do something useful at some point - didn't realize it would be 40 years after the event!).

When we develop apps we seem to start from a blank slate. So we have to teach our apps the same thing over and over again. How to initialize themselves, how to confiugure themeselves, how the database connections will work, what the data model underlying the app looks like.... In many ways we've done all that stuff - many times over. If we look at the grunt work to "creavity" ratios in the whole of the lifecycle, I bet we can find that ratio is skewed the wrong way. I haven't done the analysis but it certainly looks that way judging from the number of solutions to logging, config management, etc. that I see.

When I was doing some Rails development, I needed a security framework - managing log-ons, paswords, etc. That didn't have much to do with the guts of my application - it was necessary iverhead so I found one that worked. Yes, Open source. Now this isn't a "let's rush to Rails" statement - just the view that you can perhaps find something useful elsewhere. That's not new either, of course.

Then we have a variety of competing frameworks which pile complexity on. Maybe valuable, maybe not. They are of course designed to make it "standard" to follow a particular path. But again those are at the wrong level. They are essentially syntactic. We need to have our environment "pre-wired" in the same way dogs appear to be "pre-wired" to exhibit dog-nature.

Development feels like ground hog day to me.

Give him a lollipop

When someone says “I want a programming language with which I need only say what I wish done”, give him a lollipop...

I am not going to introduce the reader to the Java language, nor its platform, but rather highlight a few pertinent aspects of the technology that makes it my business to ensure that folk are aware of what is going on.

(This comment is largely taken from wikipedia - its common knowledge - you can find links to all my references there...)

The main thrust here is that Java is way beyond a simple OO language, and its platform is, well, demonstratively successful and won't be having any of this "Java is dead" business ;)

Virtual Machines

There is a large number of Java Virtual Machine implementations, spanning an extremely broad range of hardware (Let's not forget the Java's roots in the Oak language...).

Some of these VMs are proprietary:

Azul VM a segmented Java Virtual Machine based on a proprietary chip architecture optimized to run pure Java. The HW backend allows for 54 cores and Terabytes of memory, with no garbage collection costs.

CEE-J is a clean room implementation of Sun's Java technology, Skelmir is not a licensee of Sun.

Excelsior JET (with AOT compiler)

Hewlett-Packard, Java for HP-UX, OpenVMS, Tru64 and Reliant (Tandem)UNIX platforms

J9 (IBM), for AIX, Linux, MVS, OS/400, Pocket PC, z/OS

JBed, (Esmertec) is an embedded Java with multimedia capabilities

JamaicaVM, (aicas) is a hard real-time Java VM for embedded systems

JBlend, (Aplix) is a Java ME implementation

JRockit (originally from BEA Systems) acquired by Oracle for Linux, Windows and Solaris

Mac OS Runtime for Java (MRJ)

MicroJvm (IS2T - Industrial Smart Software Technology) Wide range of virtual machines dedicated to embedded systems (including hard real-time constrained systems), ARM7, ARM9, AVR, AVR32, PPC, MIPS, ...

Microsoft Java Virtual Machine (discontinued in 2001)

OJVM (also known as "JServer") from Oracle Corporation

PERC (Aonix) is a real time Java for embedded

Blackdown Java (discontinued in 2007)

C virtual machine (CVM, from Sun), supports C

Gemstone - modified for Java EE features (application DBMS)

Golden Code Development (EComStation and OS/2 port of Java RTE and SDK for Java SE v1.4.1_07)

Intent (Tao Group)

Novell, India.

NSIcom CrE-ME

HP ChaiVM and MicrochaiVM

Some are open:

HotSpot

AegisVM

Apache Harmony

CACAO

Dalvik

IcedTea

IKVM.NET

Jamiga

JamVM

Jaos

JC

Jelatine JVM

JESSICA (Java-Enabled Single-System-ImageComputing Architecture)

Jikes RVM

JNode (operating system)

JOP (Hardware implementation of the JVM)

Juice

Jupiter

JX (operating system)

Kaffe

leJOS

Maxine (meta-circular JVM being developed by SUN)

Mika VM

Mysaifu (Windows CE / Windows Mobile)

NanoVM

SableVM

Squawk virtual machine (for embedded system and small devices)

SuperWaba

TinyVM

VMkit of Low Level Virtual Machine

Wonka VM

Xam

JVM Languages

Java language aside, there are a number of high-profile programming languages that run on the Java VM:

AspectJ, an aspect-oriented extension of Java

ColdFusion, a scripting language compiled to Java

Clojure, a functional Lisp dialect

Groovy, a scripting language

JavaFX Script, a scripting language targeting the Rich Internet Application domain

JRuby, an implementation of Ruby

Jython, an implementation of Python

Rhino, an implementation of JavaScript

Scala, an object-oriented and functional programming language

There are many Java implementations of existing languages:

Ada JGNAT
AWK Jawk
C C to Java Virtual Machine compilers
Cobol Veryant isCobol
ColdFusion Adobe ColdFusion Railo Open BlueDragon
Common Lisp Armed Bear Common Lisp CLforJava Jatha (Common LISP)
Component Pascal Gardens Point Component Pascal
Forth myForth
JavaScript Rhino
LOGO jLogo Xlogo
Lua Kahlua Jill
Oberon-2 Canterbury Oberon-2 for JVM
Objective Caml Ocaml-Java
Pascal Canterbury Pascal for JVM
PHP IBM WebSphere sMash PHP (P8) Caucho Quercus
Python Jython
Rexx IBM NetRexx
Ruby Jruby
Scheme Bigloo Kawa SISC JScheme
Tcl Jacl

Apart from existing languages, there are a number of new programming languages that have been
developed on the Java VM:

Alef++, a programming language inspired by Perl and Lisp.

AspectJ, an aspect-oriented extension for the Java programming language.

BeanShell, a scripting language whose syntax is close to Java.

clojure - a Lisp Dialect

Duby, a customizable programming language featuring type inference and a heavily Ruby-inspired syntax.

The E programming language has an implementation on the JVM.

Fantom, a language built from the ground-up to be portable across the JVM and the .NET CLR.

Flow Java.

Fortress, a language designed by Sun as a successor to Fortran, mainly for writing parallel scientific computations

Frink, a language that tracks units of measure through calculations.

Hecl

Ioke, a prototype-based language somewhat reminiscent of Io, with similarities to Ruby, Lisp and Smalltalk.

Jaskell, Haskell inspired scripting language

Join Java, a extends Java with the Join Semantics of the Join Calculus.

Jelly (Programming Language)

Joy

Judoscript.

N.A.M.E. Basic.

NetLogo, a multi-agent programming language.

Nice.

Noop, a language built with testability as a major focus.

ObjectScript

Pizza, a superset of Java with function pointers and algebraic data types.

Pnuts.

CAL, a Haskell-inspired functional programming language.

Sleep, a procedural scripting language inspired by Perl and Objective-C.

The V programming language[18] has an implementation on the JVM.

X10, a IBM language designed for high-performance heteregenous clusters and parallel scientific computations. Syntax of X10 is highly based of Java, and optimizing compiler targets JVM or C++.

Yeti, a ML style functional programming language, that runs on the JVM

Da Vinci VM – OpenJDK now provides explicit support for other languages.

I just want to highlight Fantom (latest-greatest) – it can be written once and compiled for Java VM,
.NET, or JavaScript!!!

Several C to Java bytecode compilers exist:

NestedVM translates C to MIPS machine language first before converting to Java bytecode.

Cybil works similarly to NestedVM but targets J2ME devices.

LLJVM compiles C to LLVM IR, which is then translated to JVM bytecode.

C2J is also GCC-based, but it produces intermediary Java source code before generating bytecode. Supports the full ANSI C runtime.
Axiomatic Multi-Platform C supports full ANSI C 1989, SWT, and J2ME CDC 1.1 for mobile devices.

Java Backend for GCC, possibly the oldest project of its kind, was developed at the The University of Queensland in 1999.

Javum is a port of the full GNU environment to the JVM, and includes one of the above compilers packaged with additional utilities.

Just to highlight two of the above technologies – Da Vinci VM, and Javum. The former being an open standard for any language to be able to exploit the Java VM. The latter being a complete port of the GNU UNIX libraries, including a C compiler!

High Performance

The following is James Gosling's facebook note on the CurrentState of Java HPC:
http://www.facebook.com/note.php?note_i =24763131623d

He refers to this article, which is summarised below:
http://proactive.inria.fr/userfiles/file/papers/ProActiveJavaStatusforHP...

Integer and double arithmetic are no longer an issue since Java 6

Java NAS Parallel Benchmark compared to a Fortran MPI implementation only lags behind on strongly communicating applicat ons when it comes to speed.

On most NAS benchmarks, however, Java performs as well as MPI as the number of nodes approaches 32.

Java IS and EP benchmarks are on a par with MPI on up to 64 nodes.

When using high-performance inter-connects (e.g. SCI), as JFS network layer plugins, the gap between Java and Fortran NAS benchmarks narrows even further. Parallel garbage collection can be kept to a minimum, resolving multi-core performance issues.

The overall result at the time of he above survey is that the overhead of Java is acceptable for computationally intensive work. Optimised inter-connects can alleviate any network layer lags (RMI implementations vs MPI). The HPC community has been building on these findings since: Ibis – a
flexible and efficient java-based grid programmingenvironment.

In closing our little Java expose, it should also be noted that the current ground-breaking research in parallel programming (where multiple-threads, multiple-processes, semaphores, signaling and waiting is deemed BAD), is also done on Java technology. The current popular avenue is called software transactional memory – treating memory like a database... (e.g. JVSTM, Deuce, Multiverse)

GPU-wise; you can use a GPU on the Apache Hadoop (HUGE distributed processing architecture) platform without even changing your code! Just deploy the appropriate SPI plugin, and all your map-reduce calls will be delegated to the accelerator instead of your CPU.

Apache Maven is another paradigm-shifting Java technology that I can't even begin to discuss in this document...

Conclusions,

So, the short story of the long story is that Java, as a language and a platform, has pioneered all aspects of computation that a computer scientist or programmer could ever care about. Furthermore, it has also adapted and evolved in a usable way, incorporating new concepts and approaches to computation all along. I know, I've been using it in anger for over 15 years...

I remember I once heard the

I remember I once heard the definition of "legacy" as, anything not written in Java.

For Web applications, Java is

For Web applications, Java is dead. Long live PHP :-)

Dynamic data may be the decider

Don Syme of Microsoft Research makes a strong argument for data-rich functional languages in this age of dynamic data generated by new applications evolving at a frantic rate. His PDC10 talk on extending the F# compiler to be data-aware is a real eye-opener. His demo of code processing a periodic table from freebase.com has to be seen (you can skip to about 0:29mins into the video to get the gist of it). See http://bit.ly/bfWDkA.

Yah! They're all going to RoR!

Oh wait, that didn't happen, did it Bruce Tate? Errr I mean Mike Gualtieri

That's quaint to parrot the "Java is dead" chant. I think we've heard that for 10 years...

However, websites like dice.com slew of Java positions, and tiobe's to programming languages, disagree with your opinion.

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

It is akin to saying "C/C++ is dead and it's time to move on".

Not "Dead". "Dead-End"

Code Ninja,
If you read more than just the title of the post you'll see that I say Java is good for some types of applications. But, when it comes to enterprise business applications I think there is a better way. The number of jobs or the number of people using something is not evidence that it is the smartest choice.

are you frustrated about Java?

To the author of the article: Have you ever written a decent Java application? LOL. It's really fun to read all those comments. It's nice to see there is a competition, but to say that Java is dead? no it is not, not at all. There are some downsides, but still, it does what it does, running on almost every OS, being open sources, and backwards compatible. Off course an evolution is needed, but there are evolutions. The standard is not ideal, but there are enough opens source variants.

Btw, nobody forces you to use Java ;-). The moment Java is dead, is the moment that nobody talks about it, nobody programs it, and nobody teaches it. That's the moment that Java is dead, and not 1 day earlier...

We need to innovate beyond Java not within it

Robrecht, LOL. I have written many, many decent Java applications and made a lot of consulting money because it takes longer, is more complex and harder to maintain. I've used most of the popular frameworks as well. I am not saying that Java can't get the job done. Clearly it can. What I am suggesting is that it is time to move forward and innovate not within Java, but beyond.

For Web development, Java is

For Web development, Java is too cumbersome. PHP is much more suitable for Web apps.

Written in Hurry ?

This is an amazing report - headline makes you read the entire report thinking that something exciting will happen next . . . . and after reading you realize folks at Forrester also go wrong.

- rohit

Silver Bullet

I agree partially with the sentiments expressed in this article, however the reality is that what you are saying is that we need a "silver bullet". That will NEVER happen, nor should it. As long as there is demand, there will always be an abundant supply of frameworks and platforms, all suiting particular needs and contexts. In fact, many of those that exist today came to be out of a need for something that the other frameworks or platforms could not provide, and for each one of those there are 100 others that have been home grown to meet the needs of the particular business problem, as part of a service offering, etc...

I am a long time .NET developer, having worked with the platform since it was in alpha. However, this has become less significant over that time to the extent that it doesn't matter anymore which language you choose vs. another. The choices and resulting benefits are as varied as the personalities, team dynamics and skill sets that come into play when making the choice about which to use.

It is the interoperability of the platforms, and even more so the efficiency with which the development team can develop, implement and maintain throughout the software development lifecycle which matters, and those who get stuck on languages and platforms, often due to religious battles, will miss opportunity time and time again.

Why Pascal is not my favorite programming language

In 1981, Brian W. Kernighan, wrote a somewhat famous paper, "Why Pascal is not my favorite programming language."

Before we begin writing the obituary for Java, we need someone to explain in as clear terms as those used by Kenrighan, what exactly is wrong with Java. It remains as the portable, safe, reliable, dynamic, multi-threaded, familiar and efficient standard that, as was pointed out, was in the right place at the right time.

John Mitchell, Stanford's guru on programming languages, states clearly that expressiveness versus efficiency is the challenge. Expressiveness of common abstractions is what fueled Visicalc and then Excel to be the de facto standard for simple user controlled Business Analytics. Custom applications are "custom" because the available abstractions supported through the expressive features of the myriad of applications and middle ware products do not match the requirements of the custom-er.

Custom development will persist for some time to come and the generic apps and middle ware products will need a portable, safe, reliable, dynamic, multi-threaded, familiar and efficient standard programming platform.

Expressiveness versus efficiency challenge

Thomas, Thank you so much for pointing us toward Kernighan paper. I think the expressiveness versus efficiency is a key challenge in finding an application development authoring tool. I hesitate to use "programming language" because I think kit is too limiting. Java does have a nice balance of expressiveness and efficiency for many app types such as systems software and development platforms. For application development, a higher level of abstraction would benefit many business solutions. I think the challenge now is what you say about finding an "efficient standard programming platform". There are numerous vendors and open source projects that have more productive development tools but they are not necessarily standard. So when choosing a platform to develop applications, app dev pros must also consider whether or not this platform will be around. There is a trade-off between standards and productivity.

Java's fall is not a technology issue

When you look at what Java is capable of and how it could be used, you see all the technical merits and faults which we are all familiar with, or can find plenty of opinions to read about such.

The problem with Java is that it is not being considered a vehicle by Oracle. Sun eventually figured out that it could only ever be a vehicle for them, but by the time they figured that out, so many others had a head start, that they couldn't keep up (they never solidified a desktop platform and model for using Java for web apps and desktop apps the same way. The technology was available, just no attempt to reign in all the disastrous attempts (too many web UI platforms and applet vs Java Web Start [JWS] and others).

The time to invest in any of those was huge and inter-working between them was non-existent because of platform only APIs like the "Applet" methods that didn't exist in JWS.

Look at the I/O model differences between JME and JSE as another example. The technologies in JME should have replaced or been available in JSE from the get go because it was "possible".

In the end, Sun had no idea how to administrate standards on the desktop. Now Oracle is crushing Android because it interferes with the profitability of the JME licensing.

What we see happening is people trying to take control of all the Java development community and dance the Oracle dance, instead of just innovating to find a profitable way to use Android as a vehicle to success. Oracle could be pioneering database access on android to compete with iOS CoreData. They could provide a "sync" between Enterprise Oracle instances and the devices so that people could take the database on the road with them and then bring it back to "sync" with the enterprise, seamlessly.

But in the end, what is happening is that Oracle could care less about the Java technology. That's not what Larry is interested in. He is only interested in the numbers, and if he starts the day with the numbers lower than the day before, he doesn't look for things to do to increase market share. Instead he looks for things to do that wring money out of people who are already paying too much, by reducing choice in their world so that they have to come to Oracle (as opposed to wanting to come to Oracle for the value added).

People who want choice and want technology to win, are going to vote with their legs. They will go where technology is actually enabling them with value that yields money in their pockets.

What will be the winning technology when Oracle gets Google to pay up? Will Google pay out, or will we get another new mobile device technology next?

I agree with you that Java

I agree with you that Java and alikes are not the best tools to implement business rules. But it all depends of the complexity of the task.

I work with COTS products more than 10 years. And I have to say that my carreer as a computer programming have been changed since then. Instead of complaining about bugs or optimization on the application codes, with COTS I could talk at the business level to my customers. Instead discussing new algorythms, I rather talk about new ways to improve my customers business.

But COTS are expensive solutions. No doubt about that. And expensive to maintain. Actually, in my point of view, COTS strategy is to be able to divide the problem of developing an application in two different stages:

Stage 1: develop and maintain a platform where is possible to build business rules (expensive to maintain and code intensive, and another hidden cost: multinational companies have to move to new O.S. versions, database versions almost every year, obligatiing COTS suppliers to validate their solutions with every new flavor of Windows, Linux, Oracle...)

Stage 2: understand business needs and implement solutions for them (much easier to maintain or change and codeless)

So, the "new platform" already exist, as there are plenty of COTS suppliers around. And because they are focused on the business they intend to support, in my opinion, definetely would be unlike to have a COTS generic language that would adapt to any kind of specific needs for every industry, or any company eager to invest in developing a generic COTS platform - it will confuse the market, and knowing the sales cycles, it will be very hard to sell.

So COTS are for big business.

Mid and smal sizes business that cannot afford to buy and pay the annual support fees a COTS demands, can still count on Java or alikes. The complexity of the business are not so high, changes are not so frequent, they are not audited frequently as a big company, so they do not need to be in compliance with SARBOX, ISO, etc.

I hope it helped a little.

Regards.