For example, a new java compiler could allow for some breaking backwards compatibility to allow for things like overloading on generic types like:
void foo(List<String> arr);
void foo(List<Integer> arr);
Or to allow things like generics over primitive types
void foo(List<int> arr);
Now I am not suggesting these are trivial changes, or that everyone would even use such a compiler, but I was curious why I could not find ANY alternatives to javac. Even if you never modified the bytecode spec, some of these changes (and others) could be implemented purely at compile time. If nothing else, it could allow a nice testbed to merge changes back to mainline in some fashion (I get that changing the semantics of the language means it is no longer “Java”, but let’s call it J++ or something).
I like Java’s backwards compatibility first mentality, but I was surprised this is not an approach people have taken over completely new languages like Kotlin/Ceylon/etc.
Is there more going on here that prevents this from happening?
3
I think this is the sort of thing you are positing does not exist:
- http://pizzacompiler.sourceforge.net/
it is an existence proof of what you’re looking for (but from 12 years ago — many of the features in that “extended Java compiler” eventually migrated into the real Java compiler). In fact, Java keeps evolving at a reasonable (okay, that’s debatable) pace, so “extensions” to the language get considered and implemented in Java (see https://en.wikipedia.org/wiki/Java_version_history)
But more broadly, I think you could argue that Scala (http://www.scala-lang.org/) meets your definition. Its broken backwards compatibility at the source level (the language is totally different), but generates output that runs on a vanilla JVM, and, more impressively, it is interoperable with standard Java libraries.
All the other JVM-based languages (like groovy, jruby, jpython, etc) also fall in this category. See https://en.wikipedia.org/wiki/List_of_JVM_languages for a more comprehensive list. (Note that there are a couple entries on that Wikipedia page that claim to be supersets of Java, even.)
I think anyone that would take the time to implement a Java++ would probably want to fix a lot of stuff. And would end up creating something completely different. A lot has been learned about language design in the last 20 years, and the JVM provides a compatibility mechanism that doesn’t require source code compatibility.
3
Back in 2004 Microsoft did have a product called J++. It got Microsoft involved in a bitter court battle with Sun Microsystems which Microsoft lost. A ton of stuff in the Java eco-system is heavily protected by intellectual property and trademark law, and Oracle has an army of lawyers to enforce it. One of Java’s big selling points has been cross platform/cross-vendor compatibility. As someone who is currently trying to get a thick stack of libraries to all build nicely on Linux using GCC and on OS X using Clang I kind of see the value in that.
2
I would add to P.T. answer above. Scala as a functional programming language which compiles to Java bytcode (so uses JVM) allows some fancy FP footwork but either way the answer resolves to a hack. here is a link to a previous asked similar question for Scala:
https://stackoverflow.com/questions/4982552/scala-method-overloading-over-generic-types
I would be hesitant to suggest Java 8 may be able to provide a similar hack given functions are now treated as first class citizens and can be passed around as arguments much like Scala.