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 code
As 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.
Filed Under: apis, copyright, declaring code, java, languages, programming, python, verboseness
Companies: google, oracle
Comments on “How Java's Inherent Verboseness May Mess Up Fair Use For APIs”
I really hope Google starts allowing developers to move away from Java without killing the cross-platform abstraction layer somehow. Maybe Native Client will provide that solution, as I think it’s already used to make Android apps on Chrome OS.
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.
Re: Re:
Killing Java will not kill the root of the problem and Google will know this.
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.
Re: Re:
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.
As long as it’s statically typed…
Serious question:
If Oracle wins case, can IBM sue Oracle for using SQL ?
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.
Re: Serious question:
Lets see here, if Oracle wins any re-implementation of an API would be illegal.
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.
Re: Re: Serious question:
That’s a bit scary when you consider that Ritchie is dead, which means the task of filing such a suit would, of course, fall to his estate…
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.
We deserve it.
Sorry but as a technology worker, I have to completely admit that we created this problem for ourselves.
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.
Re: We deserve it.
“Far to many professionals sign deals with the devil abdicating all of their creative ownership when they get a job.”
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.
Re: Re: We deserve it.
Sad to say that’s often a condition of employment being offered, John. When you’re in a buyer’s market as the seller you have to choose between accepting a bad deal or accepting no deal. I’ve got such a clause in my own contract of employment and I’m only an administrator!
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.
That's it.
Programmers, please use APL in future. Lawyers, please use COBOL in future. Though most patent applications already read like COBOL.
Java "weakness"
Come on. This verbosity has a reason. And while there are people who prefer the duck-typing of python and other scripting languages, it has its drawbacks. Anyone can pass anything to the function. Looking at a more complex code base you never know what objects a function is called with.
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, …
Re: Java "weakness"
There is a reason why Java is widely used for very large projects. And it’s not because of ‘dumb programmers’ (referencing another post here).
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.
Re: Re: Java "weakness"
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.
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.
Re: Re: Re: Java "weakness"
Depending on what you’re trying to accomplish, the lack of strong typing can be an advantage. Especially for a single function to accept multiple types of arguments.
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 3×3 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.)
Re: Re: Re:2 Java "weakness"
Definitely. And I should clarify here that I’m a light coder not an experienced software architect – personally I much prefer working with dynamically typed languages (and most of the coding tasks I do are more suited to that anyway). But I’m also well aware of the strength and necessity of stricter languages for many purposes. I like your example here though, as I’ve definitely enjoyed that kind of thing – for example WordPress (which I work with a fair bit) provides some great dynamic functions for time/date stuff that accept all sorts of formats from full UTC timecodes to plain language statements like “last 7 days”.
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 🙂
Re: Re: Re:3 Java "weakness"
But I’m also well aware of the strength and necessity of stricter languages for many purposes.
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.
Re: Re: Re:4 Java "weakness"
I think you might be surprised at how many developers in the FLOSS world use Vim or Emacs. It’s a bit like writing, a distraction free environment allows concentration on the task at hand, rather than all the flashing lights.
Re: Re: Re:5 Java "weakness"
It’s a bit like writing, a distraction free environment allows concentration on the task at hand, rather than all the flashing lights.
IMO that’s like digging a ditch with a shovel, because you don’t like being distracted by the loud noise of a backhoe.
Re: Re: Re:6 IMO that's like digging a ditch with a shovel
Anybody who likens programming to digging a ditch should … stick to Java and PHP programming.
Re: Re: Re:7 IMO that's like digging a ditch with a shovel
Anybody who likens programming to digging a ditch should … stick to Java and PHP programming.
Perhaps you should do some research on what analogies are (and are not).
Re: Re: Re:8 Perhaps you should do some research on what analogies are (and are not).
Analogies are:
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?
Re: Re: Re:9 Perhaps you should do some research on what analogies are (and are not).
Analogies are:
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.
Re: Re: Re:4 Java "weakness"
“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.”
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.
Re: Re: Re:3 Java "weakness"
Some people prefer editors. Others prefer IDEs.
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.
Re: Re: Re:4 Java "weakness"
Lots of other power tools.
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.
Re: Re: Re:4 Some people prefer editors. Others prefer IDEs
Definition: an IDE imposes a particular build system on you, an editor doesn’t. Example of an IDE: Microsoft Visual Studio. Example of an editor: Emacs. (Note I didn’t say text editor: this is because Emacs can also directly edit binary files.)
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.
Re: Re: Re:5 Some people prefer editors. Others prefer IDEs
That definition might work for you, but it has a lot of holes.
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.
Re: Re: Re:6 combination of an editor with all of the tools that you need to do your development
The term for that is “development environment”, not “IDE”. As in “Linux is a more powerful development environment than Windows”, while “Microsoft Visual Studio is an Integrated, therefore less flexible, Development Environment”.
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.
Re: Re: Re:3 Java "weakness"
Since I’m telling you things about Java, let me mention the JVM.
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.
Re: Re: Re:4 Java "weakness"
Aha – thanks, this actually clarifies a lot. I knew there was a distinction between how Java and languages like C++ are compiled, and that Java had a runtime aspect which is what enables it to move so easily between platforms. But I have always been pretty unclear on what exactly that meant and what the real distinction was 🙂
Re: Re: Re:5 Java "weakness"
(or more accurately, I was unclear on the distinction between Java as a compiled language with a runtime and just a straight-up interpreted scripting language like Python or JavaScript).
Re: Re: Re:2 Java "weakness"
So here’s the python code to do that:
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.
Re: Re: Re:3 Java "weakness"
Of course, in Clojure, which I mentioned above, you could use several alternative techniques. Multi-dispatch methods. Protocols. And then, a CAS might not even be implemented directly in Clojure, but in some type of pattern-rewriting language itself written in Clojure.
And Clojure runs on the JVM.
But working in Java by day pays the bills.
Re: Re: Re:3 So here's the python code to do that
Really?
Re: Java "weakness"
To this and those who are Java fanbois. Try things like OCAML, ML, Haskell, Clean and their ilk. Far less verbosity as compared to Java, C++, COBOL, etc.
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?
Re: Re: Java "weakness"
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?
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.
Re: Re: Re: Java "weakness"
The only time I’ve had to even touch Java professionally was helping my then boss with a post-graduate project he was stuck in. All it took for me to solve problem was look in the index of the Java book the course was using. It took me about 5 minutes to solve his problem.
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.
Re: Re: Re:2 Java "weakness"
Who said Java is used everywhere?
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.
Re: Re: Re:3 Java "weakness"
My response was to the verbosity of Java, the specific languages mentioned use type inference. Compiler infers types without you having to specify all the ugly detail. You only have to get involved when the compiler cannot work it out from the source code at hand.
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.
Re: Re: Re:4 Java "weakness"
Let’s not get started on listing the problems with Java. I’d need far more time and alcohol to get through that list than I currently have available.
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.
Re: Re: Re:4 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).
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.
Re: Re: Re:2 Java "weakness"
“The only time I’ve had to even touch Java professionally was helping my then boss with a post-graduate project he was stuck in.”
You have no idea how lucky you are. I wish I could avoid Java.
Re: Re: Re:3 Java "weakness"
I go through periods of hating Java (often proportional to how much the code is using generics…)
Usually a week or two in C targeting Intel’s offload framework is enough to cure me of Java hate for a while.
It seems quite simple to me: the API is the table of Contents to the book, not the book.
Re: Re:
It seems quite simple to me: the API is the table of Contents to the book, not the book.
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.
Re: Re: Re:
I like that analogy too.
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).
Re: Re: Re:
THAT is the analogy that I kept using for smartphones in the Apple patent thermonuclear wars.
Re: Re: Re:
“An API is like the steering wheel, accelerator, brake, speedometer, gear shift of a car.”
I’ve been using that analog for years; most people even understand it.
Re: Re: Re: Re:
Yeah but this is a typical Audi 4-point steering wheel.
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-1280×782.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!
Re: Re: Re:2 Re:
Google’s Java implementation is a direct clone of Java (without permission). Direct!
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.
Re: Re: Re:2 Re:
Notwithstanding, using trademark to make a point about a copyright case is disingenuous at best.
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?
Re: Re: Re:
That’s the one I usually think of, but then I start wondering what the steering column and shift pattern/layout count as. I know analogies aren’t required or expected to work at all scales, but this is one of those things I can imagine a normal on a jury wondering. I’m also not very good with analogies, much like James Comey isn’t very good with… analogies.
Re: Re: Re:
Hmm, I would if I could patent turning a steering clock wise to turn right and counterclockwise to turn left. Anyone who didn’t want to pay me could just do it the other way around. Profit! Muh ha ha ha!
Re: Re:
More like the table of contents for a recipe book for the same culture. The overall gist of the sections will be the same since the purpose is the same (making food in one case and getting a computer to compute something in the other).
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.
It’s the specification of the interface. It’s not complicated, it explains how to interface with the code. You need to have the same interface (not necessary the variable names though) it if you want to be able to use your code instead of theirs for the same purpose.
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.
There is a reason for this lawsuit
1. Google has money
2. Oracle wants it
3. Profit
A far out solution ...
The judge declares that the next session will be held on the moon. Since the definition of the solution is the same as the solution itself they’d have no problem, and as a bonus we’d get a base on the moon.
Technical vs non-technical
To say this is a problem where the jury is stacked with non-technical peers does not really address the problem.
Oracle and Google are completely technically oriented and still this difference of opinion exists.
Re: Technical vs non-technical
Only because Oracle wants money.
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.
Re: Technical vs non-technical
The difference in opinion is over what Oracle can convince the courts, not necessarily over whether or not Oracle’s case is valid. The way Oracle’s been trying to shift the court case away from any sort of technical details or understanding and trying to deliberately obfuscate the facts of what an API is and does implies that they know they can’t win if they argue their case to an audience that actually understands the concepts involved.
Re: Technical vs non-technical
There is no problem or confusion between Oracle and Google on this, that’s just the ‘apple’ they are trying to sell to a non-technical jury.
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.
Re: Re: Technical vs non-technical
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).
It was the other way around, H-D tried to patent it, and their competitors objected.
The python example would have been less pertinent
It’s hard to see where the Python example makes use of an API call. So, while the Java example is more complex, it does a better job of demonstrating API use.
Re: The python example would have been less pertinent
The standard definition of an ‘API’ is as follows:
“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.
Re: Re: The python example would have been less pertinent
…how can you say that Java defines an API better?
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!
Re: Re: Re: The Java example makes it more clear that an API is being used
Translation: “the Java example makes more of a fuss over using an API, the Python version just gets on with the job”.
Why do you think corporate types prefer Java?
Re: Re: Re:2 The Java example makes it more clear that an API is being used
I wasn’t even aware that corporate types had such a preference, so I will defer judgement until I can verify whether that statement is even true. Care to back up your implied claim?
Re: Re: Re: The python example would have been less pertinent
In Python functions are public by default, except if you prefix the name with an underscore.
Same flexibility, different philosophy.
Re: Re: Re: The python example would have been less pertinent
To add:
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()
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.
A First Draft
class FixBadLaw {
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!” ) }
}}}
I'm no fan of Java
But in all fairness, the Solicitor General of the US would have said the exact same thing if he had been given the Python example. Because both examples have equal signs and parenthesis and variables. And that’s enough for a politician to think it’s “all the same”.
Re: I'm no fan of Java
If it looks like a duck…
Re: Re: I'm no fan of Java
When you are dumb enough, anything with at least one eye and at least one leg looks like a duck 🙂
Whole point of C
The whole point of “C” was to create an API that would have the same language but could run on different hardware with different system level changes. This way you could write a single program and compile it for a Commodore 64, Atari, and IBM. Each implementation of the “C” Compiler would be slightly different because the systems were different enough that you needed to rewrite the back end.
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.
Why are none of the jurors at all programmers. Are they intentionally trying to fuck up this case?
Re: Re:
Yes. Oracle appears to be being deliberately obstructionist because they can’t win on the facts if the facts are clearly understood.
This is where even I—an information scientist with only some very basic programming experience—got confused. If you’d asked me not that long ago to give an example of an API definition, I would have said something like, “There exists a function ‘max’ within the class ‘Math’ that takes two numbers as arguments and returns the larger of the two or, if they are equal, their shared value.” (Plus the grammar for what calling a function looks like and all that.) I wouldn’t have included any actual code in the answer, however unavoidably implied it might be by that definition.
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.
Re: stupid API example
They are trying to keep things simple for a jury, but that’s the problem. In real life, the API is small and the routines are typically large. In their example, the routines are tiny and look just like the API.
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.
Might be the beginning of the end? It sure would save me a load of liquidity. I won’t hold my breath yet though. It is America, and avarice and greed usually win the day.
What an API is
“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.”
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.
So Oracle is throwing the software development community under the bus for the sake of a few dollars? Oracle – as a technical / software company – should know better.
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.
Re: Re:
Re: Re:
I recently listened to an Illumos developer (former Open Solaris) talk about Oracle. It wasn’t pretty…
There's a practical difference?
Maybe it’s because I’m a multi-language programmer, but I really can’t see the 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.
> 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”?
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… ??
Re: Re:
No it’s far worse actually: def max(a,b) isn’t copyrightable by itself but the following collection is:
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)
…
Rather than comparing the API to Oracle’s effort, maybe they can compare the API to the mechanical world.
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.
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.