Of course, you /could/ use a proxy-based decorator which could certainly handle all of these requirements, but then you need to change your code to use the decorator rather than the underlying object. It would be trivial to create a way of associating objects and methods with said decorator.

But… that sucks. Java doesn’t allow you to easily and /transparently/ manipulate itself to get what you want without resorting to such treachery or, even worse, direct byte-code manipulation.

“In light of this requirement, Java is not expressive enough to cleanly implement a solution.”
Huh?
Is there something about Java that prevents use of SOAP faults? (It’s really hard to understand what you mean by such an unspecific claim.)

Your point was that Java doesn’t allow you to refactor code the way you would refactor code in Smalltalk. That’s true - Java doesn’t allow you to refactor code the way you would in Smalltalk.
Smalltalk idioms might not translate to Java.

The specific example you choose to make that point with seems to have been based on the belief that exceptions couldn’t/shouldn’t/wouldn’t propagate from SOAP server to SOAP client. afaict that was a mistaken belief - was it a misunderstanding?

“non-falsifiable statements”
On the contrary these statements are falsifiable
- client programs will need to handle SOAP faults
- returning error values forces clients to use 2 separate mechanisms, one to handle SOAP faults and one to handle application error values; and we can avoid that duplication in the many client programs by signalling application errors with SOAP faults
- if (!authenticate(key)) demonstrates that Java is expressive enough to allow you to ignore the normal way of dealing with error conditions

Are these claims you make against me falsifiable?
“You shift the burden to the programmer… you shift it to his customers… while refusing to see anything wrong with Java.”