> > * 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
