Thus Google's reply brief must therefore
appear any day
now.
According to PACER, Google's brief is due May
23.
--- "When I say something, I put my name next to it." -- Isaac
Jaffe, "Sports Night" [ Reply to This | Parent | # ]
|
Logging an idea that occurred to me some months ago.
On page 56 of
the Oracle brief, they give an example of a method signature involving a lot of
words, apparently to impress the Federal Circuit judges with regard to the
amount of ‘creativity’ inherent in such method
signatures:
public abstract void verify(PublicKey key, String
sigProvider)
throws CertificateException,
NoSuchAlgorithmException,
InvalidKeyException,
NoSuchProviderException,
SignatureException
I wonder whether such legal briefs are written by lawyers with little or no
understanding of the subject matter of their briefs.
Assuming that
Google do not pick up on this in their reply brief and deal with it thoroughly,
an amicus brief might explain the significance and implications of using such a
method signature. I do not program in Java. Nevertheless I understand that
CertificateException etc. are examples of exceptions. Any method
that throws exceptions must declare the exceptions that it throws. Moreover any
Java program that calls the method (in order to verify a cryptographic key) is
required either to ‘catch’ these declared exceptions, or else the
calling method must declare that it throws the exceptions that it doesn't catch.
Thus the list of exceptions is functional and necessary for interoperability.
If one wrote application code that called the Java class, and caught the
exceptions declared above, and if one wished to write a replacement for the Java
class for some other virtual machine, but written in the Java language,
and implementing the same requirements with regard to catching and throwing
exceptions, then the replacement code must also throw the exceptions that share
the same names. The only genuine variability would be in the precise
order in which the exceptions were declared. (One might, for example, list
InvalidKeyException before CertificateException.)
The
sequence of words ‘public abstract void’, in that order, is
functional, not expressive. And given that the applications program is going to
make use of a PublicKey class, any interoperable replacement is required to
accept a first argument belonging to a class called PublicKey.
These are
the requirements of the Java language that make most of the features of the
method signature quoted above functional, not expressive.
Of course
programmers could express and explain the above far better than I could. [ Reply to This | Parent | # ]
|