Tim Ellison wrote:
Chris Gray wrote:
On Tuesday 09 May 2006 22:03, Etienne Gagnon wrote:
Yes. But only by checking out everything.
I am developing a API "stubs" project, which is a full "stubs"
implementation of the Java 1.5 API. My objective was actually to allow
for not needing an API "implementation" to compile code against the API.
I was planning to use this, among other uses, for compiling SableVM's
luni-kernel implementation.
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!
I disagree -- we spent a good period of time last summer carving up the
class library into modules defined by Java and internal APIs. I believe
it would be detrimental to disregard these boundaries by compiling
against the entire Java APIs, as that would perpetuate the 'spaghetti
code syndrome'.
Aside : there's no harm in a "rt.jar" created from our modules. Are
modules are there for development convenience? it's plausible that
we'll have a monolithic classlib distro as well as the modular one, right?
We could use compile-against stubs, but would also need them for the
org.apache.* packages that comprise our internal APIs, for now I see no
problem with using the actual JARs that we produce.
I guess the question for me, now that I thought about it longer, is
where would we use the separate stub library? I can see us filling in
our blanks w/ stubs for whatever reason (totally fooling JAPI :) and
getting people to flesh those out...
geir
Regards,
Tim
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
