Note that JAR files are not really what I would call a module  
mechanism; I am currently fighting them in the context of a not-quite- 
trivial application with lots of dependencies and boy, I wish that  
they would be somewhat more robust. Dependency management, version  
management and is simply not handled. Let alone proper packaging with  
'open classes' or 'class extensions' (so that you cannot even  
properly deploy a visitor pattern independently from the hierarchy it  
works on, actually the key of that pattern). Or another one of my  
favourites, which was properly handled in the Envy system btw,  
conditional loading of modules/code. No such luck :-(

The people at Eclipse had to work around all of this; all the plug-in  
stuff of Eclipse is done via their own mechanism built on top of Java  
such that they actually can deploy plug-ins a bit easier. And even  
then it is not possible to unload (!!!!!) any code, and the result is  
a difficult beast with XML config files that interact with the JARs  
things etc. Ugly, ugly, ugly.

I haven't looked at it in any detail, but if you want to look at  
module mechanisms from mainstream languages that are being used I  
would look at the one in C#. At least you have major and minor  
version numbers ;-) Anybody had a look at that ?

On 01 Mar 2007, at 1 March/10:22, Andreas Raab wrote:

> stephane ducasse wrote:
>>> In short: What impresses me about the Java solution is not that  
>>> it's flawless - what impresses me is that it works, that people  
>>> actually use it to deploy code and this code actually works in  
>>> the way intended.
>> But do you think that VW, VA code does not work once deployed? I  
>> would like to understand why Jar are better than parcels for example.
>
> Here are some "simple" issues: How do Parcels deal with conflicting  
> modifications to base classes? Say, one that says "Object>>isCommon  
> ^true" and one that says "Object>>isCommon ^false"? (Java simply  
> doesn't allow modifications to base classes which, really, isn't  
> such a bad thing from the point of view of modularity)
>
> Another one: Which assurances do parcels give in terms of security?  
> As far as I know there is no bytecode verifier, parcel have full  
> access to the entire Smalltalk namespace (covered by ClassLoaders  
> in Java), there are no limitations in terms of what operations a  
> parcel can perform (nil become: true; Java had a good set of fixes  
> in this area to get it right and not to leak ambient authority) and  
> I don't think VW even knows what a sandbox is.
>
> A third one: Which namespace are parcels loaded into? Can two  
> different versions of parcels be loaded side-by-side? How (if at  
> all) do they affect each other? Etc.
>
>> May be I should post to VW to see what are the problem with  
>> deployed code in VW.
>> A parcel in VW has dev and depl prerequisites and it seems to work  
>> too.
>
> Well, sure. Sorta. Kinda. :-) We can do the same in Squeak with  
> projects and change sets and it seems to work, too. Sorta. Kinda. :-)
>
> Cheers,
>   - Andreas
>
>