Generics are implemented using erasure as a response to the design requirement that they support migration compatibility: it should be possible to add generic type parameters to existing classes without breaking source or binary compatibility with existing clients. I wrote about this two years ago. Migration compatibility is exploited widely in JDK5; all of the collection classes and interfaces use generics, yet existing code using collections continues to work. Without migration compatibility, the collection APIs could not be retrofitted use generics; we would probably have added a separate, new set of collection APIs that use generics. That was the approach used by C# when generics were introduced, but Java did not take this approach because of the huge amount of pre-existing Java code using collections.
A non de-facto implementation? Like RoboVM or IcedTea or JRockit (was acquired and merged into mainline JDK) or the ones from here: http://en.wikipedia.org/wiki/List_of...rtual_machines
Java is a trademark protected word. You can't name your own tech Java, just like you can't name your own tech company Microsoft or Google either. That's not an unreasonable restriction.
You can also freely fork Java, as long as you keep it under GPL terms, which Google didn't want to do with Android.
I completely acknowledge there is uglier legal or political issues invovling the JCP and the disputes with Apache Harmony and even Android.
Before Xamarin split from Novell and chose its current name, that team did support and promote Silverlight for many years before eventually cancelling it.