please believe me, i've been thinking hard about this.
What is the classpath if you start java -jar ?
Then you could say: look at the manifest inside the .jar.
That is true, but many times it is also empty, e.g. in jython-complete.jar!
Another example: if you start JBoss, almost everything is hot deployed later.
(As a side note, all the above illustrates that scanning the classpath
is by no means a guarantee that we pick every possible package - to
not speak of OSGI environments).
The big advantage of the standalone .jar is that you can drop it into
any java application.
You might say we 'know' which are the core java packages.
But do we really know what's below javax, for every possible java version ?
If we prefilled the cache with some core java packages we believe are
present in every virtual machine, this would be more confusing:
import javax.somepackage would work,
import javax.anotherpackage would not work.
So the bottom line is, if you stick to one simple rule of thumb (which
is good style in java generally, and in non-standalone jython projects
** For java stuff, only do explicit imports. **
then you're all set.
Now if you have a good solution for some of the problems listed above,
please let me know!
I am always interested in improving standalone mode.
On Fri, Nov 21, 2008 at 6:34 AM, Stefan Behnel <stefan_ml@...> wrote:
> Oti wrote:
>> in standalone mode, we cannot know which names are java packages,
>> thats - shortly spoken - the reason you cannot import 'a whole' java
>> package (in full mode we scan the classpath to find out the available
>> classes and put them into cachedir, which is useful if you start
>> jython from the command line).
> Thanks for the explanation.
>> You can also tell the interpreter that javax.swing is a package, by saying:
>> oti$ java -jar jython-complete.jar
>> Jython 2.5b0+ (trunk:5593M, Nov 20 2008, 22:43:24)
>> [Java HotSpot(TM) Client VM (Apple Inc.)] on java1.5.0_16
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import sys
>> <java package javax.swing 1>
>>>>> import javax.swing
>> <jclass javax.swing.JFrame 2>
>> I believe this little inconvenience is acceptable, given the
>> advantages a standalone .jar file has.
> I absolutely see the advantage of having a single .jar file, that's why I'm
> using it. But couldn't the above be automated even for the standalone jar?
> If a regular import fails, and Jython hasn't scanned the classpath before,
> it could do so right at that point and keep a set of all packages in
> memory. Then it would know how to import these things next time, and could
> just retrigger the import that just failed.
> I don't think it's a memory problem to keep, say, 10000 package names in
> memory, but I assume it might take a few seconds to scan a classpath of a
> couple of hundred MB - although the size isn't relevant here, as .zip files
> have a directory index, so it's the number of files that matters. And given
> the size of Jython's stdlib, I don't see why the classpath should become
> that large. It might be a different situation inside an app server, though.
> Still, would a couple of seconds for the first package import be that bad?
> If users want to optimise startup time, they can always stick to importing
> FQCNs. And, believe it or not, Jython's cold startup time is a couple of
> seconds on my machine already, so I wouldn't notice a difference if it took
> a second longer.
> The obvious advantage would be that code doesn't just break because Jython
> happens to run from inside a jar file on some user's machine.