How Java's Inherent Verboseness May Mess Up Fair Use For APIs
from the this-whole-case-is-fucked-up dept
The latest round of the Oracle/Google API copyright lawsuit has been an attention grabber to say the least. There's plenty of absurdity to go around, but in reading through the coverage and commentary, it became clear that part of the problem is actually in the nature of Java as a statically typed, verbose language. To me, the crux of the case has been in the fact that non-technical people don't seem to get that software and APIs are different things. They don't get that an API is more like a map or a menu, rather than the actual stuff itself. The API is basically just explaining how to get information, not what the information itself actually is.But this distinction is lost on people who aren't very technical. Sarah Jeong, whose coverage of this case on both Twitter and Motherboard has been phenomenal, wrote a great piece last week calling out this distinction:
The problem with Oracle v. Google is that everyone actually affected by the case knows what an API is, but the whole affair is being decided by people who don’t, from the normals in the jury box to the normals at the Supreme Court—which declined to hear the case in 2015, on the advice of the normals at the Solicitor General’s office, who perhaps did not grasp exactly how software works.In fact, during the jury selection process, it appears that an effort was made to make sure no one even remotely technical got onto the jury. So much for a jury of your peers, right?
But, a further point drove home for me just how messed up this whole thing is -- along with the recognition that part of the problem is in just how verbose Java is. Last week, one of the witnesses in the case was a top Android programmer, Dan Bornstein, who was actually asked to write some code on a white board, to show what "declaring code" is, as compared to the actual implementation code. While no photos are allowed in the courtroom, EFF's Parker Higgins (who also has been known to guest post here on occasion), did his best to recreate what Bornstein drew:
Here's my artist's rendition of the Bornstein sketch. Not perfect, but his handwriting and drawing aren't better. pic.twitter.com/aNu8ZAyXMP
— Parker Higgins ☔ (@xor) May 13, 2016
@xor Translated to Python. Usually Java's verboseness just makes code a pain to write; now it may also mess up law. pic.twitter.com/WzOmcyRwyU
— Aviv (@metaviv) May 14, 2016
@sarahjeong @xor Actual side by side version of the Java vs. Python versions for the court whiteboarding pic.twitter.com/Dd58egcaF2
— Aviv (@metaviv) May 14, 2016
Nothing about the declaring code at issue here materially distinguishes it from other computer codeAs we pointed out at the time, this is just wrong. The declaring code explains the interface for communicating with computer code. The implementation is actual computer code. They're not the same. But in Java... they look pretty similar because Java is so verbose, and requires much more detailed declaring code. In the Python version, the differences are much, much clearer, and you can see how the declaring code is basically just a specification for something you want, rather than a bit of creative coding to do something new.
And thus, what we're left with is the fact that, in part because of how Java works, the declaring code looks too much like regular code and that confuses the hell out of basically anyone who's not a programmer. Remember how, in the first version of this trial, Judge William Alsup first had to teach himself Java to understand why an API should not be covered by copyright? Unfortunately, the appeals court justices (and Supreme Court Justices) did no such thing, and couldn't understand the inherent difference here, sending the case back to Judge Alsup's courtroom.
And, now, even with it being "fact" that APIs are covered by copyright in certain cases in the 9th Circuit (hopefully other courts have a chance to fix this at some point soon...), we're still facing the same kind of argument.
Technically, this round for the trial is supposed to focus solely on whether or not Google's use of the Java APIs is "fair use" under copyright law. But that has made for some weird discussions in the trial, because you don't need fair use if there's no copyright in the first place. And since many people involved were operating under the (reasonable!) assumption that there was no copyright in the API, it's made for some weird discussions in the trial, where everyone has to dance around the copyrightability question. In fact, there's been some discussion between the judge and the two companies over whether or not the jury should even be informed about the results of the first case and the subsequent appeals process.
In the end, it's creating a very messy case, and a big part of that mess is because code is confusing to non-techie folks, and Java's inherent design appears to make it even more confusing -- which does not bode well for copyright and APIs going forward. And that could create a really big mess in the software world. Lots of people who dislike Java have claimed for a long time that it is inherently awful, in part because of how verbose it is. But perhaps they didn't realize that factor might wreck some important concepts in software development far beyond just Java programming itself.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: apis, copyright, declaring code, java, languages, programming, python, verboseness
Companies: google, oracle
Reader Comments
Subscribe: RSS
View by: Time | Thread
If they would use that for all mobile devices, too, then Java could be deprecated and some other nice language or languages that are more fun to use, simpler, and more secure.
[ link to this | view in chronology ]
Re:
Java was already a shit platform and is very well known and will likely not go away because of this. Compare that to the fact that Java is a very well known language and has a low barrier of entry and you can see why Oracle is doing what they are doing.
Just because you have a huge community of developers with a skill set and some intelligence does not mean they are somehow smart enough to not shoot themselves in the foot. I have seen more than enough developers that are dumber than a box of rocks but can still give you a competent line of code to accomplish a specific task.
[ link to this | view in chronology ]
Re:
As long as it's statically typed...
[ link to this | view in chronology ]
Serious question:
Implications seem endless ...
IANAL or a Computer Scientist.
But I think Oracle is poisoning a lot of wells here, and it would be nice if one of them was their own.
[ link to this | view in chronology ]
Re: Serious question:
Dennis Ritchie, and Bjarne Stroustrup probably never transferred parts of the C and C++ API copyright to the standards body. Mostly because they, like everyone else, assumed it doesn't exist. A straight reading of an Oracle win is those two could hold almost the entire software world hostage. Almost, everyone uses C and C++. Microsoft, Google, Oracle, the US Government.
I really wish they would too, just to prove the absurdity of such a ruling.
[ link to this | view in chronology ]
Re: Re: Serious question:
[ link to this | view in chronology ]
Re: Re: Serious question:
Oracle HAS ALREADY WON. If you've re-implemented an existing API, you ARE ALREADY INFRINGING that copyright.
If Oracle wins HERE, it will simply make it HARDER for you to USE THE FAIR USE DEFENSE when someone sues you if you become becoming successful enough.
People don't get it: clean room is no longer a defense because of this! IT IS DONE!
Microsoft COULD end WINE and ReactOS and any XNA clone.
Whoever the hell owns UNIX today MIGHT sue any competing implementation (such as BSD, OSX) as they see fit.
Unity Technologies COULD end the myriad of engines that mimic the Unity Engine API.
That wasn't even a possibility until this wretched case in 2012.
[ link to this | view in chronology ]
We deserve it.
Far to many professionals sign deals with the devil abdicating all of their creative ownership when they get a job. I always create exceptions when I have to sign one of these and refuse new employment if they do not agree to allow me ownership of code I develop outside of work.
So regardless of how this case turns out, we have already lost this war. I can only be set right with some form of a technological revolution now and this will no occur until we get rid of the party system because both sides are squarely entrenched with big business.
[ link to this | view in chronology ]
Re: We deserve it.
This is not only true, but to an astonishing degree.
I think that every contract I've been presented with since the mid '90s has included wording that assigned the rights and ownership of everything that I do to the company, regardless of whether or not the company, company resources, or even knowledge I gain during employment is involved.
From the very first time I saw that, I've been striking that language out of the contracts. Only once did an employer object to me doing so -- but we were able to negotiate a perfectly reasonable alternative.
What blows my mind is that almost nobody else ever does this. They just sign the damned things. Astonishing.
[ link to this | view in chronology ]
Re: Re: We deserve it.
I congratulate you on being in a position to negotiate such clauses out of your contract but I fear that many of us aren't in quite so good a situation.
[ link to this | view in chronology ]
That's it.
[ link to this | view in chronology ]
Java "weakness"
I can understand that it's a weakness in this particular situation, but it's hardly a weakness in general. Not to mention that there are many languages that "suffer" from the same weakness - C, C++, C#, Pascal, ...
[ link to this | view in chronology ]
Re: Java "weakness"
It's for Maintainability.
If you change something in Java, which makes it the wrong type to be passed to a function -- then that is a COMPILE TIME error, not a RUN TIME error.
In modern IDEs, these compile time errors show up instantly as you are editing the code. And one change can introduce a gigantic number of errors. For example, change the type of argument to a function, and you may have suddenly created hundreds or thousands of compile time errors in your project. And you can see all those files affected instantly get little red compile error flags next to them almost the instant you make this change in the editor.
That instant reaction is because the IDE has a sophisticated database model of the source code. That editor is not just a simple text editor. Every keystroke is making database changes to the internal representation of the source code model -- which is deeply integrated with the compiler.
Now I'm not knocking dynamically typed languages. I happen to like Python. I happen to especially like Clojure and other Lisps.
But in a large commercial project, I want as many errors as possible to be compile time (which usually means edit time) errors rather than run time errors.
Sure, one might argue that adequate testing can exercise all of the possible code execution paths. But are you sure? Really sure? Willing to stake a very large amount of money on it? What if a new code execution path is introduced later but a test is not introduced to test it?
I would argue that for unit testing, you should consider the compiler as your zero'th line of unit testing, before you run the first unit tests.
I understand the great productivity of dynamic languages for projects of a certain size. There comes a point where it is actually more productive to have strong typing with good tools that can analyze everything.
The argument of having to wait for a compiler is ancient history. The analysis of your code is done on each keystroke.
[ link to this | view in chronology ]
Re: Re: Java "weakness"
Furthermore on that front - there are times when the lack of strictly typed declarations won't even produce a runtime error, but just bizarre and potentially hard-to-track bugs. For example, if you were to use the example python "max" function here with the numbers 2 and 10, but accidentally passed them as strings instead of integers, it would return 2 as the higher "number" and not generate any error at all.
[ link to this | view in chronology ]
Re: Re: Re: Java "weakness"
For example, in a Computer Algebra System (CAS). A function such as "add" accepts a pair of arguments.
If both actual arguments are numbers, then simply add them.
If one argument is a number "5", and the other argument is a symbolic expression (NOT a string!) but an expression such as 'x + y', then the result should be a new expression 'x + y + 5'.
Or I could add two 3x3 matrices together. Or add a scalar such as 5, to a matrix.
(In the case of an expression above, the expression is not a string, but rather a data structure which represents the expression.)
[ link to this | view in chronology ]
Re: Re: Re: Re: Java "weakness"
Sidenote, I did not know what you brought up above about modern IDEs maintaining a database model of the code and doing such rigorous compile-checking as you type. That makes me want to go back and try to learn C++ again :)
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Java "weakness"
True - in particular all the fancy flexibility of the dynamically typed languages has to be resolved somehow into actual machine code that runs.
At some stage in that process the stricter languages are required because https://xkcd.com/568/.
Sidenote, I did not know what you brought up above about modern IDEs maintaining a database model of the code and doing such rigorous compile-checking as you type
Yep - I use Visual Studio - and I can tell you that whilst most Microsoft products have simply got more and more annoying for the last 15 years Visual Studio has actually got better. I guess the free alternatives have too - but I haven't had the opportunity to try them.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Java "weakness"
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Java "weakness"
IMO that's like digging a ditch with a shovel, because you don't like being distracted by the loud noise of a backhoe.
[ link to this | view in chronology ]
Re: IMO that's like digging a ditch with a shovel
[ link to this | view in chronology ]
Re: Re: IMO that's like digging a ditch with a shovel
Perhaps you should do some research on what analogies are (and are not).
[ link to this | view in chronology ]
Re: Perhaps you should do some research on what analogies are (and are not).
Analogies are not:
If you wanted a better analogy, you could have mentioned digging at an archaeological site, rather than a ditch. Then the issue becomes, not quantity of earth moved, but quality. And you will recognize why a big, dumb backhoe is precisely not the kind of tool you want to use. Why, in fact, you might need to go in the opposite direction, down to hand-held trowels and even toothbrushes to exert fine control over your dig.
Is that “analogy” enough for you?
[ link to this | view in chronology ]
Re: Re: Perhaps you should do some research on what analogies are (and are not).
Fallacious.
Misleading.
No, analogies are by nature imperfect, and are misleading if misinterpreted.
Analogies are not:
True.
That depends on your definition of truth. Fiction, for example, is not factual but good fiction contains truths.
If you wanted a better analogy, you could have mentioned digging at an archaeological site, rather than a ditch. Then the issue becomes, not quantity of earth moved, but quality.
My point was about using tools that make the work faster and easier. Your interpretation of the analogy to include the idea that programming is about moving as much stuff around as quickly as possible is a classic example of taking an analogy further than it was intended. I also didn't mean that programming is better if you use diesel power. It's an analogy, not a description.
Is that “analogy” enough for you?
I don't agree with it, because a text editor doesn't give you finer control over your project than an IDE. But it works fine.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Java "weakness"
As someone who has been using VS daily since it became Visual Studio, I disagree with this. It reached its "peak goodness" a number of year ago, and every release ever since has annoyed me more and more.
I now go out of my way to avoid using it as much as I can.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Java "weakness"
IDEs have a learning curve, like any professional tool. Like Photoshop, for example. Or like using power tools in a machine shop. Be careful.
But once learned, a good IDE can be extremely powerful. A common refactoring example: Rename a function using the 'rename' command. First select the function name, and pick Rename. Now as you type in or edit the new name, anywhere on screen that you can see that same identifier (in other files, even!), you will see it renamed live, keystroke by keystroke, as you change the name.
And by "same identifier", I mean that this intelligent rename is NOT done by a stupid search and replace throughout your source code. The database knows precisely and exactly every reference to that identifier in your entire code base, even across other projects that use this class. The rename is universal. If I rename "foobar" to "foobaz", it will not affect other "foobar"'s that are different identifiers, in different context. The compiler knows exactly what is an exact reference to the foobar being renamed.
But here are a couple other quick examples:
In the middle of a big function, select six lines of it. Pick refactor, extract function. Now you have a new top level function with those six lines. At the location where those six lines were, is a call to this new function. But wait! Any local variables that were used in those six lines are passed as parameters to the function.
Pick an embedded class. Select it. Pick a refactoring command to lift to it's own file. All of the necessary editing, and changes are done for you.
Pick an if statement. A simple refactor is to simply reverse the then/else clauses and invert the condition. Lots of other power tools.
Anytime, anywhere, you see a variable, or something, and you want to go to where it is declared, simply click in it and hit F3. You're instantly at the declaration. And I don't mean somewhere that declares a similar identifier with the same name. I mean the ACTUAL declaration of the identifiers you selected -- the compiler know. And the compiler is built into the editor.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Java "weakness"
One of my favorites is selecting an expression and hitting a key combo to assign it to a new local variable. I don't have to know the type of the expression, the IDE will do it for me, and pick a reasonable name.
[ link to this | view in chronology ]
Re: Some people prefer editors. Others prefer IDEs
Item: open-source projects, in particular, use a variety of build systems, particularly ones that work cross-platform. If you want to collaborate on open source, you need an editor that doesn’t tie you to one build system. This is why IDEs just get in your way.
[ link to this | view in chronology ]
Re: Re: Some people prefer editors. Others prefer IDEs
An "Integrated Development Environment" is a combination of an editor with all of the tools that you need to do your development. You know, integrated. Good IDEs let you customise your toolchain based on what you're trying to do; in my experience only very targeted IDEs (such as Visual Studio) force a toolchain (build system) on you.
FWIW, add enough plugins to Emacs and it becomes an IDE.
If you find that IDEs are getting in your way, it may be that you're using the IDE wrong, and that learning how the IDE wants you to alter your workflows may improve your experience. Of course, up to you whether the risk of spending time learning the IDE is likely to be paid back in improved productivity - it doesn't always pay off.
[ link to this | view in chronology ]
Re: combination of an editor with all of the tools that you need to do your development
I don’t need “plugins” to Emacs to do development. I can already use it with all the build systems I regularly come across. And not just for building code, but for generating documentation from markup sources as well.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Java "weakness"
The JVM does garbage collection, and is a managed runtime. Java is one of many source languages that can be compiled to JVM bytecode. Types can be passed back and forth, because the types exist as concrete values to the underlying JVM runtime.
There are 3 compilers that you typically use. The first one is obvious, it compiled Java (or other language) into JVM bytecode. The other two compilers compile JVM bytecode into native code. Well call these compilers C1 and C2.
When you start a program, the JVM begins interpreting your bytecode. Then as dynamic profiling reveals that your method is using a lot of the CPU time, your method gets compiled into native code by C1, which rapidly compiles it into decent machine code. At the same time, your function is put on a list to be compiled later by C2. C2 will spend a lot of time highly optimizing your code. It will aggressively inline.
Now, classes containing bytecode can be dynamically reloaded at runtime.
Suppose YOUR function calls MY function. When your function gets compiled by C2, it has inlined my function into your function's native code for speed.
Now, later, for some reason, I reload a new version of my class, which contains a new version of MY function.
Problem: now YOUR function has inlined a stale version of my function. Not to worry. The JVM instantly de-optimizes your function back to being bytecode interpreted again. And now if your function is still using a lot of CPU time, it will get compiled by C1, and put on a list to later be compiled by C2 when the JVM gets an opportunity. So you will never be running the stale code.
Unlike an Ahead Of Time compiler such as C, or C++, the JVM C2 compiler can globally optimize the entire program that is running in this instance. It has access to ALL of the bytecode which makes up the program.
Imagine what your C compiler could do if it could know about the other code (that you might not write until tomorrow) that it will be linked with. It could reorganize method arguments. Change how methods are called.
Another thing about compiling at the very last moment is that the C2 compiler can use instructions that are ON YOUR PARTICULAR HARDWARE. Does your processor have SSE extensions. Or some other AMD processor extensions?
Yet java code is distributed as JAR files, which contains JVM bytecode and runs on any machine or OS.
Do you need a heap with dozens or HUNDREDS of gigabytes of RAM? Did you know there are multiple vendors of JVM implementations. Call Azul systems for their Zing VM. It can handle HUNDREDS OF GIGABYTES of ram, with GC pause times of about 10 milliseconds. Of course, you'll pay for this. (Disclaimer: I have no relationship with Azul.)
Or you can run your Java code on an IBM zOS mainframe. Etc.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Java "weakness"
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Java "weakness"
[ link to this | view in chronology ]
Re: Re: Re: Re: Java "weakness"
For Java, instead, each if statement takes the form of a new method with different arguments. Or, even better, you would call an add() method on the object you're trying to add something to, so we could halve the number of methods we would need to create. So Numbers have an add() method that takes another Number, Matrices have an add() method for Matrices and another add() method for scalars, etc.
The advantage of the Java way is ease of searchability. If you want to find the method that adds a Matrix to another Matrix, look in the Matrix definition file.
The advantage of the Python way is one-point-of-definition for all 'add' code. If you want to find how a Matrix is added to another Matrix, you open the Add file and find the if statement that pertains to that case.
I personally prefer the Java way, because I do enjoy letting the Compiler catch things and tell me 'Hey you haven't coded that function that you're trying to use. Should probably make it.' rather than finding out when I'm running the program, and I get a run-time error when Python can't find the Matrix-specific adding code and just returns a string representation of them concatenated.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Java "weakness"
And Clojure runs on the JVM.
But working in Java by day pays the bills.
[ link to this | view in chronology ]
Re: So here's the python code to do that
[ link to this | view in chronology ]
Re: Java "weakness"
As to the term "duck-typing", this is applicable only to a section of the dynamic languages.
From my perspective, static typing has its place in the toolbox. It is not the panacea though that many of it proponents. Like all tools, it has its usefulness as well as its problems.
Logic and design irregularities are more insidious and irrespective of compile-time correctness, these are far more difficult to locate. The worst offenders are those "artistes" who like writing "tricky" code without understanding the implications for future support and maintenance.
Most of the tricks used are simply ego-boosted trips and have been created supposedly for efficiency, without all the hard work of actually profiling the code. There is nothing wrong with using various algorithms to solve a problem (thinking outside of the box should be a feature of good programmers), but you had better document what you are doing.
Compilers, IDE's and other tools should be there to enhance the ability of the programmer to get the job done, not straight-jacket them so that it takes more time and effort satisfying pedantic tools that, in the end, are not guaranteed to be correct themselves.
From my perspective, JAVA, C++ and their ilk are the modern versions of COBOL. You can write every program in one of these but do you really want to?
[ link to this | view in chronology ]
Re: Re: Java "weakness"
As mentioned in a reply just above yours, "working in Java by day pays the bills."
I want to sit around designing and playing board games, but I also want to eat. There aren't many places hiring Haskell developers, and typically they require stronger or more specific math skills than I possess. My dabbling in Clojure was a lot of fun, but I've never heard of anyone hiring Clojure developers... or any LISP variant, out in my part of the world at least.
[ link to this | view in chronology ]
Re: Re: Re: Java "weakness"
I have used COBOL in the distance past to write communications programs in the Honeywell DNS/DSA environment.
The use of these other specialised languages appears to be rising in the stock market trading companies and associated fields. I don't know what is being used in the Insurance industry today, but at one time, they were a big user of APL. They may have moved onto using J and K for all I know.
There are many companies still using languages of the Basic variety (no doubt under the influence of usofty). I know of companies using varieties of Pascal. Others still use varieties of COBOL or Fortran.
Java is just another in a long list of programming languages being used, it is not used everywhere, even if used by some large companies and small companies.
[ link to this | view in chronology ]
Re: Re: Re: Re: Java "weakness"
Looking locally, there are FAR more jobs working with PHP than Java, and C#/SharePoint seems to offer more regular work than Java too.
Java happens to offer the highest earning potential for me right now. Some years ago it was C++. Next year it may be Scala. YMMV.
Not sure what relevance any of this has. The comment you responded to was pointing out that strong typing isn't a weakness. Sure, it's not a silver bullet either, but I believe the original point stands, despite your attempt to shift the conversation to a topic of more interest to you.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Java "weakness"
The problem with Java and its ilk is that it is mandatory that you are manually involved with creating all the type specifications for every interaction. The creators of Java did NOT learn these lessons from the past - even though many involved are very smart people (certainly smarter than myself).
The difficulties of translating any language to what can run on the hardware should be taken up in the compiler/interpreter and not be shoved into the face of the programmer. The role of a programmer should be solving a problem domain problem not a solution domain problem.
The JVM has the ability to do a lot of stuff, but the Java language compiler creates a mismatch here and requires you to do various things that other languages that run on the JVM do not require you to do.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Java "weakness"
FWIW, Oak looked to have the makings of an excellent language... but perhaps too ambitious for the time, and release pressures ended up watering the result down into what Java 1.0 was.
A problem nowadays is that there are far too many languages to choose from - many are particularly good at some specific task. Knowing which language is best for the task at hand (and will continue to be for the life of the project) is an NP-hard problem... at best we can determine which languages are appropriate... and hope that the person responsible for the decision actually has the knowledge required to choose.
And at the end of the day, every single language has drawbacks, at least in my experience.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Java "weakness"
Personally I love that all the type information is available to me and reliably correct. Any time I have to use javascript for example I grind my teeth because everything is just objects and I can't tell what I'm dealing with. In Java, when I get something back from a method, I know what it is and what I can do with it. I don't look at it as the language shoving stuff in my face that I have to deal with, but rather providing me with lots of useful information.
[ link to this | view in chronology ]
Re: Re: Re: Re: Java "weakness"
You have no idea how lucky you are. I wish I could avoid Java.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Java "weakness"
Usually a week or two in C targeting Intel's offload framework is enough to cure me of Java hate for a while.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
In court today one of the witnesses gave a pretty good analogy. An API is like the steering wheel, accelerator, brake, speedometer, gear shift of a car. Basically some simple concepts that are more or less the same in every car so that you can get into any car and drive it without learning a whole new system. But then the car itself is very different, and that's the implementation.
[ link to this | view in chronology ]
Re: Re:
I've seen it thrown around a couple of times recently. Most everything in the programming world is an abstracted idea of something in the real world (which is why I personally think patents on software are ridiculous, but that's a completely different can of worms).
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re:
I've been using that analog for years; most people even understand it.
[ link to this | view in chronology ]
Re: Re: Re:
http://images.gtcarlot.com/pictures/38303094.jpg
And this is the trademark Lexus one:
http://media.caranddriver.com/images/13q2/519483/2013-lexus-rx450h-steering-wheel-photo-519547-s -1280x782.jpg
They both do the same thing, but notice how neither one is an exact replica of the other. Imagine Audi put out a car with a Lexus steering wheel.... complete with the brand (the equivalent of *java.lang*...). You can bet they would be sued. The problem with Google's Java clone is that it isn't "inspired" by or derived from Java. It is a straight up clone. I mean, not even the SQL dialects found in MySQL, Oracle, or MS SQL Server are exact clones of each other despite all being based on ANSI-SQL. Google's Java implementation is a direct clone of Java (without permission). *Direct!*
[ link to this | view in chronology ]
Re: Re: Re: Re:
You are confusing interface with implementation. In this context, when you say "Java" it's important to be specific what you're talking about. If you mean the specification, then yes of course it's exactly the same, because otherwise it couldn't work. If you mean the implementation, then no, it is not a clone. Google did not copy any Java implementation code from Oracle, with or without permission.
[ link to this | view in chronology ]
Re: Re: Re: Re:
Nobody is claiming that Oracle has a trademark on the Java API. I'm pretty sure it's not eligible for trademark protection. It's possible that Oracle could hold patents on the implementation of Java, and there's certainly history for patent-encumbered standards... but that was never a point made in the case, so would be irrelevant even if true.
Do you also think that IBM, Microsoft, GNU and others are creating *direct* clones of C99 because they've brazenly copied the interface/specification in their C compilers, despite that they are implemented independently and differently? What about all the LISP dialects? Where does it end?
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re:
The fact that the book is laid out in the same order is just to reduce confusion of those who have cooked before and are familiar with the OTHER cookbook, even though the individual recipes are different.
[ link to this | view in chronology ]
The decision because the decision makers are either not qualified to make the decision or plain old disingenuous not because java is a typed language.
[ link to this | view in chronology ]
There is a reason for this lawsuit
2. Oracle wants it
3. Profit
[ link to this | view in chronology ]
A far out solution ...
[ link to this | view in chronology ]
Technical vs non-technical
Oracle and Google are completely technically oriented and still this difference of opinion exists.
[ link to this | view in chronology ]
Re: Technical vs non-technical
Sun had no problem with Android.
At an earlier point in time, even after acquiring Java, Oracle also had no problem with Android.
The Standard C library has had its API re-implemented many, many times. On many platforms.
So why is it a problem that Apache Harmony re-imiplemented the Java API. That is, used hard work to build a compatible system.
Nobody thought this was a problem until Oracle brought this case. And the case was not about this. But since Oracle couldn't seem to win on any other grounds, this is what they morphed their case into.
I sure do miss Groklaw.
[ link to this | view in chronology ]
Re: Technical vs non-technical
[ link to this | view in chronology ]
Re: Technical vs non-technical
They know full-well what an API is, both of them, and are trying to 'copyright' that which neither have copyright to, or have tried to acquire in any other legal way.
This is no different than an old lawsuit 20-years ago that was rejected, where a Japanese motorcycle company created their first V-Twin engine, and then went forward trying to 'patent' the sound of its exhaust, dragging Harley-Davidson into the mud trying to protect their 'presumed ownership' of V-Twin sound (desired by their almost-monopolistic market). Harley couldn't patent it, nor could the Japanese company, as the final nail in that coffin was that there were just too many 'harmonic variances' between each individual engine to accomplish this task realistically. In the end, you now have a more-open market with better offerings. It also preserved competition that would have otherwise been monopolized.
They KNOW what they are doing.
[ link to this | view in chronology ]
Re: Re: Technical vs non-technical
It was the other way around, H-D tried to patent it, and their competitors objected.
[ link to this | view in chronology ]
The python example would have been less pertinent
[ link to this | view in chronology ]
Re: The python example would have been less pertinent
"Application program interface (API) is a set of routines, protocols, and tools for building software applications. An API specifies how software components should interact and APIs are used when programming graphical user interface (GUI) components."
Translated to lay-speak, it is the 'telegraph' or 'pencil and paper' used to transmit communication between software components.
As the 'API' (technically) for Python (in the example) uses the built in function 'max', while (in the example) the Java shown depicts the user writing code that in-effect, becomes a function (much like in 'C'-language), how can you say that Java defines an API better? The example shows a written-out function, while the given function is native to Python?!
If anything, the article's point of view is well-made, that Python is far less 'verbose' and more native than Python, yet both are capable of accomplishing the same job (albeit, if you really want to write 10 more lines of code to do it with Java).
Your perspective would strip many programming languages of currently built-in functions if you did this! You could then argue that Java is ripping off the 1972 ideology of 'C', and thus defunct Java instantaneously by doing this - as they clearly PLAGIARIZED many of 'C's' functions if this is the case.
See, this is a NASTY can of worms to open, if you go down this path, where you end up with three outdated languages left in the end, wrapped in an API-protected prison that you would never develop further as a result.
[ link to this | view in chronology ]
Re: Re: The python example would have been less pertinent
I'm not sure where you feel I made that claim. I'm comparing the qualities of the code samples, not the qualities of the languages used.
The Java example makes it more clear that an API is being used, as it references the java.lang package, a member class, and a member method. Now, we have a concrete example and use of an API which closely resembles APIs and their use in this case, where the API was written (or owned, if you prefer) by one company, but used by another. If Google had just used their own methods, as in the Python example, there's no case.
Also, if we look at just the declarations for the methods, we're able to get a bit more information from the Java example. Admittedly, much of it isn't pertinent to the matter at hand, such as the 'static' and 'int' keywords. However, the 'public' keyword is important in this context because it is an explicit statement that this method is expected to be used beyond the scope in which it was written. It is not as clear whether or not the Python method is meant to or even if it could be used in any other Python script. Although, having to write my own max method in every script where I need one isn't a pleasant thought, so I feel safe in assuming that Python has a way to achieve this. That's the Python example that should have been used, instead.
Finally, it's not clear to me how my perspective ultimately leads to the end scenario you describe. Could you explain that part a little more, well, verbosely? Thanks!
[ link to this | view in chronology ]
Re: The Java example makes it more clear that an API is being used
Why do you think corporate types prefer Java?
[ link to this | view in chronology ]
Re: Re: The Java example makes it more clear that an API is being used
[ link to this | view in chronology ]
Re: Re: Re: The python example would have been less pertinent
Same flexibility, different philosophy.
[ link to this | view in chronology ]
Re: Re: Re: The python example would have been less pertinent
In Python the package (+module) is formed by the filesystem hierarchy and the name of the file, so you don’t have to spell it explicitly in the defining file. Essentially there’s less duplication of information.
Java:
Filename: java/lang/Math.java
Content: package java.lang
... class Math…
... _ int max…
access via java.lang.Math.max()
Python:
Filename: math.py
Content: def max…
access via math.max()
[ link to this | view in chronology ]
Static vs. dynamic typing has nothing to do with it. There are plenty of statically typed languages that use type inference (automatically figuring out what type you're talking about) to achieve results similar to Python, rather then requiring manifest typing (declaring all types up-front) as Java does.
[ link to this | view in chronology ]
A First Draft
public static void main(String[] args){
int circuit = 1;
boolean copyrightableAPI = true;
while ( circuit < 12 && copyrightableAPI ) {
if ( circuit == 9 ) { System.out.println( "Hello?" ) }
else { if ( copyrightableAPI )
{ copyrightableAPI = Courts.file.lawsuit( Courts.find.districtcourt( circuit ) );
if ( copyrightableAPI )
{ Courts.file.appeal( circuit );
circuit++; }
else { System.out.println( "Hello world!" ) }
}}}
[ link to this | view in chronology ]
I'm no fan of Java
[ link to this | view in chronology ]
Re: I'm no fan of Java
[ link to this | view in chronology ]
Re: Re: I'm no fan of Java
[ link to this | view in chronology ]
Whole point of C
This argument is silly, it needs to be tossed for any number of reasons. The entire field of programming would melt down if Java and even lower level languages were copyright-able. What would happen if the person who created Assembly started going after everyone in the industry after this suit? Everything under the sun at some point gets back to assembly.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
It's a lot more obviously a "procedure, process, system, [or] method of operation" that way, too.
But, as I said, this is where even a well-educated layperson in a related field can get confused.
[ link to this | view in chronology ]
Re: stupid API example
They should have used a real-world example, where the API to something like Swing would have had some small function headers, and the implementation would have been pages.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
What an API is
The map and menu lines are old and tired.
An API is like the front panel of a vending machine, you know that when you push one sequence of buttons, it will deliver you a danish, another sequence you get corn chips.
The code is the mechanism that drops the food, the machine could use screws that turn, a robotic arm, or some weird ass Rube Goldberg machine that ends with a catapult tossing your food to you.
[ link to this | view in chronology ]
The case more or less shows that Oracle isn't a technology company anymore. It's not an innovative company anymore. Faced with irrelevance, it's resorted to the favoured tactic of patent trolls: bogus lawsuits. It's now the copyright troll version of a patent troll.
Congratulations Oracle. I hope you're proud of yourself. You'll be remembered as the company that destroyed everything for the sake of money.
[ link to this | view in chronology ]
Re:
Maybe this org chart comparison will clear things up.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
There's a practical difference?
The "verbose" Java syntax suggests that "public static int max(int a, int b)" is coverable by copyright, while "def max(a,b)" isn't coverable by copyright? Is it the types on the arguments or the method return that makes it eligible, or the "public", or the "static"? Each of those elements is purely functional, and shouldn't be eligible for copyright protection on functional grounds anyway.
If you shorten the words in a book to just abbreviations, or remove definitives, does the book lose eligibility to copyright?
I think copyright in code is a particularly stupid idea, partially because of the problem mentioned above where programmers sign on to assign all of their copyright to their employer (often including work done outside that employment, though I don't know how often that's enforced)... but also because copyright isn't a very good incentive for software to be written.
I have never met anyone who has ever written any code with the goal of owning the copyright on the code. Every single time somebody writes code, in my experience, it has been to solve a problem, for some business purpose. Without the copyright, that business purpose would still exist, and the code would still be written. Companies would be far better placed using trade secret law to protect "their" code than copyright law, IMO. Not that I'm a lawyer.
[ link to this | view in chronology ]
That gets even tricker when you take into account Python's optional type hints; so def max(a,b) isn't copyrightable, but def max(a: int, b: int) -> int is... ??
[ link to this | view in chronology ]
Re:
def max(a,b)
def min(a,b)
def sin(a)
def cos(a)
def sgn(a)
def acos(a)
def asin(a)
def atan(a)
def atan2(a,b)
...
[ link to this | view in chronology ]
In an ARS article, they cited the ".CompareTo(string anotherString) method Declaration. They are arguing over, in programming circles, common-sense declarations.
Android could have renamed it to .Compare2(string anotherString), and possibly avoided this problem. But, that makes the language look cheezy and immature.
I propose, to the legal team, to get a box of screws: a Pentalobe screw, a Phillips screw, a Flathead screw, machine screw, wood screw, etc.
All of these are screws. They might have more specific name, and might have different manufacturers. But, they all turn to fasten, and are somewhat interchangeable. That is all the API is - a generic name for a specific type.
The screw will have properties (left hand or right hand turn, size of the spiral, length, etc)...But, at this point, to trademark the name "screw" seems impossible/improbable (I do read Techdirt often).
And, I see Oracle trying to Trademark the API's - the .CompareTo() name, or the name of the type of Screw.
[ link to this | view in chronology ]
Not 9th circuit precedent
This part of the article is incorrect. The Court of Appeals for the Federal Circuit made the ruling regarding copyright of APIs. The 9th Circuit has not, to the best of my knowledge. Since there was a patent aspect to the original case, the Federal Circuit (which has exclusive jurisdiction at the circuit level for patent appeals) took the appeal and set the precedent. It won't bind the 9th Circuit appeals court at all; it will bind cases that get appealed to the Federal Circuit though, so we might start seeing random patent claims attached to API copyright claims to make sure that the case is under Federal Circuit jurisdiction.
[ link to this | view in chronology ]