Oracle lays out long-range Java intentions

2012-03-15, InfoWorld, by Paul Krill
Click here to see the article

Interoperability goals include a multilanguage JVM and improved Java/native integration

Oracle's wish list for Java beyond next year's planned Java SE (Standard Edition) 8 release includes object capabilities, as well as enhancements for ease-of-use, cloud computing, and advanced optimizations.
JDK (Java Development Kit) 10 and releases beyond it are intended to have a unified type system, in which everything would be made into objects, with no more primitives, according to an Oracle slide presentation entitled "To Java SE 8 and Beyond!" posted on the QCon conference website. Oracle cites an ambitious list of goals for Java in the presentation, which was apparently delivered by Oracle Technology Evangelist Simon Ritter last week.

A slide entitled "Java SE 9 (and Beyond)" reveals goals for interoperability, including having a multilanguage JVM and improved Java/native integration.

Other languages besides Java, such as JRuby, Scala, and Groovy, already have become popular on the JVM in recent years. A timeline provided in the presentation has JDK 9 arriving in 2015, JDK 10 in 2017, JDK 11 in 2019, and JDK 12 in 2021. The presentation declares, "Java is not the new Cobol."

Ease-of-use goals for Java include a self-tuning JVM and language enhancements. Advanced optimizations eyed include the unified type system and data structure optimizations. Under the subheading, "Works Everywhere and With Everything," Oracle lists goals like scaling down to embedded systems and up to massive servers, as well as support for heterogeneous compute models.

For cloud environments, a hypervisor-aware JVM is noted as an intention for JDK 9 and above, including cooperative memory page sharing. Multitenancy goals for JDK 8 and beyond include improved sharing between JVMs in the same OS and per-thread/threadgroup resource tracking and management.

The vision for language features in JDK 9 includes large data support, with 64-bit and large-array backing. JDK 10 and above would feature true generics, function types, and data structure optimizations, including multidimensional arrays.

Heterogeneous compute models planned for JKD 9 and beyond include Java language support for GPU (graphics processing unit), FPGA (field programmable gate array), off-load engines, and remote PL/SQL.

Also called for in the Oracle presentation is "open development," in which prototyping and research and development would be done in OpenJDK, which is the open source process for Java. Plans also call for greater community and cooperation with partners and academia.

Links:

• To Java SE 8 and Beyond! , by Simon Ritter
•  Some JDK 8 features (due 2013):
• Project Lambda : Support programming in a multicore environment by adding closures and related features to the Java language; bulk parallel operations in Java collections APIs (filter/map/reduce)
• Project Jigsaw : Module system for Java applications and for the Java platform

Why should you use Unchecked exceptions over Checked exceptions in Java

The debate over checked vs. unchecked exceptions goes way, way back. Some say it’s one of the best features Java included. Others say it was one of their biggest mistakes[1].

It looks like the debate is over. In this post I will try to include the links to articles and books which speaks about this topic. I am not an expert voice in this, but I will try to explain you why did I reach the this conclusion.

So, we are talking about,

Unchecked exceptions :

• represent defects in the program (bugs) - often invalid arguments passed to a non-private method. To quote from The Java Programming Language, by Gosling, Arnold, and Holmes : "Unchecked runtime exceptions represent conditions that, generally speaking, reflect errors in your program's logic and cannot be reasonably recovered from at run time."
• are subclasses of RuntimeException, and are usually implemented using IllegalArgumentException, NullPointerException, orIllegalStateException
• a method is not obliged to establish a policy for the unchecked exceptions thrown by its implementation (and they almost always do not do so)

Checked exceptions :

• represent invalid conditions in areas outside the immediate control of the program (invalid user input, database problems, network outages, absent files)
• are subclasses of Exception
• a method is obliged to establish a policy for all checked exceptions thrown by its implementation (either pass the checked exception further up the stack, or handle it somehow)

The above are as told in Java Practices Page[2].

In many of the projects I have worked on, I have seen different ways of coding and various different strategies, code formatting, class naming styles, databases and technologies. The one thing that remained same was, Exceptions. All the projects had custom exceptions, created by extending Exception class!

I am sure that most us of know the difference between checked and unchecked exceptions, but very few thinks carefully before using them. I wanted all the details to be listed in single page so that I could convince my team to switch to Unchecked exceptions.

In his famous book, Clean code: a handbook of agile software craftsmanship[3], Robert C. Martin writes the below lines supporting Unchecked Exceptions.

The debate is over. For years Java programmers have debated over the benefits and liabilities of checked exceptions. When checked exceptions were introduced in the first version of Java, they seemed like a great idea. The signature of every method would list all of the exceptions that it could pass to its caller. Moreover, these exceptions were part of the type of the method. Your code literally wouldn’t compile if the signature didn’t match what your code could do.

At the time, we thought that checked exceptions were a great idea; and yes, they can yield some benefit. However, it is clear now that they aren’t necessary for the production of robust software. C# doesn’t have checked exceptions, and despite valiant attempts, C++ doesn’t either. Neither do Python or Ruby. Yet it is possible to write robust software in all of these languages. Because that is the case, we have to decide—really—whether checked exceptions are worth their price.

Checked exceptions can sometimes be useful if you are writing a critical library: You must catch them. But in general application development the dependency costs outweigh the benefits

The last line is most significant, where he speaks about the general application development, Lets take an example,

If you have to read an XML file using a DOM Parser, we need to deal with some checked exceptions[5] like ParserConfigurationException, SAXException and IOException . The API developer thought that if the XML was invalid, they should notify so that the consumer of the API (ie, the application developer) can decide how to handle the situations.

Now, If You have some alternatives to proceed with the normal logic, you could do that, other wise you should catch these checked exceptions and throw and Unchecked exception. This way the method signatures will be clean also, we are stating that if the XML is invalid we can not do much, and we are stopping the processing. Let the error handler written at the top layer take the appropriate decision on what to do.

So, all we need to do is to create out custom exception class by extending RuntimeException.

In the Java Tutorial hosted by Oracle, there is an interesting page about this debate[4], the page ends with the line, If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

I have also found a few articles supporting this,

The Tragedy Of Checked Exceptions by Howard Lewis Ship

Exceptions are Bad by Jed Wesley-Smith

Checked exceptions I love you, but you have to go by Misko Hevery

Also, a few articles on general exceptional best practices,

Guidelines Exception Handling By Vineet Reynolds

Exception-Handling Antipatterns By Tim McCune

Exceptional practices By Brian Goetz

Best Practices for Exception Handling By Gunjan Doshi

Spring Java developers get Hadoop integration

2012-02-29, InfoWorld, by Paul Krill
Click here to see the article

VMware's Spring Hadoop offers link between Spring development framework and Hadoop distributed processing platform

VMware on Wednesday is introducing its Spring Hadoop software, which is intended to make it easier for Java developers utilizing the Spring Framework to leverage Apache Hadoop data processing capabilities.

Developers can perform MapReduce queries in Hadoop from Spring, then have triggered event results based on Hadoop, said Adam Fitzgerald, VMware director of developer relations. Also, developers can build complex workloads that interact with Hadoop either as individual MapReduce requests or as data-streaming results. 

Hadoop is Apache's open source platform for scalable, distributed computing, while Hadoop MapReduce is a programming model and framework for processing large sets of data. Spring Hadoop will be available on VMware's springsource.org website and is being released under an Apache open source license.

"Spring Hadoop was created to make it more straightforward for enterprise Java developers to use Apache Hadoop," Fitzgerald said. With the integration, VMWare has taken Spring's dependency injection mechanism for linking related objects and applied it to Hadoop. This saves developers time and increases productivity, testability, and portability, Fitzgerald said.

Spring Hadoop enables execution of MapReduce, Streaming, Hive, Pig, and Cascading jobs via the Spring container. Hadoop Distributed File System data access is enabled through JVM scripting languages, such as Groovy and jRuby. Also, declarative and programmatic support is offered for Hadoop tools, including FsShell and DistCp.

Is Java Dead? Heck No!

2012-02-13, eWeek.com, by Darryl K. Taft
Click here to see the article

A recent JBoss post dredges up the old “Java is dead” argument by calling out the need for polyglot programming or using other languages in addition to Java. But Java is not going anywhere.

For the record: Java is not dead, nor is it dying. It is, however, mature, and perhaps a little grumpy and set in its ways.

Yet it seems one of the best ways to draw attention to a post or commentary on Java and programming is to use the Words “Java” and some variation of “dead” in the headline.

For instance, recently Mark Little, senior director of engineering at Red Hat, wrote a blog post entitled: “JBoss polyglot - death of Java?"

And although the headline suggests that Red Hat’s JBoss unit is pushing a polyglot programming strategy of using several languages for different projects, the gist of the post is that the company is not trying to move away from Java. In fact, Little makes it plain that “we're as committed to Java today as we've ever been.”

Little noted that JBoss is doing projects with languages such as Ruby, Scala, C/C++, Erlang and others. In the post, he said:

… you can't fail to have noticed that we're doing quite a bit of work with languages other than Java. Those include Ruby, via TorqueBox, Clojure with Immutant, C/C++ in Blacktie, Scala in Infinispan, Ceylon and my own personal favorite Erlang. (OK, that's still more a pet project for me than anything else.) But does this mean that we're turning our backs on Java? No, of course it doesn't! If anything it shows our continued commitment to Java and the JVM because all of these approaches to polyglot leverage our Java projects and platforms.

Little added that some of the efforts Red Hat has been involved in that stress its commitment to Java include: Putting JBossAS 7 onto OpenShift; various discussions and presentations on how core enterprise capabilities transcend languages and Java is a great solution; JBossEverywhere is all about making JBoss’ core services and projects available on a wider range of devices and platforms, some of which are not Java-based but many of which are; the company’s increased presence and adoption at JavaOne; and its efforts to define a common fabric/platform across deployments, which will be based on Java and more in line with ubiquitous computing.

“Then there's the number of times that our competitors keep telling people that Java and EE6 are dead and we keep having to set the record straight,” Little said.

So Little makes no bones about acknowledging continued support for Java. He’s just saying Red Hat, like so many other companies, is using other languages. Oracle, the owner and steward of Java is even encouraging Java supporters to use other languages on the Java Virtual Machine. The Da Vinci Machine Project is an effort to extend the Jave Virtual Machine (JVM) with first-class architectural support for languages other than Java, especially dynamic languages.

There Is a Need for Multiple Languages

There are several languages supported by the JVM, including Clojure, Groovy, Scala, JRuby, Jython, Rhino and AspectJ, to name some.

"There is clearly a need for multiple languages,” Mike Milinkovich, executive director of the Eclipse Foundation, told eWEEK. “Mark's post was absolutely right that the JVM is providing the platform for a renaissance of programming language development and adoption. It will, however, be interesting to watch how the JVM-polyglot scenario unfolds, as there is also a cost to projects if they try to build and maintain applications using multiple languages, even if they're based in the same runtime architecture. I suspect it will take a while before best practices emerge."

Essentially shrugging on the discussion, Grady Booch, chief scientist for software at IBM Research and a software and computer technology historian, quipped: “A person who knows several languages is multilingual. A person who knows two languages is bilingual. A person who knows one language is an American. I know of zero projects of any interesting economic value that are not multilingual. But that doesn't portend the death of Java.”

And for his part, James Gosling, the creator of Java, candidly told eWEEK, “Java, the programming language, was always something of a scam to convince C/C++ programmers this brave new world was something that they could understand. All the magic is in the JVM, and I'm thrilled by all the other languages using it, although I've only dabbled in them since none has really converted me. Scala came very close for a while, and I used it in a biggish project, but I ended up reverting. Scala has all sorts of built-in ideas about how to do various things like pattern matching; if it's not quite what you want, you end up fighting. I conceptually like Clojure, particularly its use of immutability, but I exhausted my lifetime tolerance for parentheses when writing my Ph.D. thesis.”

This whole thing about Java and death puts one in mind of Anne Thomas Manes’ 2009 post that SOA is dead, which shed light on services and was not intended to nail the coffin on service orientation—which is still alive and well. And like the constant attempts to bury the mainframe, the rumors of Java’s demise have been greatly exaggerated.

Some Say Rumors of Java's Demise Have Been Exaggerated

Like the mainframe, Java isn’t going anywhere. It is the No. 1 language for enterprise development. IT organizations ask for it for major enterprise projects. There are more Java jobs around than any other. There continues to be a huge demand for Java developers, and as such there is a large base of Java developers and new folks who are learning the language. It’s a stable language that enables developers to create well-structured code that is easily maintained.

There also is a host of good tools for Java. Java has a huge ecosystem and so many of the surrounding projects and products that support mobile platforms and big-time enterprise computing are Java-based: Android, Hadoop, Jenkins, Cassandra and HBase, to name a few.

Also, Java’s position in January 1996 was No. 5 on the TIOBE Index of the most popular programming languages in use by developers. In January 2006, it was No. 1 and has hovered around the top ever since. The most recent TIOBE Index shows Java at No. 1, but was flat for growth.

At 17 years old, Java is certainly mature and beginning to show signs of age in that its architecture, along with the JVM, can be restrictive for some new programming paradigms. Oracle and the Java Community Process (JCP) try to address these issues with updates and changes to the Java language and platform. So despite losing a bit of its luster, the Java standard remains strong.

For instance, at the Free and Open Source Software Developers’ European Meeting (FOSDEM) in February 2011, Stephen O’Grady, an analyst and co-founder at RedMonk, said, “Java is no longer as popular; what Java is, is the most popular.” O’Grady’s FOSDEM 2011 slides can be found here.

However, in a post from November 2010, Mike Gualtieri, then a Forrester analyst, called Java a dead end. The post, entitled “Java Is A Dead-End For Enterprise App Development,” reads:

“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 business process management (BPM), complex event processing (CEP), infrastructure as a service (IaaS), and elastic caching platforms (ECP). Software such as operating systems, databases, and console games are still mostly developed in C++.”

Gualtieri, who is now a vice president of marketing at Progress Software, also said in that 2010 post:

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, BPM and event processing platforms that enable faster change offers by enterprise software vendors such as IBM, Progress, TIBCO and Software AG.

Yet, Gualtieri noted that, “Clear standard alternatives to Java and C# for custom-developed applications do not exist.” And he exhorted app dev teams to create a three-year application development strategy and road map to include architecture, process, talent, tools and technology. The road map should clearly look at language and framework options.

Later, in January 2011, Gualtieri’s Forrester colleague John Rymer did a post on the future of Java, where he quite correctly said:

Fewer young developers will learn Java first. One of Java's greatest strengths has been the number of young developers who learn it as a first language. As Java becomes less and less of a client-side language, we expect to see educational institutions switch to other languages for primary education, ones with stronger client-side representation such as JavaScript and HTML 5. Over time, developers will begin to view Java as a server-side language for enterprises—like COBOL.

Meanwhile, a RedMonk ranking of programming languages from last week shows Java as the top programming language according to their methods of calculating. In a Feb. 8 post, RedMonk’s O’Grady said:

As recently as a year ago, Java was widely regarded as a language with a limited future. Between the increased competition from dynamic languages and JVM-based Java alternatives, while the JVM had a clearly projectable future, even conservative, enterprise buyer oriented analysts—the constituency most predisposed to defend Java—were writing its obituary. As we argued at FOSDEM last February, however, these conclusions were premature according to our data. One year in, and the data continues to validate that assertion.

Apart from being the second-highest growth language on GitHub next to CoffeeScript, Java—already the language with the second-most associated tags on Stack Overflow—outpaced the median tag volume growth rate of 23 percent. This growth is supported elsewhere; on LinkedIn, the Java user group grew members faster than every other tracked programming language excepting C# and Java. This chart, for example, depicts the percentage of LinkedIn user group growth for Java- and JVM-based alternatives since November of 2011.

Still, there are obviously times when a development team needs to introduce a new language into their environment. Jay Fields, a software developer at DRW Trading, offers advice. Fields said introducing a new language is likely a multi-year affair for any moderately sized organization. He said he had to take on several roles and to become an expert and other things to alleviate his teammates’ concerns.

Said Fields:

“I eased my teammates’ adoption fears by making the following commitments.

• If you want to work on the code I'll work with you (if you want me to work with you).
• If you don't want to work on the code I'll fix anything that's broken.
• If the initial pain of working with a new language becomes unbearable to you, I'll rewrite everything in Java on my own time.”