You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Drew Davidson <dr...@ognl.org> on 2004/08/08 17:27:38 UTC
OGNL 3.0.0 Preview 2 released
OGNL Technology, Inc. is proud to announce the release of OGNL 3.0.0
Preview 2, now available at
http://www.ognl.org
This release is a source release that provides a look at the current
state of the next stage of OGNL development. The intent of this preview
release is to solicit feedback from people who develop with and extend
OGNL to influence the future direction of OGNL.
The language is unchanged from that defined by OGNL 2.6.6, but the
internals have been completely reworked. The API is thus incompatible
with the previous versions of OGNL.
The invocation of an OGNL interpreter on an expression remains simple
and easy to perform.
OGNL 2.x:
import ognl.Ognl;
Object root = new RootObject();
result = Ognl.getValue("foo.bar.baz", root);
OGNL 3.x:
import org.ognl.el.ExecutionEnvironment;
import org.ognl.el.extensions.DefaultExecutionEnvironment;
Object root = new RootObject();
ExecutionEnvironment env = new DefaultExecutionEnvironment();
result = env.getValue(env.parseExpression("foo.bar.baz"), root);
As you will see by looking at the API there are few classes and mostly
interfaces in the org.ognl.el package; OGNL is defined by it's extension
points and these are expressed as interfaces. Default implementations
of these extensions are placed in the org.ognl.el.extensions package to
underscore their separate role in the framework. OGNL 3 provides more
clearly defined lines of responsibility and control; the acccessors have
been enhanced to get much more information about accesses that are
occurring (property accessors, in particular, have been greatly
enhanced). Type conversion and null handling have been folded into one
interface that handles both functions. Almost all extension APIs are
now registered on a class rather than globally, allowing for customizing
the behaviour of OGNL while restricting the domain of the extension to a
single class or interface.
The documentation has not yet been updated to OGNL 3. The language
guide is current because the language has not changed. The developer
guide is out of date, however. The JavaDoc is incomplete; many methods
are still undocumented, but may are documented. Most of the important
methods have some form of JavaDoc documentation on them.
This second preview release is a bug fix that incorporates all of the
bug fixes from the OGNL 2.6.6 release.
- Drew
--
+---------------------------------+
< Drew Davidson | OGNL Technology >
< Professional Open Source >
+---------------------------------+
| Email: drew@ognl.org /
| Web: http://www.ognl.org /
| Vox: (520) 531-1966 <
| Fax: (520) 531-1965 \
| Mobile: (520) 405-2967 \
+---------------------------------+
Re: OGNL 3.0.0 Preview 2 released
Posted by Drew Davidson <dr...@ognl.org>.
Adam Greene wrote:
> Can you provide an example of how to "turn on" the javassist stuff?
>
The example is the test in the OGNL source:
ognl/test/java/org/ognl/test/CompilingPropertyAccessor.java. This class
is not provided with the OGNL jar, just the source distribution. This
property accessor takes the place of the DefaultPropertyAccessor to
compile into a class the "get" method corresponding to a given
property. It is registered at startup thusly:
OgnlRuntime.setPropertyAccessor(Object.class, new
CompilingPropertyAccessor());
The compiler is limited in scope to properties of objects that have
accessors; it basically eliminates a reflective call to a method.
A more robust compiling solution is being worked on right now, with OGNL
2.7.0 and OGNL 3.0.0. I'm interesting in writing an actual compiler for
all elements of the OGNL parse tree (like the navigation Chain element,
which is where you would get real compiling performance boosts).
If you are interested in participating or hearing what's going on take a
look at the OGNL mailing lists; go to http://www.ognl.org for the lists.
- Drew
--
+---------------------------------+
< Drew Davidson | OGNL Technology >
+---------------------------------+
| Email: drew@ognl.org /
| Web: http://www.ognl.org /
| Vox: (520) 531-1966 <
| Fax: (520) 531-1965 \
| Mobile: (520) 405-2967 \
+---------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: OGNL 3.0.0 Preview 2 released
Posted by Adam Greene <ag...@iq-2000.com>.
Can you provide an example of how to "turn on" the javassist stuff?
Drew Davidson wrote:
> Adam Greene wrote:
>
>> There was some mention made that OGNL 3.0 would speed up OGNL, is
>> this true?
>
>
>
> OGNL 3.0 is more prepared to allow for compiled property accessors.
> There are more clearly-defined access points.
>
> One of the classes in the source is a compiling property accessor
> using Javassist (which meshes well with Tapestry, which also uses
> Javassist). This is optional, of course, since I don't want to ship
> OGNL with a dependency on any other libraries; but it's easy to plug
> it into the Environment just as you would any other accessor.
>
> Here is a run of the performance tests from OGNL 3. There are three
> results for each test: "java" is the compiled Java version, "compiled"
> is the Javassist-generated compiled property accessor, and
> "interpreted" is the OGNL evaluator without any compilation assistance.
>
> performance [OGNL3]:
> [java] Constant: 100 + (20 * 5)
> [java] java: 5446294 iterations in 1002 ms
> [java] compiled: 3687805 iterations in 1001 ms (1.5 times
> slower than java)
> [java] interpreted: 3640896 iterations in 1001 ms (1.5 times
> slower than java)
>
> [java] Single Property: bean2
> [java] java: 5636897 iterations in 1001 ms
> [java] compiled: 790666 iterations in 1002 ms (7.1 times slower
> than java)
> [java] interpreted: 77543 iterations in 1001 ms (72.7 times slower
> than java)
>
> [java] Property Navigation: bean2.bean3.value
> [java] java: 4937216 iterations in 1011 ms
> [java] compiled: 277214 iterations in 1002 ms (17.8 times
> slower than java)
> [java] interpreted: 29958 iterations in 1001 ms (164.8 times
> slower than java)
>
> [java] Property Navigation and Comparison: bean2.bean3.value <= 24
> [java] java: 5171168 iterations in 1001 ms
> [java] compiled: 195063 iterations in 1001 ms (26.5 times
> slower than java)
> [java] interpreted: 28470 iterations in 1002 ms (181.6 times
> slower than java)
>
> [java] Property Navigation with Indexed Access:
> bean2.bean3.indexedValue[25]
> [java] java: 5388811 iterations in 1002 ms
> [java] compiled: 97811 iterations in 1002 ms (55.1 times slower
> than java)
> [java] interpreted: 29761 iterations in 1001 ms (181.1 times
> slower than java)
>
> [java] Property Navigation with Map Access: bean2.bean3.map["foo"]
> [java] java: 3685474 iterations in 1011 ms
> [java] compiled: 176076 iterations in 1001 ms (20.9 times
> slower than java)
> [java] interpreted: 28330 iterations in 1002 ms (130.1 times
> slower than java)
>
> The results generally go from fastest (simple bean access where all of
> the work can be performed by a Javassist-compiling accessor) to the
> slowest (no assistance). The map access at the end is faster because
> it's property accessor is just a Map.get(), so it doesn't have to do
> reflection to get to the property.
>
> Bear in mind that this test only includes named property access. No
> attempt has been made to write compilers for the other operations,
> such as comparisons, etc. I expect that given time and help this will
> be accomplished.
>
> Here are the same performance tests for OGNL2 (with similar
> Javassist-generated property accessors):
>
> performance [OGNL2.6.6]:
> [java] Constant: 100 + (20 * 5)
> [java] java: 5599475 iterations in 1002 ms
> [java] compiled: 3402478 iterations in 1001 ms (1.6 times
> slower than java)
> [java] interpreted: 3255849 iterations in 1001 ms (1.7 times
> slower than java)
>
> [java] Single Property: bean2
> [java] java: 5717893 iterations in 1002 ms
> [java] compiled: 755983 iterations in 1001 ms (7.6 times slower
> than java)
> [java] interpreted: 458046 iterations in 1001 ms (12.5 times
> slower than java)
>
> [java] Property Navigation: bean2.bean3.value
> [java] java: 5343613 iterations in 1002 ms
> [java] compiled: 202217 iterations in 1002 ms (26.4 times
> slower than java)
> [java] interpreted: 130920 iterations in 1001 ms (40.8 times
> slower than java)
>
> [java] Property Navigation and Comparison: bean2.bean3.value <= 24
> [java] java: 5304380 iterations in 1001 ms
> [java] compiled: 151994 iterations in 1001 ms (34.9 times
> slower than java)
> [java] interpreted: 107465 iterations in 1002 ms (49.4 times
> slower than java)
>
> [java] Property Navigation with Indexed Access:
> bean2.bean3.indexedValue[25]
> [java] java: 5063081 iterations in 1001 ms
> [java] compiled: 78105 iterations in 1001 ms (64.8 times slower
> than java)
> [java] interpreted: 65550 iterations in 1002 ms (77.2 times slower
> than java)
>
> [java] Property Navigation with Map Access: bean2.bean3.map["foo"]
> [java] java: 3711423 iterations in 1002 ms
> [java] compiled: 164530 iterations in 1002 ms (22.6 times
> slower than java)
>
> So you can see that OGNL3 has a bit of an edge over OGNL2. It is
> mostly due to a more streamlined architecture; there is a clearer
> division of responsibilities and things are broken out better. The
> ability to provide compilation support in OGNL3 is more plausible
> since I'm writing it with that goal in mind; the OGNL 2 compilation
> support is really shoehorned into the code; it will work in the
> limited circumstances that this test exercises but there is little
> chance of writing a full-fledged compiler for all aspects of OGNL 2
> (reason being that OGNL2 does not provide it's accessors with very
> fine-grained information about the call that invoked it, making it
> difficult to determine the exact circumstances of the property access
> call).
>
> - Drew
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: OGNL 3.0.0 Preview 2 released
Posted by Drew Davidson <dr...@ognl.org>.
Adam Greene wrote:
> There was some mention made that OGNL 3.0 would speed up OGNL, is this
> true?
OGNL 3.0 is more prepared to allow for compiled property accessors.
There are more clearly-defined access points.
One of the classes in the source is a compiling property accessor using
Javassist (which meshes well with Tapestry, which also uses Javassist).
This is optional, of course, since I don't want to ship OGNL with a
dependency on any other libraries; but it's easy to plug it into the
Environment just as you would any other accessor.
Here is a run of the performance tests from OGNL 3. There are three
results for each test: "java" is the compiled Java version, "compiled"
is the Javassist-generated compiled property accessor, and "interpreted"
is the OGNL evaluator without any compilation assistance.
performance [OGNL3]:
[java] Constant: 100 + (20 * 5)
[java] java: 5446294 iterations in 1002 ms
[java] compiled: 3687805 iterations in 1001 ms (1.5 times slower
than java)
[java] interpreted: 3640896 iterations in 1001 ms (1.5 times slower
than java)
[java] Single Property: bean2
[java] java: 5636897 iterations in 1001 ms
[java] compiled: 790666 iterations in 1002 ms (7.1 times slower
than java)
[java] interpreted: 77543 iterations in 1001 ms (72.7 times slower
than java)
[java] Property Navigation: bean2.bean3.value
[java] java: 4937216 iterations in 1011 ms
[java] compiled: 277214 iterations in 1002 ms (17.8 times slower
than java)
[java] interpreted: 29958 iterations in 1001 ms (164.8 times slower
than java)
[java] Property Navigation and Comparison: bean2.bean3.value <= 24
[java] java: 5171168 iterations in 1001 ms
[java] compiled: 195063 iterations in 1001 ms (26.5 times slower
than java)
[java] interpreted: 28470 iterations in 1002 ms (181.6 times slower
than java)
[java] Property Navigation with Indexed Access:
bean2.bean3.indexedValue[25]
[java] java: 5388811 iterations in 1002 ms
[java] compiled: 97811 iterations in 1002 ms (55.1 times slower
than java)
[java] interpreted: 29761 iterations in 1001 ms (181.1 times slower
than java)
[java] Property Navigation with Map Access: bean2.bean3.map["foo"]
[java] java: 3685474 iterations in 1011 ms
[java] compiled: 176076 iterations in 1001 ms (20.9 times slower
than java)
[java] interpreted: 28330 iterations in 1002 ms (130.1 times slower
than java)
The results generally go from fastest (simple bean access where all of
the work can be performed by a Javassist-compiling accessor) to the
slowest (no assistance). The map access at the end is faster because
it's property accessor is just a Map.get(), so it doesn't have to do
reflection to get to the property.
Bear in mind that this test only includes named property access. No
attempt has been made to write compilers for the other operations, such
as comparisons, etc. I expect that given time and help this will be
accomplished.
Here are the same performance tests for OGNL2 (with similar
Javassist-generated property accessors):
performance [OGNL2.6.6]:
[java] Constant: 100 + (20 * 5)
[java] java: 5599475 iterations in 1002 ms
[java] compiled: 3402478 iterations in 1001 ms (1.6 times slower
than java)
[java] interpreted: 3255849 iterations in 1001 ms (1.7 times slower
than java)
[java] Single Property: bean2
[java] java: 5717893 iterations in 1002 ms
[java] compiled: 755983 iterations in 1001 ms (7.6 times slower
than java)
[java] interpreted: 458046 iterations in 1001 ms (12.5 times slower
than java)
[java] Property Navigation: bean2.bean3.value
[java] java: 5343613 iterations in 1002 ms
[java] compiled: 202217 iterations in 1002 ms (26.4 times slower
than java)
[java] interpreted: 130920 iterations in 1001 ms (40.8 times slower
than java)
[java] Property Navigation and Comparison: bean2.bean3.value <= 24
[java] java: 5304380 iterations in 1001 ms
[java] compiled: 151994 iterations in 1001 ms (34.9 times slower
than java)
[java] interpreted: 107465 iterations in 1002 ms (49.4 times slower
than java)
[java] Property Navigation with Indexed Access:
bean2.bean3.indexedValue[25]
[java] java: 5063081 iterations in 1001 ms
[java] compiled: 78105 iterations in 1001 ms (64.8 times slower
than java)
[java] interpreted: 65550 iterations in 1002 ms (77.2 times slower
than java)
[java] Property Navigation with Map Access: bean2.bean3.map["foo"]
[java] java: 3711423 iterations in 1002 ms
[java] compiled: 164530 iterations in 1002 ms (22.6 times slower
than java)
So you can see that OGNL3 has a bit of an edge over OGNL2. It is mostly
due to a more streamlined architecture; there is a clearer division of
responsibilities and things are broken out better. The ability to
provide compilation support in OGNL3 is more plausible since I'm writing
it with that goal in mind; the OGNL 2 compilation support is really
shoehorned into the code; it will work in the limited circumstances that
this test exercises but there is little chance of writing a full-fledged
compiler for all aspects of OGNL 2 (reason being that OGNL2 does not
provide it's accessors with very fine-grained information about the call
that invoked it, making it difficult to determine the exact
circumstances of the property access call).
- Drew
--
+---------------------------------+
< Drew Davidson | OGNL Technology >
+---------------------------------+
| Email: drew@ognl.org /
| Web: http://www.ognl.org /
| Vox: (520) 531-1966 <
| Fax: (520) 531-1965 \
| Mobile: (520) 405-2967 \
+---------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: OGNL 3.0.0 Preview 2 released
Posted by Adam Greene <ag...@iq-2000.com>.
There was some mention made that OGNL 3.0 would speed up OGNL, is this true?
Drew Davidson wrote:
> OGNL Technology, Inc. is proud to announce the release of OGNL 3.0.0
> Preview 2, now available at
>
> http://www.ognl.org
>
> This release is a source release that provides a look at the current
> state of the next stage of OGNL development. The intent of this
> preview release is to solicit feedback from people who develop with
> and extend OGNL to influence the future direction of OGNL.
>
> The language is unchanged from that defined by OGNL 2.6.6, but the
> internals have been completely reworked. The API is thus incompatible
> with the previous versions of OGNL.
>
> The invocation of an OGNL interpreter on an expression remains simple
> and easy to perform.
>
> OGNL 2.x:
>
> import ognl.Ognl;
>
> Object root = new RootObject();
>
> result = Ognl.getValue("foo.bar.baz", root);
>
> OGNL 3.x:
>
> import org.ognl.el.ExecutionEnvironment;
> import org.ognl.el.extensions.DefaultExecutionEnvironment;
>
> Object root = new RootObject();
> ExecutionEnvironment env = new DefaultExecutionEnvironment();
>
> result = env.getValue(env.parseExpression("foo.bar.baz"), root);
>
> As you will see by looking at the API there are few classes and mostly
> interfaces in the org.ognl.el package; OGNL is defined by it's
> extension points and these are expressed as interfaces. Default
> implementations of these extensions are placed in the
> org.ognl.el.extensions package to underscore their separate role in
> the framework. OGNL 3 provides more clearly defined lines of
> responsibility and control; the acccessors have been enhanced to get
> much more information about accesses that are occurring (property
> accessors, in particular, have been greatly enhanced). Type
> conversion and null handling have been folded into one interface that
> handles both functions. Almost all extension APIs are now registered
> on a class rather than globally, allowing for customizing the
> behaviour of OGNL while restricting the domain of the extension to a
> single class or interface.
>
> The documentation has not yet been updated to OGNL 3. The language
> guide is current because the language has not changed. The developer
> guide is out of date, however. The JavaDoc is incomplete; many
> methods are still undocumented, but may are documented. Most of the
> important methods have some form of JavaDoc documentation on them.
>
> This second preview release is a bug fix that incorporates all of the
> bug fixes from the OGNL 2.6.6 release.
>
> - Drew
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org