BiJava: Backwards-incompatible Java

"no primitives"

And this would be "recognizable" Java?

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).

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.

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

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

@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

 

 

"Things you should never do" part 1

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