[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Introduction + Clojure in e4 / Introduction
|
Hi Neil,
Thanks for your interest, I will try to explain what I did and what I
intend to do.
Hi Gaetan,
I'm also very interested in the work you have done. Clojure does look
like a really innovative approach to concurrency, meaning it could be
a powerful alternative to Java in general.
Yes, I think there are lots of possible (and very interesting)
interactions between Clojure and Eclipse:
* proper concurrent programming with STM and MVCC systems.
* functional paradigm to improve work on large and shared data
structures (Models, ASTs, DOMs, ...).
* homoiconicity and macro system enable very powerful and well
integrated code generation systems.
* all Lisp features greatly simplify creation of internal DSLs for
plug-ins API.
* prototyping and testing made easier thanks to dynamic features.
* interactive development : live code modification/interaction in a
running test instance of the app coupled with debug features.
* introduction of Aspect Oriented Programming through dynamic binding.
* scripting of Eclipse / OSGi features.
* ...
Moreover the design of Clojure make possible a smooth integration with
Java plug-ins: no need of specific wrapping or APIs for Java -> Clojure
(thanks to Java interop and use of Java interfaces for Clojure objects)
and Clojure -> Java (thanks to gen-class and proxy macros) interactions.
However, I tried to use Clojure with OSGi about 6 months ago and ran
into some quite significant problems. At the time I wasn't able to
devote enough time to resolving them, so I'd be interested to hear if
you have hit them yet and if so whether you have any solutions.
1) Clojure is not really an interpreted language like JavaScript. It
is compiled, with compilation to .class files occurring on the fly
during VM initialisation. The compilation runtime and the Clojure
standard library are bound tightly together so they cannot be
separated, and the compilation runtime is started by a static
initialiser block. As soon as any class from the standard library is
loaded, the compilation runtime will be kicked off. This is expensive:
on my 2.33Ghz Macbook Pro it takes over 2 seconds to start. Therefore
it is imperative to use just one "copy" of the Clojure runtime by
placing it in its own bundle.
In fact since the 20081217 release there is an AOT (Ahead Of Time)
compilation system that enable to generate .class files without running
them. However you still need to load the code in the runtime in order to
compile it.
Personally I package the Clojure lang in a specific bundle (with some
little hacks that I describe in the next section), and, as the
bootstrapping of the runtime is little long (around the 2 seconds for me
too), I made it start with the application (auto-startup). When I am
developing new plug-ins with Clojure code I only made them dependent on
the Clojure lang plug-in. The JDT compiler copies .clj files in the bin
directory (available to the plug-in class loader) and it runs well.
However for continuous integration and deployment I develop an Ant task
that is called in a custom callback build file. This made Clojure
compilation integrated in the release engine (based on PDE headless
build). So in the released product, Clojure code is directly available
as bytecode (no text file loading).
I agree too that it will be complicated to have several instance of the
Clojure runtime running at the same time. One possibility is to use the
runtime that is embedded in the test instance of the app instead of the
IDE's one, that may enforce the dynamic features of the language and
enable use of multiple versions of the runtime. It could be a very
interesting approach to dynamic development.
2) Compilation and execution of Clojure sources happens in the
classloader of the compilation runtime. Under OSGi this would be the
classloader of our Clojure bundle. There appears to be no way to
request Clojure to use a different classloader, and in my discussions
with Rich Hickey he felt it would be "unsound" to add such a facility.
Therefore there can be no proper separation of Clojure classes across
bundles, and the Clojure code in your bundle will not be able to see
the Java classes in your bundle unless you use DynamicImport-Package
or buddy loading.
That's quite true. In order to make Clojure code fully OSGi I had to
hack the Clojure runtime in order to use a specific class loading system
(but this is very local modifications : 3 or 4 methods in RT and a new
class for class loading). This system uses the namespace of Clojure code
in order to know which bundle use to load classes and resources. This
solution enable to use both Java and Clojure code in the same plug-ins
(and even in the same packages) and the Clojure code will share the
class loader of the plug-in (same visibility as Java). The draw back is
that the Clojure code namespaces have to begin with the plug-in name.
It is still experimental, but I can make it available under EPL if we
find a good way to share it.
Another solution could be to use Java reflexivity to find class and
therefore the class loader of the caller (but I did not try this one yet).
3) The Java implementation of Clojure itself is difficult to work
with. Hickey does not believe in OO, so all of his Java code is
contained in static methods, fields and initialisers.
Now, this was 6 months ago and perhaps some of these issues have been
resolved now. I hope so because I would like to use Clojure, but it
was just not practical the last time I looked.
The language (and therefore the runtime) is still quite young, and the
Clojure core team seems to be a little bit in a rush in order to release
a 1.0 as soon as possible (as there is a lot of buzz and expectation
around the language). I think later the Clojure community will be more
open to runtime re-factoring / extension. Moreover I think it is the
good time to gather a community of interested people around Clojure and
Eclipse and made some proposals about OSGi integration (but may be e4 is
not the right place to do this). About this specific problem I wish I
could share feedbacks (and find some support) in a Eclipse
"multi-language project", maybe some parts of the problem are common to
several languages and solutions could be made available in a specific
bundle (or implemented directly in the OSGi runtime).
Regards
Neil
I hope this is clear enough.
Feedbacks and questions are welcomed.
Cheeers,
Gaetan
2009/1/23 Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>:
Hi Gaetan,
I'm definitely interested in the work you're doing here. You're right in
that I'm doing work to better support JavaScript bundles however I don't
believe it's a stretch to support other JVM based languages in a similar
fashion.
The current status of e4 "multi-languge" is that we're just ramping up and
now is an ideal time to join in. (In addition to this list I'd suggest
speaking up at the bi-weekly meeting -- see calendar on
http://wiki.eclipse.org/E4)
The JavaScript/Rhino support code I've been working on is still fairly
prototype-y however it probably would make sense to more formally do and
share the work in the e4 incubator especially if other are interested.
--
For those not on the call...
Hi, I'm Simon. I'm a committer on the Equinox project where I work on
various aspects including p2, server-side, OSGi compendium services, and
bits and pieces of the framework.
I'm interested in contributing to e4 in the areas of multi-language support
(with an initial focus on JavaScript) as well as anything to do with
server-side interaction and runtimes.
-Simon
gaetan morice ---01/23/2009 12:30:24 PM---Hi all,
From:
gaetan morice <gaetan.morice@xxxxxxxxxxxxxxxx>
To:
e4-dev@xxxxxxxxxxx
Date:
01/23/2009 12:30 PM
Subject:
[e4-dev] Introduction + Clojure in e4
________________________________
Hi all,
I am head of the Eclipse Products Team at Anyware Technologies. I lead
Eclipse based IDE projects for embedded software tooling that involve lots
of Eclipse technologies such as EMF, CDT, TM and DLTK. I also lead research
efforts on alternative JVM languages use in Eclipse plugins development.
I am currently working on a proof of concept on the programming language
clojure (a functional dynamic jvm based language, which has a very
interesting way to deal with multi-threading : www.clojure.org and my
EclipseCon talk at http://www.eclipsecon.org/2009/sessions?id=630). >From my
point of view, writing plug-ins using clojure could be very interesting due
to its features (multithreading, dynamism, native Java interop) and its
performances which are very close to Java (vs. JRuby, Groovy, ...).
I made some hacks in the core of clojure runtime in order to use Bundles'
class loaders. And after some efforts I managed to use clojure code in
Eclipse plug-ins (I made a little builder in order to compile clojure files
into class files ). This code interacts in both directions with java and
share the dependency and visibility of the plugin in which it is hosted.
But the most interesting feature is that it is fully dynamic, enabling, for
example, live code modification in a running instance of Eclipse or
interaction with Eclipse components.
I've seen in yesterday's meeting notes that Simon Kaegi has managed to write
OSGi bundles in Javascript (but the code is not yet in e4 CVS, right?), and
I'd like to know the current status of e4 wrt dynamic languages integration,
and how I could join the effort.
Cheers,
Gaetan
--
Gaetan MORICE
Eclipse Expert
gaetan.morice@xxxxxxxxxxxxxxxx
Tel : +33(0)5 61 00 06 47
Fax : +33(0)5 61 00 51 46
New address
________________________________
Anyware Technologies
Lake Park
ZAC de l'Hers - Allée du Lac
BP 87216
31672 Labège Cedex
France
www.anyware-tech.com
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
--
Anyware Technologies <http://www.anyware-tech.com>
*Gaetan MORICE*
Eclipse Expert
gaetan.morice@xxxxxxxxxxxxxxxx <mailto:gaetan.morice@xxxxxxxxxxxxxxxx>
Tel : +33(0)5 61 00 06 47
Fax : +33(0)5 61 00 51 46
*New address
*
------------------------------------------------------------------------
*Anyware Technologies
* Lake Park
ZAC de l'Hers - Allée du Lac
BP 87216
31672 Labège Cedex
France
www.anyware-tech.com <http://www.anyware-tech.com>
