For me this just puts into perspective how much it sucks to have Java as the language powering Android. Would a rewrite in (say) Go even be possible? I guess you could machine translate a lot of boring stuff like support for a gazillion devices, and the memory footprint savings would be quite substantial.
Oracle tried their hand with copyright infringement, because copyright is far stronger than anything else that's IP-related. However, here's the thing:
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.
> 1. Oracle is basically arguing about APIs being copyrightable and if APIs are deemed to be copyrightable, we're fucked as an industry ;-)
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.
parent thinks the industry will flee to safer European shores, because the local legal climate is much more liberal than the US when it comes to software (for example, patent trolls are very rare over here).
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".
It's not just unlikely, it's completely nonsensical from a legal perspective. If Google's Android division were located in Europe, that would make zero difference for their legal fight against Oracle.
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.
That would be the case except if you where a US software company fleeing a legislative climate that made it hard to do business are you going to put your HQ/major business units in Berlin/Paris or a third-world country.
These are large primarily sales driven organizations so first world transport links and infrastructure matter.
I always think is is somewhat interesting given the Java trap [1]. In some ways RMS was very prescient (not entirely surprising), but had Sun not released Java under the GPL, we could easily be having this discussion about IceTea.
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
APIs are pretty much confirmed to be copyrightable, as far as I can tell. The SC denying cert to review this appeal essentially confirms the Federal Circuit's interpretation. All that is left is to decide on fair use, which could still let Google off, but that defense assumes copyrightability.
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.
As far as I've been able to tell, the Federal Circuit's decision sets no precedent. It is only binding on the trial court in this particular case.
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.
Yes but Android's policy is avoid GPL whenever possible, which is why they rewrote their own Dm-crypt mod and other standard tools also Oracle already tried and failed to sue over Android http://www.infoworld.com/article/2615512/java/open-source-ja... (2012 article)
It's not just Android. Google is a massive Java shop and a lot of their stuff is written in it. They have plenty of Java expertise in all areas.
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 ?
They probably wouldn't but then again, they're taunting the lawnmower (mentioned above) and seem to forget that the lawnmower has a lot of money and willpower.
I'd say it's time they dumped that lawnmower and came up with something to replace it.
They also had the money to buy Sun Microsystems , they didn't. They had the money to use something else than Java on Android , they didn't. They're not going to move to Go, they'll just pay and make a deal if Oracle wins.
Is it really more difficult to compile to Go source code than to Dalvik/ART byte code? Using Go as a compilation target would allow other languages to benefit from structured value types and goroutines.
> Is it really more difficult to compile to Go source code
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 ?
If a platform is popular, language creators will want their languages to run on it, especially if that platform solves some of the problems the old platform has (like excessive memory consumption in the case of Java).
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.
> 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.
Main issue is making people move away from one language to another. You'd have to let people use their existing code base with the new language (like apple did with swift). Could it be possible without another similar lawsuit?
Call them "legacy apps" and run them over a compatibility layer. Hardware will gradually get good enough to run the old Java apps without hiccups, and the apps that get translated to Go will run about as fast as the Java-Android versions [citation needed], but with oodles of memory to spare.
I would go one step further and look for {spam_words} in "username+{text}@{googledomain}.com", where spam_words can be "junk", "spam", etc. This is like a very narrow edge case, but still might catch something. Again, if you're into that kind of thing; I'm quite skeptical that it brings any value.
That's not at all what I meant. Gmail redirects emails to "youremail+whateveryouwanthere@gmail.com" to "youremail@gmail.com". Some people filter emails this way, henceforth my suggestion to check for this edge case.
I'm not entirely skeptical of how ethical their exploitation will be conducted, I'm just raising the point that we're a country with heavily affected (ex-)forests. Moreover, there's a rich recent history of external interests being facilitated by our ultra-corrupt government, to rather devastating effects.
Location: Cologne, Germany
Remote: Yes
Willing to relocate: Western Europe or Romania
Technologies: Go, Python, JavaScript, C, C++, Java, C#
Résumé/CV: Google Drive [0]
I work as the CTO of Lavaboom - we make secure email, using a mostly Go/JS stack, powered by RethinkDB and Docker. We're entirely open source [1]. Having got quite close to a "1.0" with Lavaboom, I'm looking for the next challenge.
Trivia: I've been programming for 10 years, in at least 10 different languages; I like building dev tools, privacy-friendly stuff, emacs, algorithms and data structures, compilers, linux and different BSDs, etc. If you'd like to chat I'm on #lavaboom (it's linked to our #public channel on Slack), or you can hit me up via email/Hangouts - see my Github profile [2].
edit: I also maintain this rather popular repo of coding interview resources [3] (long due for an update).
IMHO if you need to break down a task well enough to run on a supercomputer, there isn't a lot more to do to make it run on a regular server farm.
edit: Actually, in the scenarios you'd use a supercomputer for, the added latency and overhead (shoddy servers, network, etc.) would most likely make the run time orders of magnitude higher.
Maybe for embarrassingly parallel tasks, but if you require nontrivial interprocess communication, a server farm can't compete with the interconnect of a modern supercomputer.
And by "codes", you mean specific legacy software artifacts written in FORTRAN (note that I'm not even spelling it as Fortran)? Of course that's a problem.
No, that means specific problem domains that are not easily partitioned, and where latency or affinity are the primary performance constraints.
There are still some fortran libraries in large scale use for this sort of thing. They are still in use because they are very good, and replacing them would be very expensive for little gain.
Write in any language you want; that's irrelevant to the nature of the computations being done here.
By codes they mean -- at the minimum -- pretty much anything that requires frequent communication between any or all nodes as a necessary part of computation. (For example, simulations across a large 3D space, where the changing states of particles on node A directly impacts the states of particles on adjacent nodes.)
You can't write your code in any language you want on a supercomputer.
Also, there is a wide range of literature about communication patterns for supercomputer apps; my argument is that often times, to solve the problem that matters, you may not actually need to run the simulation you think you do. It's more that people are just used to running that way.
For example, with MD, you can run 1 sim parallelized over 100 machines using tightly coupled communication (doesn't necessarily mean the forces and positions of every particle have to be shared between node decompositions) or run 100 sims over 100 machines, with no communication except for input and output files. The latter can often answer the same question far more cheaply.
No, the people who run the clusters won't let you run any language just because it has an MPI binding. They invest a lot in ensuring peak performance, and right now, only C++ and FORTRAN can achieve that. Very few, if any, major supercomputer centers support Java codes.
Oh, you're talking about a policy limitation, not a technological one. (And if you're talking about the DOE or NSF/Teragrid/XSEDE clusters, then you're probably right. Haven't touched those in years -- and even when I did, I wasn't doing anything crazy.)
To be frank, if I was running a computer that was designed for peak performance, I probably wouldn't use Java. There are some very significant performance issues with garbage collection that prevent you from making peak use of them machine.
Supercomputers aren't built so that people can squander the resource (desktop PCs, closest clusters, and phones fulfill that role).
It is a technical limitation. Oftentimes the platform is so specialized that only a tiny handful of compilers are ported to it. Say, just gcc, g++, and gfortran, and xlc, xlC, and xlf. And just one version at that. Java would require porting the JVM to the cut-down, weird Linux on the compute nodes. Some $$$ machines don't even support dynamic linking! The number of these machines is so small that extensive compiler and tool support just isn't happening unless you want to add millions to the cost.
The JVM probably calls fork() and system(), no? Not allowed. Dynamic thread creation? Not allowed. And 50% of your flops go away unless your program uses the BG/Q-specific "double hummer" floating point instructions. These are primitive machines, in terms of development environment and typically require significant rewriting to get even "standard" system software working.
PARC syndrome should definitely be a thing if it isn't already.
That said I think it only covers a subset of what went wrong at Nokia, and that was only the first half, before a whole different set of things went wrong under Elop
