1. Oracle is basically arguing about APIs being copyrightable and if APIs are deemed to be copyrightable, we're fucked as an industry ;-)
2. Oracle, because of the Sun acquisition, has many, many interesting patents related to programming languages and virtual machines. Consider that Sun was involved in the research for making Smaltalk VMs fast and they also developed Self. The IP for all the fancy techniques used in Java's HotSpot VM? Well Sun owned it. Do you think Go is safe because it's not based on Java, or because it doesn't have a Java-like VM? Think again, at the very least it has a garbage collector ;-)
Thing is, if Google would have cloned OpenJDK, they would have been safe because of the GPL license. But they didn't, they used Apache Harmony instead, a project that never passed the Java TCK because Sun never allowed it to.
...which was not invented by Sun. GC is like twenty years older.
In the US, in Europe where we are somewhat more sane on this issue I'd look forward to a boom in software development the like of which we've never seen.
The implications for the US software industry are pretty horrify though, it makes software patents look mild.
In practice this is unlikely for a number of reasons, in particular the fact that Europe is way too expensive for the industry that spearheaded third-world "offshoring".
These are large primarily sales driven organizations so first world transport links and infrastructure matter.
The only way to avoid US law is to not trade in the US at all, otherwise someone should have told Samsung and SAP before they paid hundereds of millions to Apple and Oracle respectively.
The "Don't be ridiculous, nobody is going to sue you for using/implementing Java/C#/whatever" attitude was always frustrating, but I have to admit I didn't actually expect it to really happen :-P
But I disagree "we're fucked as an industry", though there could be some inconvenience. The Sega etc. cases still hold, and they essentially say that copying interfaces for binary compatibility / interoperability is fine. As far as statically compiled languages are concerned, that's all we need. If some API creator sues, we can always create / adopt a different API and map it to the binary instructions in the SPI.
Their decisions on patents set precedent, but for copyright they are supposed to follow the precedent of the numbered circuit that the trial court is in, which would be the 9th in this case. Future copyright cases in the 9th will still be appealed to the 9th Circuit, not the Federal Circuit, unless they are also a patent case.
I think there needs to be a change to the way appeals work in cases like this. In federal trial courts, there is a thing called supplemental jurisdiction which allows a court to hear claims that they would normally not have subject matter jurisdiction to hear if they are part of a case with other claims that they do have jurisdiction to hear.
For example, suppose a business deal goes bad, and ends up spawning a lawsuit involving federal copyright claims and state contract claims. Copyright claims must be heard in federal court. Federal courts normally would not have jurisdiction to hear state contract cases, but because of supplemental jurisdiction the federal court will hear the state contract claims too. If the case was just a state contract case, it could not be brought in federal court.
The idea behind supplemental jurisdiction is that in case like my hypothetical business deal gone bad it really is one case that just happened to generate issues that fell under different jurisdictions. If tried separately there would be much overlap in witnesses, documents, and other evidence. It would be an inefficient use of judicial resources and unduly burdensome on the parties and the witnesses.
At the appellate level, the court is examining the trial court's application of the law, not the trial court's determination of the facts. The appeals court works off the transcript and documents from the trial court, and the only people that have to appear physically are the lawyers arguing for the parties.
I think it would make a more sense to let appeals from multi-issue cases to go to multiple appeals courts, each appeals court only getting those issues for which it sets precedent. So in a case like Oracle vs. Google, tried in the 9th Circuit, copyright issue appeals should go to the 9th Circuit Court of Appeals, and patent issue appeals should go to the Federal Circuit. In cases like my hypothetical copyright and state contract case, if tried in the 9th Circuit, appeals on copyright issues should go to the 9th Circuit Court of Appeals, and state contract issues should go to a state appellate court.
It's also the main language taught at universities, which helps with hiring. I've heard that Google's public use of Python is more for PR. If you want to change this then the way is to change what educators are teaching.
Java is probably one of the reasons why they acquired Android. Possibly even one of the reasons Android is written in Java.
I once knew a senior Java architect who turned down a job at Google. This was back in the "who needs another Yahoo!" days. Needless to say they regretted that decision.
The problem isn't rewriting Dalvik in Go or language X,Y,Z.The problem is the APIs used by Google -- and Oracle copyright claims on them.
Furthermore Dalvik supports most languages of the JVM so do you really want to impose a single language in place of Java, Clojure, Kotlin, Scala, Jruby, Jython and many more ? do you think all the programmers using these languages would be happy if forced to migrate to Go ?
Ask yourself that question.
I'd say it's time they dumped that lawnmower and came up with something to replace it.
And who's going to write a Java/Clojure/Scala/Jyton/JRuby/Kotlin/ to Go compiler ? when Google couldn't even write their own language for the android plateform at first place ?
Rich Hickey has complained about the lack of composite value types for instance, and I can imagine that many language creators would love to use green threads based concurrency without actually having to write the low level code for it.
Go is a minimalist language. Many people want more sophisticated type systems and other modern features. So there's a great opportunity for other languages to stand out without having to compete with Go itself. Every time Java adds some functional programming support, the Scala community has to defend its raison d'etre. There would be no such issues with Go and that alone would be a real incentive for language designers to put work into a compiler.
I don't know what you're talking about.
You can use Go to write android apps already so let the people that like other languages already supported by Android do the same. Nobody's going to rewrite Java or Scala in Go. As I said earlier, if Google wanted to do that it would have done that 5 years ago. They are clearly not interested in betting all their mobile strategy on a niche language.
And no, you can not write Android SDK apps entirely in Go today. What you can do is write a library or command line tool and call it from a Java app.