$10bn Oracle v Google copyright jury verdict: Google wins, Java APIs in Android are Fair Use Google has won the latest round in its long-running battle with Oracle over the use of Java class library APIs in Android. A San Francisco jury today found that Google's reuse of Java's core software interfaces in its own mobile operating system should be considered fair use – meaning Google can avoid paying royalties to …
A few days ago I took a look at a Cisco ACS appliance that started to refuse any http connection to the web interface and I was disgusted to see several logs where the Java server vomited all kind of cryptic messages about stuff.stuff.stuff.stuff() in... with no meaning to a non-developer. Java deserves to die a quick death for its total disregard for what we sysadmins consider a minimal decency, meaningful error messages. I don't give a crap on the trace listing classes I'm not interested in, just tell me what didn't work. And this is no exception, Nagios Log Server did this to me too recently.
As a developer and sometime sysadmin, bullshit.
Without the source, a cryptic class.class.class link to a function call ina language you have no need of knowing is as useful as a chocolate teapot.
Be nice to the sysadmins, they keep your platforms running.
Actually, unhandled exceptions seem to be the problem here. The stack trace in this case might be the only means of this user to get support from Cisco TAC in resolving the issue.
This case in my opinion is that :
1) The sysadmin has a point but doesn't know what his point is and therefore is not well suited for problem solving. He's the type that simply asks the wrong question due to lack of knowledge. Instead of learning more about what stack traces are and finding the right thing to complain about, he's simply picking the first thing he doesn't understand and focusing his hate at Java unfairly
2) Cisco as always has done a shit job on writing code. I can see a mom and pop operation or open source project dumping a stack trace without an exception handler. But Cisco should have enough developer resources to not only implement program flow, but also implement error management even if it's just a top level exception handler for 'Unknown exception'.
3) Cisco ACS is an old product that only receives update begrudgingly. It was written during the dark era of Cisco which means their products were meant to be used but never seen by anyone. Cisco has a long an glorious history of absolutely disgusting user interfaces. They're getting a little better.
4) This won't be a big problem in the future. Cisco has more or less moved to Python. Cisco does programming languages like a flake does religions. Java used to be king... now Python. The marketing and management at Cisco know even less about what an API is than Oracle's lawyers. Believe it or not, all new Cisco courses this past year have at least one slide making a huge deal about what a northbound and a southbound API is. They also all seem to try and fit a plug on programming Python in. So... without exception, Cisco HAS NEVER made a single point as to why someone would need an API, but instead makes a huge point out of making incredibly bad scripts that do absolutely nothing in a programming language that is not particularly well suited for calling the APIs as opposed to implementing them. You should see the shitload of new information on "YANG" which must be the most insanely lazy and somewhat sloppy approach to API development in history.
Java is a perfectly ok language... it's not particularly good as a runtime environment anymore. JVM could use a massive update and Google did a little with that in Dalvik. Sadly, there are no good and modern extensions to Java regarding things like assisted auto-vectorization... or things like OpenMP style multithreading assistance. Their libraries are impressively bad for things like threading in general. There are far too many conflicting models in Java for multitasking programming. Due to REALLY REALLY bad GUI support in Java, there's no decent runtime for handling calls to the UI thread. Microsoft "solved this" in C# by building a serialized delegate mechanism which doesn't suck... too badly. Even better was the Task<> structures attached to the language async mechanisms. Java has sort of died in this place. There are solutions, but you can't find which one to use or how to intermix them when needed.
After this case, Google should probably make a replacement for Java which operates on the Java class libraries but fork them substantially enough that they can extend and improve the language as much as possible
Software I wrote trapped the exceptions and logged a meaningful error message along with the stack trace. Shoot the developer not the language. Next to security, error handling is the most neglected part of software development. Not that they ever produced a stack trace of course :)
I can remember working with versions of AIX that seemed to specialise in producing short, cryptic and undocumented messages like "Your dorkle has snarfed". At one point I began to wonder if it wasn't all part of some clever game, where if I collected the messages and re-arranged correctly them I'd win a huge prize.
"Next to security, error handling is the most neglected part of software development. "
The sentiment is admirable, but as stack trace avoidance advice it is thoroughly useless. Apparently one of the unwritten rules of the Universe is that if you take pains to trap and handle exceptions in all the ten places they can occur, they will only ever happen in the eleventh place that nobody even imagined could generate exceptions...
@Steve Crook - "At one point I began to wonder if it wasn't all part of some clever game, where if I collected the messages and re-arranged correctly them I'd win a huge prize."
I did, and the acronym from all the messages was the location and license key to a shiny new AS/400 that didn't run AIX. :)
Meaningful error messages are the responsibility of the coder of the software, not the language used?! The developer should put something that makes sense in the 'Exception e' before passing it on. That way, something comes out that makes sense. The stack trace is actually really helpful as well, if you know what you're looking at. ;)
> Meaningful error messages are the responsibility of the coder of the software, not the language used?!
But the default of dumping out all this programmer shit on poor unsuspecting customers web browsers screens is just plain dumb. Not only does it confuse the shit of them it probably gives hackers way too much information about how bad your programmers are and where holes they will be able to exploit are.
@Anonymous Coward
"stuff.stuff.stuff.stuff()"
I wish this server would give me a lot less information about what's going wrong. I love Googling "" to see if anyone else has had this error in this situation, Googling "stuff.stuff.stuff.stuff()" let's me find the answer right away, and I'm an Oracle consultant paid £250 an hour.
Instead of blaming the tool (Java) I think you should try directing your rage at the developer - Cisco. They may be fine at producing routers, switches and the like, but the (non-embedded) software they write is almost universally crap!
Why the downvotes for @tekHedd? He/she is right - Java is very popular for server apps, and not a half bad choice for that matter.
Unfortunately most folks who complain about Java are conflating it with the crappy desktop JRE from Oracle, which incidentally isn't even the reference implementation.
Java a "niche language"?
That's like saying transport vans are "rather obscure".
Also:
Google wins Oracle v. Google. Big victory for fair use.
Ummm ... no . This is not about "fair use" of someone's "intellectual property" (scare quotes intended), it's about someone inventing a whole new type of "intellectual property" so that he can homestead it for a quick buck, which is more like conquistador expedition.
Seems to be the going thing in Silly Valley anymore, IP trolls and locusts. It's just another case of 'orrible doing what they do best (M$ probably does this too), claim rights to others' innovations. Still true as I wrote when Larry bought Lanai, and when he tried to sue the socks off of SAP:
Larry, Larry, quite contrary,
How does your empire grow?
With IP “rights” and patent fights,
and lawyers all in a row.
Java on the server is pretty good - CLI + socket - Great.
Its the rest of the garbage that comes lumbered with Java and the problem that so many poeple and companies have been burned by Java incompatibilities and securities snafus in the past make Java a very hard sell these days.
Java's problem has and always - wheres the revenue model to maintain it?
Second Java? Ohh, we already have it, that's Java script isn't it?
I know it is an old article but seeing some of the stuff written here. Having eyed Java in past as a possible development platform for new devices, I must say, from what I have read, it does seem to be in need of a major overhaul to strip out grabage and redo things with old java programs put in a comparability mode. It comes a time in certain development, to absndone the old and make something new (running the old through a comparability mode). This means also redoing the language and API's into something better, which is not Java. Java scripting to webassembly with desktop API support, is something simpler to use, but I don't think it is anywhere near what needs to replace Java. But Java had a whole infrastructure around it, including a phone API set eventually, that didn't take off. A lot of stuff to chuck away, or a lot of stuff to pick from as API structures to rework for a new language.
BTW, it's not Android, though android attempts to implement through it's linux core what should have always been in Java.
"Java would have died ages ago if it weren't for android."
Err.. no it wouldn't. Java has always has been mostly used as a server side development language. Don't know where you are getting your information, but that side of Java use there is still healthy and shows no signs of diminishing.
Is that you Larry? Go back to your Hawaiian island and leave the computer industry. You are no longer relevant. Be happy the justice department or SEC doesn't come sniffing around your hidey-hole wondering how you bully competition and thwart innovation by purchasing more relevant companies. You got to the top of the pile just like Nintendo once did; by playing every single dirty trick in the book that is still consider legal. The power of Big Red is slipping, and it slipped a bit more today. There are too many smaller, more nimble players, in your space and that is concerning. It is most concerning to those remaining.
We use ORACLE here, but at the end of all things. The middle tier is laden with open sores DBs of the MySQL variety. Another red player, but still mostly useful and freely available.
If you're not aware, the acronym ORACLE stands for; One Raging Asshole Called Larry Ellison.
> Is that you Larry? Go back to your Hawaiian island and leave the computer industry. You are no longer relevant.
But if Larry had won, he wouldn't own a "Hawaiian island" or even a pedallo for very long. If Oracle had proved that you can claim royalties on the usage of an API, Oracle would have to give every cent's they've ever acquired to IBM.
If they'd have won this, lawyers would have sensed a payday.
"yes, this function, it takes a string, for example, "Hello World" and it prints it to the screen! We have the copyright on that!"
There'd not be a single api/function/method of coding that wouldn't have been torn apart, only to have RMS in the corner probing orifices going "I told you!"
Google is a REALLY REALLY scary company these days. There are endless numbers of ethical issues with Google... far too many to count. This is a case where they actually are doing something good instead of unintentionally evil. Others have covered the API things... I'll dig into some others.
1) Cartography.... we are so insanely dependent on Google maps these days that if Google shut them off, there would be airplanes completely lost.
2) Search... they're the only company which understands that people want search results that actually give what they're looking for. As a result, they mine data no matter how unethical that data mining is in order to establish a search result listing that prioritizes what you mean instead of what you say. As such, Google watches absolutely everything you do and makes it a secret as long as it can because they don't even want you knowing.
3) Broadband... Google already carries insane amounts of data worldwide. In addition to being what may be the biggest or second biggest tier-1 service provider at the moment, they're running fiber to data centers and to the home and supplying predatory pricing to get you to switch. Their prices are so low the packages so good that no business with responsibility to it's shareholders can justify not switching. If Google shut down their transport network, the Internet would actually break.
4) DNS servers... by this time, changes are you or your ISP, your ISP's ISP, etc... are using Google's DNS servers. As such, Google is tracking absolutely everything everyone does whether they use Google or not.
5) Google car... Google will probably give away 90% of all their self driving technology to as many vendors as possible to ensure as much guaranteed information tracking as possible in exchange.
6) Google Docs... if you start using them and you really use them... you're locked in... you can't move them back home again. OpenOffice/LibreOffice etc... suck terribly and there's far more to Docs than just what's compatible and open. An open file format doesn't mean every program which implements it implements every feature. It's pretty much guaranteed lock in once you start.
7) Google Mail... awesome service most of us couldn't live without. But Google doesn't give this service away for free out of the goodness of their hearts... tracking tracking tracking.
I can keep going for a LONG WHILE!!!
Google is basically big brother. For the moment, Google is run by a group of people who seem to be someone with good intentions. So long as the company grows and turns a profit, this will stay like this. Once the stock stagnates etc... the board will step in an replace CEOs with shareholder representatives with no interest in the customers themselves. Things like selling your tracking information to others will sound like a good and profitable idea.
What's worse is, Google's too big to fail now. It makes absolutely no difference what Google does. We honestly can't manage in 2016/2017 without dependence on them. There's no alternatives and no replacements and if Google went bye bye and just shut off all their toys... there wouldn't be much left of the Internet. It would be far more devastating than when Infoseek changed their search engine back around 1995 and we couldn't find ANYTHING anymore. There are major systems around the world which simply will stop working of Google shuts down.
That's good news. The original judge had it right, fair use should apply to published APIs.
If there was a transfer of copyright material (copying of code behind the APIs) then Google should get skinned for that.
But if re-implementing APIs was to be considered a copyright violation it would either be the death or the salvation of the software development game. I say salvation, because then the risk of lock-in would be a very compelling reason for the use of open standards and easy to argue for at a corporate level.
What really grates is Oracle's attempts at retrospective lock-in. A real confidence-killer.
> Some copy of code was also involved
My understanding is that the original author of the initial implementation wrote much the same code in a re-implementation. It was just a few lines of code. The judge stated that it was an obvious block of code and thus was not copyrightable.
It was for rangeCheck. Out of the whole a Java, Oracle wanted billions just for rangeCheck. The judge reminded Oracle's lawyer that an expert witness had said a high school student could right it, and the judge is a programmer and had written similar code hundreds of times himself.
Oracle's lawyer boasted that he would not be able to implement rangeCheck in 6 months. As the lawyer (Boies) couldn't win a legal argument with a gardener, his claimed ineptitude at programming is actually credible. Multiply that by the hourly rate he gets for cases not related to SCO, and you still do not get to 9 billion. (Yes, it is the same David Boies who committed BS&F into representing SCO against IBM for a share in the profits.)
Of course it can and was argued that the copied code was not significant. It was 9 lines of code that just checked whether either index was below zero or above the maximum size of an array.
It wasn't special or elegant code, just functionary and exactly what would be written by any number of people
Se here for the details: Google’s 9 lines
Agreed but... the code copied was a published API in the sense that it was open source at the time.
What makes this a problem is that so far as I know, the Java APIs are not published as header and source but instead as a simple Java file. I don't recall universal interface definitions being kept intentionally separate from the code which implements the API. So, while a script could easily extract 99% of the API from a .JAR file with no assistance, to get the whole thing probably required extracting it from code.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
