Bug#227587: [PROPOSAL] Java library dependencies
> > * j2/1-runtime does not garantee anything *at runtime*, so it is
>
> Right. That's exaclty the reason why I'd like to see them removed for
> library packages. But I guess I have already told this... :)
And this is my core problem with your proposal. You want to remove
j2/1-runtime, but you offer nothing whatsoever to replace it.
Sure, the current system has some serious problems (which Jan's proposal
attempts to solve). But you don't solve these problems - therefore it's
rather strange for you to point out these problems as a reason to adopt
your proposal.
In the current system, you will probably have the correct core classes
installed but there is no guarantee that they will be used at runtime.
With your proposal, there is no guarantee that the correct core classes
will even be installed, let alone used.
Jan's proposal addresses these issues as I mentioned before. But in the
meantime, I'd prefer to keep j1/2-runtime since this at least gives
users half a chance.
> I don't want to put the burdon of testing all possible runtimes to
> library packagers. In most cases they can't do this even if some unit
> tests are included.
Um, surely the library packager should be the once to decide in what
circumstances the library will work? You'd rather push the burden from
one library packager to all users of that library (including end users
writing custom projects against that library)?
As I mentioned in a previous mail, *building* a library against a set of
core classes gives a fairly good indication of whether the library
should work with those core classes. Building (unlike running) *does*
run through all possible paths through the code, and since the only
difference between runtimes is (in theory) which classes are available
(not what they actually do), then this should give a fairly decent
result.
Ben.
Reply to: