Javalobby

Dr. Axel Rauschmayer is a freelance software engineer, blogger and educator, located in Munich, Germany. Axel is a DZone MVB and is not an employee of DZone and has posted 246 posts at DZone. You can read more from them at their website. View Full User Profile

Java’s missing features

11.23.2009
| 10210 views |
  • submit to reddit

We Recommend These Resources

NOSQL for the Enterprise

The following is a list of the language features I miss most when programming Java:

  • Closures: are useful for implementing abstractions that involve behavior. Smalltalk provides ample proof that functions and object-orientation go together well. Instead of giving Java functions as objects, its creators decided to support the encapsulation of behavior via inner classes. At long last, it looks like Java 7 will have closures. They are essentially functions with built-in compatibility with single-method interfaces. Not perfect, but certainly very useful.
  • Modules: are also coming to Java 7. Reinier Zwitserloot has a nice write-up of the rationale and current state of Jigsaw, Java’s module system. It is interesting that one requirement was that module have to cross-cut packages so that the core of Java can be properly modularized.
  • Generators: let one repeatedly invoke a method. The method does not return a value, it yields it. A yielded value is passed to the caller in the same manner as with a return statement. But, the next time the method is invoked, execution continues after the last yield. Thus, a yield suspends method execution, and an invocation resumes it. This helps whenever data has to be computed lazily, on demand and in a piecemeal fashion: (The beginning of) an infinite list can be iterated over by writing a generator with an infinite loop. Tree iterators become trivial to write; one uses a generator and recursion. And so on... Astonishingly, generators are already in an experimental version of the JVM.
  • Mix-ins: are class fragments that can be added to (mixed in) any given class, while defining it. The effect is similar to multiple inheritance, but results in a chain of classes (and not a tree, as with true multiple inheritance). Mix-ins are also sometimes called abstract subclasses, because they are classes whose superclass is left to be filled in. While it doesn’t look like mix-ins will be added to Java anytime soon, they could be simulated by tools as interfaces with implementations: If one attaches method implementations to special mix-in interfaces, those implementations could be automatically added to classes implementing such interfaces. While the compiled code will contain redundancies, the source code won’t and subtyping will work as expected. The attaching could be done by letting an annotation refer to a class.
  • Post-hoc interfaces: Wouldn’t it be nice if one could let a class implement an interface after it has already been defined? After all, one can add new leaves to the inheritance tree, why not new inner nodes? This would give one many of the benefits of duck typing, while keeping compile-time checking.

While other features (such as multiple dispatch and better code browsing) would be nice to have, the above list contains my most urgent wishes for Java.
References
Reference: 
Java’s missing features
Published at DZone with permission of Axel Rauschmayer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Greg Brown replied on Mon, 2009/11/23 - 7:19pm

So sick of "articles" lamenting what is "wrong" with Java...

Alex Miller replied on Mon, 2009/11/23 - 10:14pm

Re mix-ins, it appears the door is open yet again to adding extension methods to Java.  Extension methods are imho kind of ugly but do give you some of the functionality of mixins (the ability to effectively add methods after definition). 

Re post-hoc interfaces, interface injection is another hot topic in the JVM world and would allow you to do this, as far as I understand it.  That is of course at the JVM level and not at the Java level, but maybe some clever bytecode tool will open this up in some way.

Jose Noheda replied on Tue, 2009/11/24 - 3:49am

AspectJ (Spring if you prefer) allows you to inject interfaces with default implementations. That solves two of your wishes. OSGi resolves another while Groovy takes care of the bulk of the rest. Coroutines are the only point left (I would like to see them added as well). IMO generators, closures and modules are a must for the language. We could talk about multiple inheritance. And I would frankly avoid mixins and interface injection to niche apps and people who know what they do (and to external libraries that is)

Endre Varga replied on Tue, 2009/11/24 - 5:48am

Oh, people, really, have anyone realized, that most of the studentsm have problems even with standard Java 1.4 features and standard libs (not to talk about 1.5)? While I understand the professional standpoint and the usefulness of these features, but most of the beginners do not even understand, what is the problem they solve...

Jess Holle replied on Tue, 2009/11/24 - 6:12am in response to: Alex Miller

Mixins or traits would be huge.

Extension methods on the other hand I'd rather not have.  You don't really add methods after definition -- you add stuff on the caller side to make it look like you've done so as far as the caller source is concerned.  The ad hoc caller side nature of this coupled with the looks like not is behavior makes it a non-starter in my book.

Eleandro Close replied on Tue, 2009/11/24 - 7:15am

there's nothing wrong  or missing in java. java is just java. If you need other things go to ruby, python, javafx. Java has reached its goal. the people stay complains about what is missing in java, but even java 5 is not used in market ( my company uses java 1.4 yet and many companies do the same) .  if these change were added to java 8 when it will be used in the market? never, other languages e enviroment will get there first. We should admit that java is now complete and other languages JVM compiled will appears to solve these lacks. I think javaFX script solves these problems and the sun/oracle should create more tools and ways for javaFX grows in the enterprise.

Tony Siciliani replied on Tue, 2009/11/24 - 9:38am

"Closures: are useful for implementing abstractions that involve behavior"

That doesn't tell:

- why they are useful, i.e. what real benefit it brings to the average programer (= the majority)

- when they are useful i.e. if you could get the same behavior with already existing features

- how often they are useful,  i.e. general usefulness as opposed to niche case scenarios

Then again, most of the arguments I've seen don't answer these questions either. It's always something like "wouldn't it be nice if...".

Same thing for the other "missing" features. I have no problem with the JCP becoming a popularity contest, as long as it is clearly stated that the process is entirely subjective ( the "Coolness" factor) vs. it would make the language significantly better in a objective technical sense. That would be also why I don't like the title of this article. 

Because objectively, the process should be as follows for any new feature:

1. What benefit does it bring, that will offset any troublesome aspect ?
2. Can that benefit  be provided easily using existing features of the language?
3. Can it be implemented as a library rather than as a language feature?

Mike P(Okidoky) replied on Tue, 2009/11/24 - 11:35am

Instead of fighting an uphill battle and try to "fix" Java, why not migrate to Scala instead. It has only one feature missing: break & continue. I'm sure Martin could be convinced that leaving that out was stupid. But other than that, I think it's got it all.

Jan Goyvaerts replied on Tue, 2009/11/24 - 12:16pm

Look, I don't mean to be rude, but I'm a bit tired of all those people telling Java this and Java that. I guess these people would do better than Sun if they had something to say. Or would they ? If you don't like it, stop complaining and don't use it. Switch to one of those VM languages instead. I'm pretty sure you'll find what you're looking for. Or start one yourself. Everything is possible in these fantastic times.

Christophe Hanon replied on Tue, 2009/11/24 - 3:30pm

Well, this is more student work than anything else. So for me Java, the language is fine.New things are nice, yes. Don't take me wrong. But I don't think productivity will dramatically change thanks to closure or anything else in the list.

 Java the platform is more a problem.

What am I missing from Java :

- Simpler persistence (I know each version makes it simpler but it is still too complicated).May be a pure standard object oriented database with an integrated reporting...

- Better, much better Swing, an easy Desktop application framework (I know it is coming, just cannot wait).

- MS (or OO) OFfice like components (a word processor; a spread sheet,...) easy to embbed and to enhance. All in Java please.

- In the same way, a Java based web browser component. Or merge Mozilla iin JVM.

- XUL like language for interface building.

- Plenty of bug fixes and performance improvement.

- Better intergration with Desktop (Windows, Mac, Linux)

- A standard ZK like web developpment framework.

- ...

Well plenty of things to make it a good client application builder. And simpler enough to be effective on small size project.

Also political and commercial aspects matter:

- truly OpenSource I mean the real JDK not a //  by product.

- bundlled and distributed in all Linux distro.

- popular as PHP among hosters with price comparable to PHP.

- nice - really-  Open Source apps -for example CMS - not these open-source-for-the-basici-stuff-and-need-to-pay40K$ -for-getting-still-less-than-joomla.

- transparent market place not the -if-you-want-to-know-the-price-write-us

So these are my dreams. And be sure that if I find something open and multi-vendors like this, I will consider to move on.

 

Christophe Hanon

 

Silvio Bierman replied on Tue, 2009/11/24 - 7:18pm in response to: Mike P(Okidoky)

Watch it Mike! I said something to that effect in the thread about closures coming to Java7. Java extensionalists feel very strongly about the discussion and will surely bash you for saying this :-) BTW: do you really miss break/continue in Scala? I ran a count and found about one for-comprehension per 10 Scala sources (and I tend to pack those with multiple classes) and perhaps one while-loop per 25 sources. Do you use Scala as a "better Java" or do you strive to do things "the Scala way"?

Deepak Goel replied on Wed, 2009/11/25 - 2:38pm

Come on guys - give this guy a break. Why does everybody become so defensive when any weakness of Java is mentioned.

Java as a language has lot of strengths and switching to any other language, just for getting some more features, is not possible in many cases. I'd suggest that people do more research before getting frustrated. For example of why closures are useful, you don't have to go too far - read Mark Reinhold's blog (http://blogs.sun.com/mr/entry/closures).

I think if it was not for people like Axel, Java would have been stuck with the same set of features. All I hear from people is "oh this will make language more complex". Of course, it will but computers are getting more complex every day and some changes are necessary to a language to take advantage of new features.

Personally, I can see direct usage of the following in my work:

  • Closures
  • Modules
  • Mixins
  • Post-hoc interfaces

Endre Varga replied on Thu, 2009/11/26 - 4:49am in response to: Deepak Goel

The problem is not with these features, but I am really afraid that Java becomes like C++, which would be terrible.

Axel Rauschmayer replied on Sat, 2009/11/28 - 7:22am in response to: Greg Brown

@Greg Brown: You are misreading the tone of my article: I'm not criticizing Java, in fact I'm still most productive in that language (due to its tools and the vast amount of libraries available). I'm just curious what language features are out there and if they lead to increased productivity.

Axel Rauschmayer replied on Sat, 2009/11/28 - 8:21am

I agree with people saying that Java is already too complicated. There are things one could do to simplify it (remove primitive types, reify generics, streamline the standard library, etc.), but maybe it is not realistic to perform these simplifications, nor even necessary to do so, as another JVM-based language will cater to people with more difficult tastes. BTW: Languages that I know and like from a perspective of conceptual clarity often have a small group or even a single person dictating their taste. And the languages benefits from it.

IMHO, Java is still doing well, productivity-wise. I used to prefer Python to Java, but then Eclipse (refactoring, code browsing, etc.) came along, which made it hard for me to use any programming language that had less capable tools.

Axel Rauschmayer replied on Sat, 2009/11/28 - 8:20am

I've not chosen the above mentioned constructs for their academic beauty (even though it is there ;-), but depending on what work-arounds caused me the most pain in Java. Here are concrete examples:
  • Closures: The closure proposals for Java (especially FCM) have several examples that I find quite convincing. In one of my projects, there are several methods that always begin with the same statements and end with the same statements. I let those invoke a method that consolidates those statements in one place and invokes a Runnable argument “in the middle”. This would be much cleaner with a closure. Even with object-oriented programs, some things cannot be put into a single class. In these cases, I want top-level functions. Closures are a logical extension of top-level functions. Are anonymous inner classes ever used for anything else than handing over behavior? I think true functions are easy to understand for beginners and closures probably could replace anonymous inner classes completely. This would also allow us to stop using static methods to as pseudo-functions.
  • Modules: are very useful in collaborative settings where you need to control and simplify how people build on shared code. I think, with Eclipse and OSGi, no one argues against this point.
  • Generators: help with implementing iterators (writing an iterator for a tree is complicated; I've tried). Also, any algorithm that produces a stream profits. For example, a tokenizer for a text stream can be implemented as a loop.
  • Mix-ins: If you have a set of tool methods that you would like to see in several classes, you can only do so, if those classes don't already use inheritance. I think interfaces have proven their usefulness; giving methods default implementations seems like a simple extension to me.
  • Post-hoc interfaces: For example, you create a new interface App for appending objects to some kind of stream you have implemented. Making StringBuilder an implementor of App makes it work with all utility methods you write for that interface. Post-hoc interfaces are mainly useful for library developers to make more classes work with their code.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
"Starting from scratch" is seductive but disease ridden
-Pithy Advice for Programmers