And the Java people are preparing to throw away the classloaders
mechanism with Jigsaw that will be in Java 9. (The classloading is a
brittle and error-prone mechanism.)
The aim of jigswa is to design and implement a new module system for the
Java SE platform and to apply that system to the platform itself and
to the JDK (more information in the project homepage
http://openjdk.java.net/projects/jigsaw/).
Miguel
Le 03/02/2013 18:03, Frank Shearar a écrit :
On 3 February 2013 15:42, Denis Kudriashov <[email protected]> wrote:
2013/2/3 Frank Shearar <[email protected]>
For java example libA.jar uses SharedClass.methodA and libB.jar uses
SharedClass.methodB. But #methodA exists only in version deployed as
libS-a.jar. And #methodB exists only in version deployed as libS-b.jar.
Dependency from libA.jar on libS-a.jar and libB.jar on libS-b.jar are
defined explicitly in their classpathes. So libA.jar knows nothing
about
libS-b.jar and v.v. And that's why your java programm can works at same
time with libA.jar and libB.jar. They will use different versions of
same
class.
No they won't, unless you have separate class loaders. What will
happen is you will get one version of a class or another.
Of course to get my java example working you should load classes from libA
and libB by separated class loaders.
In pharo there is no way to make it work. And this is what I want to discuss
here.
But it's complicated and fragile to have separate classloaders, and a
nightmare to debug. The Java people actively avoid this, for instance
in JBoss installations.
Take a look at Colin Putney's Environments work in Squeak 4.5. It
provides a, well, environment in which you can load classes such that
you can avoid the name clash problem. _Right now_ that's all it does,
but it'll likely do more in the future.
Gilad Bracha et al's work in Newspeak is the real way to go, I reckon.
(Environments could be a first step in that direction.) Newspeak uses
fully parameterised modules, which are first class entities. In fact
they really are (stateless) classes. However, Newspeak supports inner
classes.
frank
What it means in context of pharo?
In pharo we have configurations which manage dependencies of projects.
But
you can't use at same time projectA and projectB which depend on
different
versions of projectS (when they both use same SharedClass from projectS
like in java example). If you load projectA last you will get
SharedClass
with only methodA. If you load projectB last you will get SharedClass
with
only methodB. So projectA and projectB can't works correctly at same
time.
My example very simple. It includes just single class differencies. It
can
be more complicated and java world is good example for this.
So my global question is how it can be solved in pharo? Do you have
some
plan for this?
I can't remember something similar in pharo vision docs. But maybe what
Stephane called "modules system" is exactly about this? I mean what
Stephane always opposes in namespaces/environment discussions. And I
think
that this problem is ortogonal to namespaces/environments support. Do
you
agree? Do you know about such reseach in smalltalk?
Little conclusion about such module system (if we can named it such
way?)
and what it is required from pharo:
- ability to get in image different versions of same package.
- separated class (global) dictionaries (multiple Smalltalk's) per
package
version. Maybe it can be named Module. So let's think about Module as
unique Package+Version pair which contains all globals specific to this
version and all dependent other Modules.
- each Module knows it dependencies from other Modules, This
information
can be retreived from configuration.
- each method and class should know from which project version (module)
it
was loaded.
- inside any methods compiler should resolve class names based on
Module
dependencies information. Compiler should lookup actual class objects
from
module dependencies hierarchy. So no global Smalltak for compiler. But
Smalltalk can be stay in system as default core Module.
- If you want to use class which presents in two loaded versions of
same
package you should resolve conflict manually. Such action should add
dependency to Module of your code.
- Module can't have dependencies of two Modules of same package. It
means
that code of your project can use only version of some dependant class.
I
think it is essential restriction of Modules system.
Main thing which Module system can get to us is ability to safelly load
any
versions of our projects and use it. It is not matter how old this
code.
System just loads old version of pharo core for example. Existed pharo
core
will continue works correctly.
So what you think about it?
Best regards,
Denis
--
