Re: Calumet and relative URIs

Ignoreing JVM's where CWD is simply not implemented ...

CWD is "vague" IMHO in Java because its process-wide not thread specific.
If you run multi-threads there is no way to set the CWD differently 
within each thread.
Depending on your program that can be "just fine" or "a total stumbling 
block".

An example.
In xmlsh, for example, 'sub shells' are run as seperate threads.  These 
seperate threads can "cd" to different directories
then run other programs such as xslt or calabash or whatever.
so you can do like this

( cd /foo ; xslt < file.xml ) &
( cd /bar ; xslt < file.xml ) &

In a 'normal unix shell' the implementation is obvious, you simply do a 
chdir() and the OS takes over.  Its process-wide and settable.

In Java, there is no such thing as 'chdir()' that can operate on a 
thread basis.  There's actually no 'chdir' at all.
I have largely faked this out by creating a thread specific version of 
the System properties ... this *mostly* works.
That is any code entirely in java which uses the system properties for 
the CWD as they are supposed to works, but *SOME* Internal java code,
especially in the File API's dont do this, they go directly to the OS 
for the CWD.  which hasnt changed, and even if I wrote a JNI to change it,
cant be per-thread.   I've been fortunate and have been able to work 
around this ugly thing in all cases I've found so far, but it is very 
very tricky,
and whenever I add a new library I discover new ways it can break.

Thats why I say CWD is  'vague' in Java.




David A. Lee
dlee@calldei.com  
http://www.calldei.com
http://www.xmlsh.org
812-482-5224



Florent Georges wrote:
> 2009/7/23 David A. Lee wrote:
>
>   
>> Now there's always room for a "third way"
>>     
>
>   Of course ;-)  And the idea to allow an explicit base URI to resolve
> all input documents could be useful I guess, even from within Java
> (while I do not really agree that CWD is a vague concept in Java, I
> agree though it is vague in Java EE environments, where I expect XProc
> to be widely used.)
>
>   

Received on Thursday, 23 July 2009 14:23:15 UTC