Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Dalibor,
* Dalibor Topic wrote:
>but the other, much greater part of the problem is application writers who
>assume that the whole world uses sun's jdk. Thus they muck around with
>$JAVA_HOME, try to load sun.* classes, try to put a non-existant
>$JAVA_HOME/jre/tools.jar in their CLASSPATH, and so on.
eclipse has a really nice policy about such things... for the 3.0
release, the break a lot of things, but it all well documented. And
they have a really fine tuned API system, down to which methods are
API and which not.
>So for example you'll se a lot of broken build.xml files, that assume the java
>compiler is greedy, and automatically tracks down files needs to compile a
>class if they don't appear on the command line. Well, surprise, kaffe's java
>compiler, kjc, does not, and there is no spec saying a compiler needs to do it.
IMO, in this cases its better to go with 'everybody'... This should be
a one line change...
>there are no free software java browser plugins (yet). [...]
Then at least the unfree should be made working with our packaging.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: