What if Java 8 dropped 'extends'?

Java is looking like everything including the kitchen sink. How about 'give one get one' for Java 8 -- and dropping inheritance entirely?

Frankly, I think most of what Java 8 is planning to do is let the fanboys dump every feature they can think of into the language.

I'm not against those features per se, and the JVM itself should support them, but I'm less enthusiastic about the mangled syntax that is the Java Lambda project. It isn't the features that are bad, but if you stick too many ingredients in any soup, you end up with stew. Keep going and you hit some kind of food sculpture.

[ After a bad year, Java heads in the right direction | Think you know Java? Test your programming smarts in InfoWorld's Java IQ test. | Master the latest in Java development with our JavaWorld Enterprise Java newsletter. ]

That seems to me to be the general direction of the Java language. Then again, I never got over how cracked the Java Generics syntax is, at least at the edges (not for using generic classes, but for making them).

Java was supposed to make things simpler
I don't believe in hierarchical ontologies. I believe in tags. When C++ came out, a lot of developers felt the need to use its features and often created horribly monstrous code that overused inheritance, virtual functions, operator overloading and templates, and all of the nonsense.

Java began the trend toward simplicity by dumping many of the more complex features in C++, such as operator overloading and multiple inheritance, sidestepping much of the need for the latter by introducing interfaces.

Many of Java's adds over the years were either workarounds for an overly persnickety and initially somewhat useless type system (such as Java 2 classloading, generics) and a lack of a read-write language metamodel (annotations, instrumentation, java.lang.reflect.Proxy).

What if we dropped class inheritance entirely?
This got me thinking about what I could live without. What could we take out of Java? As cracked as it may seem, I could live without the extends keyword.

What the frak, you ask? Well, inheritance isn't tagging -- it's enforcing a hierarchy. Pure hierarchies don't tend to exist in nature, business, or anywhere else but in the human mind. There have been languages with objects but no inheritance. OK, fine, extends Object is probably useful, but do I need to go any further?

What could I do instead? For one, annotations are frequently used for AOP (aspect-oriented programming)-style instrumentation at compile, classload, or runtime. You can use interfaces. Static imports were already added to Java, so why not imports of template methods (of sorts)? Would I really miss a superclass? I use it sometimes, but rarely is it something I absolutely couldn't live without. Its absence might actually do us some good. No one could ever create anything that even remotely looked like EJB 2 ever again. Strangely bad APIs would have to be rewritten.

Crazy? Consider the Java Servlet: Have you ever thought about why it is you override specific methods in one class rather than, say, MyServlet implements HttpGet? Or better yet, use annotations -- none other than Oracle agreed with you. In Servlet 3.0 you don't need to extend anything and can just use said annotations. Where do we need extends really?

Chalk one up for the aging AOP fanboys. As it turns out, cross-cutting concerns are a more common case than actual lineage, à la inheritance. Frankly I'll do anything to not see code that has something like AbstractSecureAndAsynchronousBlobbyThing next to its kin AbstractSecureBlobbyThing and AbstractAsynchrnousBlobbyThing.

Will Java 8 drop the extends keyword? Almost definitely not. That said, I stopped using it a while ago, except for workarounds or where required by legacy code.

This article, "What if Java 8 dropped 'extends'?," was originally published at InfoWorld.com. Keep up on the latest happenings in application development at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Join the discussion
Be the first to comment on this article. Our Commenting Policies