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

BiJava: Backwards-incompatible Java

10.13.2010
| 6191 views |
  • submit to reddit

Stephen Colebourne has a great idea: How about creating a version of Java that is not backwards-compatible? That would mean that it could lose some of its weird and/or hard-to-learn features, while still being recognizably Java and without suffering from the feature overload of some of its competitors. Colebourne also lists three features that BiJava (backwards-incompatible Java) should have: no primitives, nullable types, equals operator. Observations:

  • Avoid feature overload: Larry Wall’s oft-cited saying “there is more than one way of doing things” to me is the very definition of bad language design. Scala and Clojure might suffer from this problem (disclaimer: I still don’t know these languages well enough for an informed opinion).
  • Typing method parameters is great: It allows one to do static checking and documents what’s going on. Languages with algebraic types (ML, Haskell) tend to have even more custom types; they even wrap the type where in Java, one would probably use naked strings. A great practice.
  • I would also argue that (a simple version of) closures should completely replace inner classes. They are immensely confusing to newcomers and not needed if you have closures. Smalltalk and (the partially Smalltalk-inspired) Ruby show that closures and object-orientation are not antithetical.
  • Groovy++ looks interesting, sometimes it seems to stray too far from Java (why in hell are semicolons optional?). [As an aside: Groovy++, please get a proper home page, for those of us who are banned from Google Groups.]
  • ABCL (Armed Bear Common Lisp) is also worth checking out. I love their tongue-in-cheek slogan “The right of the people to keep and arm bears shall not be infringed!”. Like Clojure, ABCL is Lisp, but closely emulates Common Lisp which means it is a simpler language.
My own wish lists for Java:

From http://2ality.blogspot.com/2010/10/backwards-incompatible-java.html

Published at DZone with permission of Axel Rauschmayer, author and DZone MVB.

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

Tags:

Comments

Fabrizio Giudici replied on Wed, 2010/10/13 - 2:59am

"no primitives"

And this would be "recognizable" Java?

Oliver Weiler replied on Wed, 2010/10/13 - 4:26am in response to: Fabrizio Giudici

If you want to give up backward compatibility, then why not use another language in the first place? I've just switched to Python and it is very easy and fast to learn.

Vassil Dichev replied on Wed, 2010/10/13 - 4:39am

There are three ways to create a language:

 

  • create it intentionally simple, leaving the programmer to deal with complexities. This type of language will often grow ad-hoc features which solve only part of the problem, and I think the proposals for Project Coin are an example for this type of "evolution"
  • include any and all features and conveniences from the start without much consideration how the fit together and how cohesive they are. Maybe you're thinking of Perl as an example for such a language, and the arcane rules and exceptions for a language like this are difficult to remember. As a result it's difficult to maintain code written in the kitchen sink language
  • provide fewer, but more general features which can abstract a lot of the use cases. For instance I consider first-class functions as fundamental for abstraction. IMO another good example is how well pattern matching in Scala fits in the language- it's used for functions literals, exception blocks, assignment and "for" expressions.

Whatever you think about Scala, I fail to grasp how you can lump Clojure in the "feature overloaded" camp. Being a Lisp, it is a very minimal language and most of the features are defined as external libraries and macros. The difference between a rich language and a rich library is subtle, but important: you can easily replace or disable a library, but not a language feature.

At any rate, Groovy/Groovy++ is not a simpler language than Clojure by any means, and I would also claim it's not simpler than Scala, but that is arguable (it has more hard-coded syntax, but Scala has a richer library).

Dominique De Vito replied on Wed, 2010/10/13 - 8:16am

I don't think it's time for JDK 7 to create a major backwards-incompatible Java...

May be we could think about it for JDK 8 timeline.

BUT, this being said, I think it could be quite interesting, for JDK 7, to build and provide/offer 2 flavors of such JDK:

(a) one flavor with all code

(b) another flavor without all currently existing deprecated classes+methods!

 

IMHO, option (b) could be interesting to let users play with no @deprecated methods, and to let them learn starting to live with a backwards-incompatible Java.

What do you think about this idea ?

 

Kevin Jordan replied on Wed, 2010/10/13 - 9:11am

I think using the javac target flag would be the easiest way to do this. If you specify the latest version then previous VMs won't run it. This way you could compile a version for previous ones if you wanted to but still be able to force the latest features. This would put more work on the compiler to make the features backward-compatible if possible, but it would also allow more going forward. They could make a version where generics is more than just used at compile-time. And assuming you wanted to make it available for previous ones, you could just use the target flag and it would revert to type erasure or if you had used new features it would just fail to compile as usual.

Axel Rauschmayer replied on Wed, 2010/10/13 - 1:11pm in response to: Fabrizio Giudici

@Fabrizio: Apart from worries about efficiency, why keep primitive types? They are a source of many idiosyncracies in Java. Languages such as Common Lisp and Dylan have figured out how to treat everything as an object without sacrificing efficiency, why can’t Java?

Bracha has more to say on this: “Original Sin”.

J Szy replied on Thu, 2010/10/14 - 1:17am in response to: Axel Rauschmayer

Common Lisp and Dylan have figured out (...) why can’t Java?

Java should learn from others' failures, not copy them.

Nirob Hasan replied on Thu, 2010/10/14 - 2:39am

Yeah your idea was great. I think other language too.If you are looking for a document generation system on Java, take a look at this Java document generation site. It has basic info on all the vendors. It makes for a great starting point.

Cosmin Mutu replied on Thu, 2010/10/14 - 3:22am

@Dominique : I think that creating a double release, is a great ideea, but it might create some confusion ... most people would download the version with backward compatibility, since the other release can only be used on NEW projects and on TO BE REFACTORED projects.

Instead, I think that users should really pay attention to @Deprectated and try to use them as few as possible. I would really like it if IDEs would have some sort of configuration that would remove from their code assist all DEPRECATES.

In fact, I just searched for ECLIPSE and they seem to have such configuration... yay! :)

Here is how to set this up in ECLIPSE: Window -> Preferences -> Java -> Editor -> Content Assist -> Hide deprecated references.

Here is also the link where this was proposed:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=127296

 

 

Dominique De Vito replied on Thu, 2010/10/14 - 4:47am in response to: Cosmin Mutu

@Cosmin

I see your point. Then, let's propose something a little different.

I would like the compiler not to link @deprecated methods by default, while those methods could be still available using a given compiler option.

 

Indeed, thinking again about this topic, I think the compiler may be the best way to enforce (more and more) best practices.

 

Dominique

http://www.jroller.com/dmdevito

 

 

Pedro Worcel replied on Thu, 2010/10/14 - 10:59am

"Things you should never do" part 1

 http://www.joelonsoftware.com/articles/fog0000000069.html

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.