Earlier quoted context omitted.
Because the actual implementation isn't what the courts are looking for. This is a case about Google's intention for copying the Java API. Oracle is claiming that Google copied their API because it was easier than designing a new language; Google is claiming that they did it for interoperability reasons. There is no distinction between the two because these things are presented as evidence of Google's intent, it's no…
Thanks, that's interesting! It seems reasonable—if Google was explicitly trying to enable compatibility, that should be allowed, whereas if they were just trying to save a buck, that should be illegal. Of course, in reality Google's decision was probably a little of both, right? They selected a technology based on a wide range of factors, including development costs and compatibility. I'm still concerned that a decis…
I wouldn't think that Google's development costs were part of the decision. There aren't that many Java APIs -- as the article says, it's ~11k lines of definitions -- so Oracle is seeking ~$818k per line. Assuming Google's lawyers predicted that there was some risk of a lawsuit like this, any engineering costs associated with redesigning the APIs would just be negligible compared to the legal risk.
One could argue that it is quite difficult to design a good API, but Java's APIs are frankly full of mistakes: Date/Calendar, immutable collections with no type safety, "optional" methods like Iterator.remove, etc. It wouldn't take a team of world-class engineers to come up with something better with the benefit of hindsight.
On the other hand, developer familiarity and compatibility with existing Java libraries could have had a significant impact on Android's adoption. I think that was what justified the legal risks.