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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
|