> It's hard to imagine any particular reason why a function would need to have "java" in its name in order correctly calculate the maximum of two numbers.
That's not the full scope of it's function, at least in a technical sense. It's also meant to be a utility system-level method and in Java standard library utility methods follow a certain organizational scheme so as to designate their system-level status. This status implies certain aspects of behavior not codified in the API name. Therefore this sort of organizational scheme can be argued to be of necessity and not merely an arbitrary design decision.
I think the common gap in many comments here (not necessarily yours, but in sibling postings of your original reply to me) is of an understanding between engineers that mostly use APIs and ones that write them. I'm in the latter category, so my perspective differs. APIs do have explicit contracts that are reflected in their parameters, names, etc. They also have an implicit contract, equally critical to their actual functionality, which needs to be accounted for when in use. Many aspects of organization, etc are firmly in this category and I believe no experienced API author can credibly argue otherwise. Thus behavior like this
> a set of automated UI tests written against TurboTax would also work with H&R Block's app
is of necessity to a properly functional API satisfying an implied API contract. A better example would be H&R Block and TurboTax disputing their workflow for a particular tax form because the workflow is a commonly practiced one by accounting professionals. The software workflow codifies an existing practice. By the Baker standard that appears to me not to be a copyrightable item. API code, in my view, is not dissimilar.
Judge Thomas had an interesting exchange re football playbooks with one of the lawyers. In his example, wouldn't it make more sense to state that the proper protection for a football playbook and its associated techniques to be a patent and not a copyright? The truly valuable creativity is embedded in the practice of football tactics and not in the markings of a manual.
>That's not the full scope of it's function, at least in a technical sense. It's also meant to be a utility system-level method and in Java standard library utility methods follow a certain organizational scheme so as to designate their system-level status. This status implies certain aspects of behavior not codified in the API name. Therefore this sort of organizational scheme can be argued to be of necessity and not merely an arbitrary design decision.
I think the key word in your argument is 'implies' and you didn't use the word 'requires'. If the authors of the API are implying the nature of these sets of functions by organizing them under 'system', they are doing so to convey information and an opinion as to the nature of the function. The fact that java.system.out is STDOUT, could be also put into java.io or java.system.unix.out, java.logging.out etc. The 'system' is arbitrary, its not 'required'. For example, the out function does not inspect its package name to determine that this out file outputs to STDERR.
> I think the key word in your argument is 'implies' and you didn't use the word 'requires'.
You can make this same argument for the function name or the parameter names. Nothing about the implementation of the max function requires it be named max to work, it just needs to link to a function pointer or some equivalent construct that acts in a way as defined by a specification for what max should do. A name like max is helpful for use though. So is arranging max, min, and other standard math functions in the same module. Treating method names as different from other forms of organization is inconsistent. They are all forms of organization.
You've also raise some points re interoperability, but I'm not really arguing about that. My own argument is more of a conceptual one based on the difference between an API and an API contract as well as on the role a system specification plays in API design & use. You could probably extend this concept to the interoperability question and I see no reason why it won't make sense, but that's not what I'm doing here.
That's not the full scope of it's function, at least in a technical sense. It's also meant to be a utility system-level method and in Java standard library utility methods follow a certain organizational scheme so as to designate their system-level status. This status implies certain aspects of behavior not codified in the API name. Therefore this sort of organizational scheme can be argued to be of necessity and not merely an arbitrary design decision.
I think the common gap in many comments here (not necessarily yours, but in sibling postings of your original reply to me) is of an understanding between engineers that mostly use APIs and ones that write them. I'm in the latter category, so my perspective differs. APIs do have explicit contracts that are reflected in their parameters, names, etc. They also have an implicit contract, equally critical to their actual functionality, which needs to be accounted for when in use. Many aspects of organization, etc are firmly in this category and I believe no experienced API author can credibly argue otherwise. Thus behavior like this
> a set of automated UI tests written against TurboTax would also work with H&R Block's app
is of necessity to a properly functional API satisfying an implied API contract. A better example would be H&R Block and TurboTax disputing their workflow for a particular tax form because the workflow is a commonly practiced one by accounting professionals. The software workflow codifies an existing practice. By the Baker standard that appears to me not to be a copyrightable item. API code, in my view, is not dissimilar.
Judge Thomas had an interesting exchange re football playbooks with one of the lawyers. In his example, wouldn't it make more sense to state that the proper protection for a football playbook and its associated techniques to be a patent and not a copyright? The truly valuable creativity is embedded in the practice of football tactics and not in the markings of a manual.