Java's modules rock? (was Re: election details *PLEASE READ*)
Roel Wuyts
Roel.Wuyts at ulb.ac.be
Mon Mar 5 08:45:52 UTC 2007
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
>
>
More information about the Squeak-dev
mailing list
|