Geir scripsit: > > For what my opinion is worth (on a good day, a cup of coffee, but not at > > Caffè Florian), this would be an excellent thing to have. It will never > > be easy to work on the core Java APIs in a totally modular way (because > > Sun didn't design things that way), but with such a set of stubs one > > could at least work on a group of classes in isolation and be able to > > compile them to bytecode. Furthermore the stubs can readily be used for > > white-box testing during development, by simply adding println()s. Go for > > it! > > 1) I wonder if we could just add those println's w/ AOP since we're > fundamentally lazy.
I imagined that these println's would be ad-hoc and ephemeral, a step along the way to producing other deliverables (the class libraries themselves, and the various kinds of test that have already been discussed here). If you're developing method M of class C and your implementation invokes method M' of class C', you sometimes want to have a M' which just prints out "hello, I've been called with inputs foo, bar and baz" and/or returns some prearranged result; but I don't think you'd want the stub method to have this feature built-in for every conceivable invocation. Not unless you embark on an ambitious reflection-based framework with scripting capabilities, which of course could be huge fun in itself. :) > 2) Could we mechanically create the stubs, rather than having a parallel > source tree? One might argue that you could generate such a stub by > transforming the spec javadoc to code.... no muss, no fuss, and darn > quick... This is not such a daft idea. If it's not literally possible (and Etienne can mostly likely tell us why not), then it should still be possible to perform extensive automatic automatic checking of the stubs using japitools or similar. Chris -- Chris Gray /k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
