You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2004/12/03 14:20:57 UTC
Janino, an embedded java compiler
Hi all,
While reading a very interesting post on Brian McCallister's blog [1] on
"inverting the inversion of control" (something for block classloaders?)
I stumbled on Janino [2], an embeddable Java compiler.
The list of possible uses cases [3] is quite impressive:
- the expression evaluator can be used... ahem... as yet another EL for
our template engine :-)
- the script evaluator can be used for CForms event handlers
- the class body evaluator can be used to write JS-like code for
flowscript (we don't need a class name, but just methods)
- it provides a compiling classloader.
Too bad it is LGPL'ed...
Sylvain
[1] http://kasparov.skife.org/blog/2004/12/02#inverting-ioc
[2] http://www.janino.net/
[3] http://www.janino.net/use.html
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Growing, overall consistency and deprecation (was Re: Janino, an embedded java compiler)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 04 December 2004 01:50, Stefano Mazzocchi wrote:
> In short: you should not obtain your knowledge from reading the dev-
> list and we are solidifying many solutions into a recommended one, not
> adding more things.
I don't. I try to obtain it by using it. But following the dev@ is really
good, since it gives an upper-hand in understanding the "intentions" which
makes most stuff (like Flows) a lot easier to grasp as a user.
And Yes, I am *very* pleased with the documentation progress. All kudos to
those who work on it !!! And also the whole "startup demo" package makes it a
lot more "consumable" (learn by example - and no example means not use it ).
> And don't worry, my FS alarms might be slower to react these days (do to
> the fact that I have a day job now) but are never turned off ;-)
Good to know :o)
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: Growing, overall consistency and deprecation (was Re: Janino,
an embedded java compiler)
Posted by Sylvain Wallez <sy...@apache.org>.
Niclas Hedhman wrote:
>On Friday 03 December 2004 23:22, Sylvain Wallez wrote:
>
><snip />
>
>Well put.
>
>
>
>>Maybe we should be less shy to deprecate things. But the problem is that
>>deprecation means future deletion, which also scares people as it
>>doesn't give the image of something stable. Maybe some "mainstream-ness"
>>classification would allow people new to Cocoon to more easily find
>>their way into the system, while still giving the necessary code and
>>documentation to people having "legacy" Cocoon applications.
>>
>>
>
>Yes that sounds very reasonable.
><warning type="analogy" >
>"Not recommended for new designs" it is called in the electronics industry.
>That means that the part is manufactured, but there are better and cheaper
>ones around, and by natural selection the part will be of no demand in long
>enough time. When the demand is low enough, a final production run is made
>(deprecation) and all customers are informed, and can order any quantity for
>their own stock keeping for spare parts or whatever.
></warning>
>
>
This is a very good analogy.
>So, back to Cocoon; If you have a system where you can mark "not recommended
>for new designs", and then at the point of deprecation that 'part' could
>moved out of the standard dist, docs, discussion sphere, you are better set
>for a graceful end-of-life.
>
>
I totally agree with you.
>Mind you, these are non-urgent stuff, and I guess really noone's itch.
>
>
Well, this is non-urgent as old things don't need work as bug fixes or
new feature do, but the fact that we are discussing here shows that
there is an itch.
Now scratching may not be that complicated: let's just add a new
attribute managed by the SitemapTask to automatically indicate the
"freshness" status of a component in the docs. That can be a first step,
the next one being writing overview docs explaining best practices.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Growing, overall consistency and deprecation (was Re: Janino,
an embedded java compiler)
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> On Friday 03 December 2004 23:22, Sylvain Wallez wrote:
>
> <snip />
>
> Well put.
>
>
>>Maybe we should be less shy to deprecate things. But the problem is that
>>deprecation means future deletion, which also scares people as it
>>doesn't give the image of something stable. Maybe some "mainstream-ness"
>>classification would allow people new to Cocoon to more easily find
>>their way into the system, while still giving the necessary code and
>>documentation to people having "legacy" Cocoon applications.
>
>
> Yes that sounds very reasonable.
> <warning type="analogy" >
> "Not recommended for new designs" it is called in the electronics industry.
> That means that the part is manufactured, but there are better and cheaper
> ones around, and by natural selection the part will be of no demand in long
> enough time. When the demand is low enough, a final production run is made
> (deprecation) and all customers are informed, and can order any quantity for
> their own stock keeping for spare parts or whatever.
> </warning>
>
> So, back to Cocoon; If you have a system where you can mark "not recommended
> for new designs", and then at the point of deprecation that 'part' could
> moved out of the standard dist, docs, discussion sphere, you are better set
> for a graceful end-of-life.
>
> Mind you, these are non-urgent stuff, and I guess really noone's itch.
Niclas,
Cocoon is what it is because we are not afraid of changing our mind and
to collectively discuss things on the list and we don't act before we
have consensus.
Sure, FS creeps in (and I'm fighting it against taglibs, the ultimate FS
evil in my eyes, even Jelly's author moved away from it ashamed) but
that's why we have discussions.
We lack documentation and best practices and efforts are underway to
solidify those (our documentation is a lot better than it used to be).
In short: you should not obtain your knowledge from reading the dev-
list and we are solidifying many solutions into a recommended one, not
adding more things.
And don't worry, my FS alarms might be slower to react these days (do to
the fact that I have a day job now) but are never turned off ;-)
--
Stefano.
Re: Growing, overall consistency and deprecation (was Re: Janino, an embedded java compiler)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 03 December 2004 23:22, Sylvain Wallez wrote:
<snip />
Well put.
> Maybe we should be less shy to deprecate things. But the problem is that
> deprecation means future deletion, which also scares people as it
> doesn't give the image of something stable. Maybe some "mainstream-ness"
> classification would allow people new to Cocoon to more easily find
> their way into the system, while still giving the necessary code and
> documentation to people having "legacy" Cocoon applications.
Yes that sounds very reasonable.
<warning type="analogy" >
"Not recommended for new designs" it is called in the electronics industry.
That means that the part is manufactured, but there are better and cheaper
ones around, and by natural selection the part will be of no demand in long
enough time. When the demand is low enough, a final production run is made
(deprecation) and all customers are informed, and can order any quantity for
their own stock keeping for spare parts or whatever.
</warning>
So, back to Cocoon; If you have a system where you can mark "not recommended
for new designs", and then at the point of deprecation that 'part' could
moved out of the standard dist, docs, discussion sphere, you are better set
for a graceful end-of-life.
Mind you, these are non-urgent stuff, and I guess really noone's itch.
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+
Growing, overall consistency and deprecation (was Re: Janino, an
embedded java compiler)
Posted by Sylvain Wallez <sy...@apache.org>.
Niclas Hedhman wrote:
>On Friday 03 December 2004 22:23, Sylvain Wallez wrote:
>
>
>>Ok, re-read this with a [OT/RT/FS] prefix in the subject. I have not
>>said I *want* this to go into Cocoon.
>>
>>
>
>Sorry I chose to make the reply on your mail, and not one of the other feature
>proposals where it perhaps made more sense...
>
>Just wanted to raise a small flag. The creep is scary because one by one,
>everything makes sense but looking at the accummulated total, I am seeing a
>picture that scares people away.
>
>
I both agree and disagree: Cocoon is a complex beast, we all know that.
And despite my long term involvement in its development, there are areas
that are totally obscure to me, and some features I don't like. Even
some I wrote myself ; we all evolve over time.
However, the current discussion around templates and expressions
language is not meant to add yet another feature to Cocoon. It is meant
to provide a single solution for needs that are currently implemented in
Cocoon, but duplicated in many places with as many variations as there
are duplications, as each component (or developper) has reimplemented
the feature without really taking care of an overall consistency of the
Cocoon system.
Templates and expression languages are system-wide concern, and not only
concerns of individual high-level components. So we must define some
system-wide architecture to hold implementations of these concerns. Now
do we have to sacrifice diversity for this, by imposing e.g. a single
expression language? We cannot. Cocoon users form a very diverse
community, using the platform in diverse environments, even for a single
person. I want a bean-property EL when I use Hibernate, but also a XPath
EL when I use XML documents. But I don't want JXTG, XSP, CForms and
others to each either impose a particular EL or each provide a different
way of choosing the EL. Making a choice should be possible, but in a
consistent manner.
So yes, new features will be added. But just like CForms (who's still
using XMLForm?), these new features should become mainstream and
deprecate their older equivalent.
Now the problem also comes from the combination of a necessary backward
compatibility that requires us to keep deprecated features and the lack
of docs that indicate what features are the current mainstream ones and
those that are only here because of history.
Maybe we should be less shy to deprecate things. But the problem is that
deprecation means future deletion, which also scares people as it
doesn't give the image of something stable. Maybe some "mainstream-ness"
classification would allow people new to Cocoon to more easily find
their way into the system, while still giving the necessary code and
documentation to people having "legacy" Cocoon applications.
What do you think?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Janino, an embedded java compiler
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 03 December 2004 22:23, Sylvain Wallez wrote:
> Ok, re-read this with a [OT/RT/FS] prefix in the subject. I have not
> said I *want* this to go into Cocoon.
Sorry I chose to make the reply on your mail, and not one of the other feature
proposals where it perhaps made more sense...
Just wanted to raise a small flag. The creep is scary because one by one,
everything makes sense but looking at the accummulated total, I am seeing a
picture that scares people away.
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: Janino, an embedded java compiler
Posted by Sylvain Wallez <sy...@apache.org>.
Niclas Hedhman wrote:
>On Friday 03 December 2004 21:20, Sylvain Wallez wrote:
>
>
>>The list of possible uses cases [3] is quite impressive:
>>- the expression evaluator can be used... ahem... as yet another EL for
>>our template engine :-)
>>- the script evaluator can be used for CForms event handlers
>>- the class body evaluator can be used to write JS-like code for
>>flowscript (we don't need a class name, but just methods)
>>- it provides a compiling classloader.
>>
>>
>
>Once upon a time, the founders of Cocoon taught me about FS, and I am getting
>the feeling that it has been slowly creeping into Cocoon for so long now,
>that one can't see the forest for all the trees ;o)
>
>
Ok, re-read this with a [OT/RT/FS] prefix in the subject. I have not
said I *want* this to go into Cocoon.
I found something interesting, related to some features and problems we
have *today*, plus some potential other application domains.
Sure, I could have added an entry on my weblog for this, but this is a
dev list full of people I like to discuss with, I wanted to share it here.
Period.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Janino, an embedded java compiler
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 03 December 2004 21:20, Sylvain Wallez wrote:
> The list of possible uses cases [3] is quite impressive:
> - the expression evaluator can be used... ahem... as yet another EL for
> our template engine :-)
> - the script evaluator can be used for CForms event handlers
> - the class body evaluator can be used to write JS-like code for
> flowscript (we don't need a class name, but just methods)
> - it provides a compiling classloader.
Once upon a time, the founders of Cocoon taught me about FS, and I am getting
the feeling that it has been slowly creeping into Cocoon for so long now,
that one can't see the forest for all the trees ;o)
Honestly, how many *users* of Cocoon manages to keep up with the ever longer
list of so called features, many doing the same thing in different ways? I
don't, otoh, I don't do a lot in Cocoon (helping out on a couple of small
sites) but I try follow the dev@ list since the start in 99(?).
IMVHO, Cocoon needs to reduce features, not add them. Boil down to a nice core
that works, and then create a couple of subprojects for 'work styles'.
I think the barrier of entry to Cocoon is ever-growing, and I have heard a
couple of times from friends; "It is too complex." Before protests about the
modularity and that you can start small, I want to this is "impressions" and
"first impressions", they last...
In marketing terms, Cocoon right now is somewhat vulnerable to competition
that nails down the *need* of the users and delivers it in an easy to
comprehend package.
My two cents to the recent set of proposals to extend Cocoon even further.
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+