From: Schmidmeier, A. <Arn...@si...> - 2000-11-09 14:15:04
|
> -----Ursprüngliche Nachricht----- > Von: Samuele Pedroni [SMTP:pe...@in...] > Gesendet am: Donnerstag, 9. November 2000 13:55 > An: jyt...@li... > Betreff: Re: AW: [Jython-dev] work in progress > > Hi. > > [Schmidmeier, Arno] > > Yes they can be different. e.g. py passing > > -Duser.dir=~/something on the commandline of the java VM. > > I do not know which should be preferred, but my feeling says me that > > "" eqalsto System.getProperty("user.dir")should be preffered. > > However there might be a problem is the access to System.getProperty > > is restricted or if this property is not defined. > > I suggest therefore something like: > > > > String FileName=null; > > try{ > > FileName=System.getProperty("user.dir",null); > > }catch(SecurityException sec){} > > if (FileName==null) > > FileName="."; > > ... > I should admit I had missed these aspects. In any case the expansion > happen when interpreting classpath and sys.path, so "." is preferable. [Schmidmeier, Arno] I see here a problem with a bug in old versions of JPython. I do not know if it is fixed. It is pretty likely that . is on the classpath and also on sys.path. Older Versions of Jpython require a totally distinct classpath and sys.path. I am a bit scarry, only if this bug still exist, that you might add unwanted . to the classpath or sys.path. If this bug is fixed . is ok for me. > But I really worry about what happens on a Mac? > Unfortunately I have no access to such a machine and its jvms. > > [Schmidmeier, Arno] > > I do not understand this topic fully, I want to ask is following > > scenario possible: > > I have a java-package X with classes a and b. > > on the classpath (sys or jython) there are two distinct entries > > j1.jar and j2.jar. > > j1.jar contains a and j2.jar contains b. Is this possible? > > Same for .py filesand directories. > > The semantics for py modules will remain as in python, if one not plays > with > __path__ a py packages span over just one directory and its subdirs. > sys.path can contain only dirs (an extension for allowing zips and jars > should be not too difficult but it depends on what happens on CPython side > and for the moment I like to see what happen with the patch and get rid of > old and (hopefully few) new bugs, extending things should be easier > with a clean (so I hope) codebase. [Schmidmeier, Arno] I agree, extending things is much easier with a clean codebase. I vote for cleaning up first, then adding features. > The support for relative imports inside py pkgs should work as in CPython. > This should still be fixed in jythonc. > Concerning java with the patch: > * classpath is virtually extended with sys.path > classpath take over sys.path. > * py pkgs take over java pkgs, but the java classes in the shadowed pkg > can be accessed through the py package [Schmidmeier, Arno] I am a bit scary about this. Will following scenario work, with this design and implementation: I subclass a Java-Interface with Jython and create an instance a. (Jython needs to load the Java Interface), it is currently not in the Java VM. (instance of java.lang.Class called IJP A second Java Thread needs the class for the Java-Interface so it query the Java-Classloader after the interface, the classloader returns IJ. Jython passes A to a Java-Object which was loaded by the Java-Classloader. Now is IJP==IJ? > * dir and from import * for a java package now should really consider > the union of everything that's is in the dirs/jar on classpath and in the > dirs on sys.path. > > regards, Samuele > > [Schmidmeier, Arno] regards Arno |