|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 80
Messages: 80
Messages: 80
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Jesse Kuhnert, of the Tapestry Project, openly lambasted the MVEL project as a futile effort in the face of his unstoppable perseverance in terms of bringing superior performance to OGNL. Like MVEL has had since it's early 1.2 betas, OGNL 2.7 has introduced a new bytecode enhancement system to reduce/remove reflection calls at runtime.
Kuhnert assured me that OGNL 2.7 would put to rest any question about whether or not MVEL was faster.
Looking at our performance tests against OGNL 2.6.11 over at http://mvel.codehaus.org/Performance+of+MVEL, it was clear that early builds on MVEL 1.2 were much faster than OGNL. In fact, in our deep property expression test for "foo.bar.name", MVEL's compiled-mode execution yielded performance 51 times superior to OGNL.
With the release of the now stabilized OGNL 2.7, I thought it was time to test Kuhnert's assertion that it would indeed be faster than MVEL.
Using our same testsuite, we plugged OGNL 2.7 in, put javassist in the classpath and let it rip. And yes, OGNL 2.7 was faster. But not faster than MVEL. Based on our test results, OGNL 2.7 yeilds significantly faster results, yet remains about 10 times slower than MVEL 1.2
It seems that Jesse has a little bit more work to do. Especially considering that Commons-EL seems to remain faster than OGNL without bytecode acceleration.
Appendix: Some of the Test Results:
Test Name : Deep Property
Expression : foo.bar.name
Iterations : 100000
Interpreted Results :
(OGNL) : 6587.67ms avg. (mem delta: -2kb) [6719,6529,6515]
(MVEL) : 452.67ms avg. (mem delta: -107kb) [453,453,451]
Compiled Results :
(OGNL Compiled) : 601.67ms avg. (mem delta: 244kb) [601,602,602]
(MVEL Compiled) : 68.33ms avg. (mem delta: 0kb) [69,68,68]
(CommonsEL Compiled) : 136.00ms avg. (mem delta: 0kb) [136,136,136]
------------------------------------------------
Test Name : Static Field Access (MVEL)
Expression : Integer.MAX_VALUE
Iterations : 100000
Interpreted Results :
(MVEL) : 298.00ms avg. (mem delta: -298kb) [298,298,298]
Compiled Results :
(MVEL Compiled) : 23.00ms avg. (mem delta: -85kb) [23,23,22]
------------------------------------------------
Test Name : Static Field Access (OGNL)
Expression : @java.lang.Integer@MAX_VALUE
Iterations : 100000
Interpreted Results :
(OGNL) : 5954.67ms avg. (mem delta: -2kb) [5951,5961,5952]
Compiled Results :
(OGNL Compiled) : 52.00ms avg. (mem delta: 85kb) [52,51,52]
------------------------------------------------
Test Name : Inline Array Creation (MVEL)
Expression : {'foo', 'bar'}
Iterations : 100000
Interpreted Results :
(MVEL) : 1651.33ms avg. (mem delta: 96kb) [1652,1652,1650]
Compiled Results :
(MVEL Compiled) : 22.67ms avg. (mem delta: 74kb) [23,22,23]
------------------------------------------------
Test Name : Inline Array Creation (OGNL)
Expression : new String[] {'foo', 'bar'}
Iterations : 100000
Interpreted Results :
(OGNL) : 5732.67ms avg. (mem delta: 52kb) [5582,5610,6006]
Compiled Results :
(OGNL Compiled) : 222.00ms avg. (mem delta: 75kb) [222,222,222]
|
|
|
Message #235973
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ignore him!
I'd ignore Jesse, he's not exactly the sharpest tool in the box.
but lovely with the kids.
|
|
|
Message #235975
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Let's keep it technical, please.
Guys, it'd be nice not to turn this into a "pick on Jesse" thread. It's unnecessary and - personally - unwanted.
That said, I'd like to see the OGNL community's responses - let's get these expression languages to be well done, all of them.
|
|
|
Message #235984
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Let's keep it technical, please.
That said, I'd like to see the OGNL community's responses - let's get these expression languages to be well done, all of them.
It is good to talk numbers rather than speculations. Personally, I doubt whether the performance difference between this version of OGNL and MVEL will be an actual bottleneck for many people, but if the feature set is roughly the same, the choice seems easy.
If you would use this mainly for object path expresssions, what would be compelling reasons to choose one over the other besides performance?
|
|
|
Message #235986
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
My goodness but my ears are awfully red right now.. ;)
Those are interesting results - but I've just finished running some comparisons of my own and am afraid I'm just not seeing the same thing. Though MVEL does appear to be a few ms faster here and there I see nothing to really get excited about. In fact I'm sure these kinds of comparisons will become more and more redundant as both libraries improve their jit'ing code as it really just gets reduced to pure java statements - right?
I'm sure I've screwed things up and not set this up properly to get these MVEL performance benefits - please do correct things where I've gone wrong as I have no desire to show incorrect results. ...
Another thing to keep in mind is that the "interpreted" results below aren't really fair as the OGNL interpreted runs are using the pre-interpreted AST object tree created as was the behavior of this existing performance test...I'm happy to change things around some to show the best possible run for both libraries when someone can correct my usage. (I wasn't sure if MVEL had a non jit version of an evaluated expression in AST form ? )
Well...here are my results anyways:
[java] ============================================================================
[java]
[java] OGNL Constant: 100 + 20 * 5
[java] java: 100000 iterations in 17 ms
[java] compiled: 100000 iterations in 18 ms (1.059 times slower than java)
[java] interpreted: 100000 iterations in 18 ms (1.059 times slower than java)
[java]
[java] MVEL Constant: 100 + 20 * 5
[java] java: 100000 iterations in 17 ms
[java] compiled: 100000 iterations in 91 ms (5.353 times slower than java)
[java] interpreted: 100000 iterations in 396 ms (23.294 times slower than java)
[java]
[java] OGNL Single Property: bean2
[java] java: 100000 iterations in 18 ms
[java] compiled: 100000 iterations in 19 ms (1.056 times slower than java)
[java] interpreted: 100000 iterations in 134 ms (7.444 times slower than java)
[java]
[java] MVEL Single Property: bean2
[java] java: 100000 iterations in 17 ms
[java] compiled: 100000 iterations in 27 ms (1.588 times slower than java)
[java] interpreted: 100000 iterations in 137 ms (8.059 times slower than java)
[java]
[java] OGNL Property Navigation: bean2.bean3.value
[java] java: 100000 iterations in 20 ms
[java] compiled: 100000 iterations in 19 ms (1.053 times faster than java)
[java] interpreted: 100000 iterations in 317 ms (15.850 times slower than java)
[java]
[java] MVEL Property Navigation: bean2.bean3.value
[java] java: 100000 iterations in 17 ms
[java] compiled: 100000 iterations in 33 ms (1.941 times slower than java)
[java] interpreted: 100000 iterations in 196 ms (11.529 times slower than java)
[java]
[java] OGNL Property Navigation and Comparison: bean2.bean3.value <= 24
[java] java: 100000 iterations in 19 ms
[java] compiled: 100000 iterations in 20 ms (1.053 times slower than java)
[java] interpreted: 100000 iterations in 300 ms (15.789 times slower than java)
[java]
[java] MVEL Property Navigation and Comparison: bean2.bean3.value <= 24
[java] java: 100000 iterations in 17 ms
[java] compiled: 100000 iterations in 144 ms (8.471 times slower than java)
[java] interpreted: 100000 iterations in 245 ms (14.412 times slower than java)
[java]
[java] OGNL Property Navigation with Map Access: bean2.bean3.map['foo']
[java] java: 100000 iterations in 21 ms
[java] compiled: 100000 iterations in 21 ms (1.000 times slower than java)
[java] interpreted: 100000 iterations in 373 ms (17.762 times slower than java)
[java]
[java] MVEL Property Navigation with Map Access: bean2.bean3.map['foo']
[java] java: 100000 iterations in 19 ms
[java] compiled: 100000 iterations in 28 ms (1.474 times slower than java)
[java] interpreted: 100000 iterations in 298 ms (15.684 times slower than java)
[java]
[java]
[java]
[java] ============================================================================
Are you guys back to calling OGNL.parseExpression(String) "compiled" expressions again perhaps? The correct way to compile (as in bytecode enhancement) expressions is:
Node node = Ognl.compileExpression(OgnlContext context, Object root, String expression);
Then to use the jit'ed methods call ((ExpressionAccessor)node.getAccessor()).get(context, root); (or set(context, root) - if your expression language supports setting, you guys do support setting right? That's another thing I left out as I wasn't sure about the comparison)
You can see all of this yourselves by checking the project out from http://svn.opensymphony.com/svn/ognl/trunk/ . I've even gone as far as including the asm.jar/mvel.jar in the lib dir so would really appreciate some corrections from people as I find it hard to believe that the MVEL folks would have such a large/obvious discrepancy in their performance comparisons. . .......
|
|
|
Message #235988
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ignore him!
Did someone say something about children? ....
I'd ignore Jesse, he's not exactly the sharpest tool in the box.
but lovely with the kids.
|
|
|
Message #235989
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Correction: Oops...I had just assumed that MVEL was faster here and there but I guess after looking more closely at the tests it appears that OGNL beats MVEL in every expression. Ouch.
Again, hopefully this is just a misunderstanding/incorrect usage on my part.
Either way I'm glad to see MVEL moving along. If it gets far enough along some day it might be nice to switch over to it instead of having to maintain my own library. I do always prefer to use the best of everything and this would be no different.
|
|
|
Message #235990
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Well, no. We weren't testing in the method you are suggesting. But I wasn't really putting MVEL at any advantage.
I dare say I could extract the raw generated accessor class in MVEL from a property expression and get significantly improved results. However, MVEL's JIT does maintain consistent behavior between it's bytecode optimization and standard AST/Reflection code. In fact, hybrid execution is possible in the model.
We don't have a separate API for using the JIT, but pure AST execution in the compiler can be achieved simply by setting the system property "mvel.disable.jit" to true.
When I get back to the office today, I will pour over your results more closely. Can I get a copy of the source code used to generate your results. MVEL's are in: (SVN) https://svn.codehaus.org/mvel/trunk/src/test/java/org/mvel/tests/perftests/ELComparisons.java
BTW, MVEL does not require asm.jar in the classpath.
|
|
|
Message #235992
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Compiling
I should also note that MVEL's compiler does not require that you specify live runtime data (in either mode) to achieve a compile.
I'm just interested: does the OGNL bytecode compiler support the full gamut of the OGNL language, or just property expressions?
For example, you can write something like this in MVEL:
----
if (foo > 1) {
output = "True";
}
else {
output = "False;"
}
----
Even with the full multi-line expression in MVEL, you'll get the benefit of the JIT. So I'm trying to understand. There's very little documentation on OGNL 2.7.
|
|
|
Message #235993
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
...Can I get a copy of the source code used to generate your results. MVEL's are in: (SVN) https://svn.codehaus.org/mvel/trunk/src/test/java/org/mvel/tests/perftests/ELComparisons.java
BTW, MVEL does not require asm.jar in the classpath.
Certainly, it's in the svn url I posted in my first reply - but the specific class is:
http://svn.opensymphony.com/svn/ognl/trunk/src/test/java/org/ognl/test/Performance.java
You should be able to just check the project out and run "ant perf-test" to execute it.
I must admit that I had forgotten our quarrel until I saw this headline today, I've been busy on lots of things and didn't even think to check this stuff out. You're right, there ~is~ little to no documentation on the new stuff in 2.7. Something which I plan on correcting soon. (had to take a little break for a few days)
I have no ill will towards MVEL, really....Trust me...The majority of time I spend testing/fixing various jit compiler errors/bugs feels very painful and I'd love nothing better than to see you pummel me into submission with a superior library. With the amount of resources you guys have attaching it I'm sure that day will come very soon.
|
|
|
Message #235996
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
And yes, I realized I'm generating a new OgnlContext on each iteration, but I think that's completely fair, considering that would need to be done in the real-world.
|
|
|
Message #235997
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Nope....That's been fixed as well...
So, still wrong and still slower. Keep trying though. You'll get there some day.
And yes, I realized I'm generating a new OgnlContext on each iteration, but I think that's completely fair, considering that would need to be done in the real-world.
|
|
|
Message #235999
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
And yes....if you were wondering. I ~am~ sitting here with a big shit eating grin on my face in absolute disbelief.
|
|
|
Message #236001
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Okay, first of all, you don't even have full language coverage. And after some testing, it's not exactly safe to integrate OGNL 2.7 passing a null into the OgnlContext parameter. What happens if I declare a lambda expression?
Exception in thread "main" java.lang.NullPointerException
at ognl.SimpleNode.getValue(SimpleNode.java:216)
at ognl.ASTSequence17340500Accessor.get(ASTSequence17340500Accessor.java)
at org.mvel.tests.perftests.MVELOGNLTest.main(MVELOGNLTest.java:64)
And if we get down to the nitty gritty and compare the raw bytecode classes generated, we are going to see little difference. This is where I think your comparisons are unfair.
You are able to optimize a subset of common operations in your bytecode enhanced mode, using an API paradigm specific to that subset, while ignoring large parts of the language.
In MVEL we don't have the luxury of that. Instead, we have 2 basic API entry points, where we expect ALL language features to work ALL the time.
|
|
|
Message #236003
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Do you just enjoy being wrong? Retreat man, retreat...
You don't/aren't supposed to pass in a null OgnlContext (though I guess in many expressions you probably could).
Tapestry pools these OgnlContext objects and utilizes the clear() method they provide to reset state.
Feel free to keep going with your tests, but I think it's ironic to hear you talking about "fair" in the context of this thread. ie you brought this on yourself man, sorry you don't like the results. If you had queried me ahead of time to verify before posting (as I would have done if for some reason I felt compelled to do such a thing, which probably wouldn't happen) you would have saved yourself the pain happening now. ...
Okay, first of all, you don't even have full language coverage. And after some testing, it's not exactly safe to integrate OGNL 2.7 passing a null into the OgnlContext parameter. What happens if I declare a lambda expression?
Exception in thread "main" java.lang.NullPointerException
at ognl.SimpleNode.getValue(SimpleNode.java:216)
at ognl.ASTSequence17340500Accessor.get(ASTSequence17340500Accessor.java)
at org.mvel.tests.perftests.MVELOGNLTest.main(MVELOGNLTest.java:64)
And if we get down to the nitty gritty and compare the raw bytecode classes generated, we are going to see little difference. This is where I think your comparisons are unfair.
You are able to optimize a subset of common operations in your bytecode enhanced mode, using an API paradigm specific to that subset, while ignoring large parts of the language.
In MVEL we don't have the luxury of that. Instead, we have 2 basic API entry points, where we expect ALL language features to work ALL the time.
|
|
|
Message #236004
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
What makes you think I'm feeling pain?
I'm certainly evaluating the results, but trust me, I'm not intimidated. Nor do I take such things like this very seriously. This was always meant as friendly competition.
|
|
|
Message #236009
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
You don't/aren't supposed to pass in a null OgnlContext
You might as well state that in the Javadocs.
|
|
|
Message #236010
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Whats next? Ass Lickers 1.0 vs. Rim Job 2.3 - Hani's Challenge?
|
|
|
Message #236011
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Eelco eelco.....Don't you think you've had enough already?
I suppose you're going to tell me I should start writing my web code like I'm programming a swing application?
Thanks, but I think I'll save taking advice from people who know what they're talking about.
You don't/aren't supposed to pass in a null OgnlContext
You might as well state that in the Javadocs.
|
|
|
Message #236012
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Eelco eelco.....Don't you think you've had enough already?
Enough of what exactly?
I suppose you're going to tell me I should start writing my web code like I'm programming a swing application?
What makes you think that?
Thanks, but I think I'll save taking advice from people who know what they're talking about.
Right.
You don't/aren't supposed to pass in a null OgnlContext
You might as well state that in the Javadocs.
Ok, let me try again.
Any method in the Ognl class that takes parameter context states this:
@param context
The context to use.
It would be good if you state that the context shouldn't be null. I could have said that on the OGNL mailing list, I could've reported a bug with a patch (did that before for OGNL actually), or I could just make a suggestion here as we were on the topic anyway.
If you think this is an outragous request, go ahead and ignore it. I couldn't care less, though maybe some of 'your' users might.
|
|
|
Message #236013
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Whats next? Ass Lickers 1.0 vs. Rim Job 2.3 - Hani's Challenge?
You tell me.
|
|
|
Message #236014
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
I thought it was annoying because the javadocs didn't say it ~can~ be null. I almost always specifically state when a parameter is optional.
....Don't you? Or for every parameter do you say "and it can't be null". Wtf?
...If you think this is an outragous request, go ahead and ignore it. I couldn't care less, though maybe some of 'your' users might.
|
|
|
Message #236015
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
I thought it was annoying because the javadocs didn't say it ~can~ be null. I almost always specifically state when a parameter is optional.
....Don't you? Or for every parameter do you say "and it can't be null".
No, I don't. I typically try to state whether it can be null or not, and if it can't be null, I'll try to throw a NPE or illegalargumentexception early. I'm not doing it as consistently as I should, but I'm definitively making the effort for at least the important classes. In that sense, I felt the Ognl class would benefit from a little bit more description. Same goes for OgnlContext btw.
Wtf?
How does that help here?
|
|
|
Message #236016
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Again....Just another case of you not knowing what you are talking about.
Do you know how much it would cost people performance-wise to do checks for parameters that may/may not even be needed?
Why, if I had done that it might have cost me enough ms. in runtime performance to not make everyone in this thread look like complete petty morons.
Good for you for lookin out for the "users" though. Much love homey.
I thought it was annoying because the javadocs didn't say it ~can~ be null. I almost always specifically state when a parameter is optional.
....Don't you? Or for every parameter do you say "and it can't be null".
No, I don't. I typically try to state whether it can be null or not, and if it can't be null, I'll try to throw a NPE or illegalargumentexception early. I'm not doing it as consistently as I should, but I'm definitively making the effort for at least the important classes. In that sense, I felt the Ognl class would benefit from a little bit more description. Same goes for OgnlContext btw.
Wtf?
How does that help here?
|
|
|
Message #236017
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Again....Just another case of you not knowing what you are talking about.
Feel free to list those cases.
Do you know how much it would cost people performance-wise to do checks for parameters that may/may not even be needed?
Why, if I had done that it might have cost me enough ms. in runtime performance to not make everyone in this thread look like complete petty morons.
You have *got* to be kidding me. Putting a null check in compileExpression would kill your edge...
Sad.
|
|
|
Message #236018
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Do you know how much it would cost people performance-wise to do checks for parameters that may/may not even be needed?
Why, if I had done that it might have cost me enough ms. in runtime performance to not make everyone in this thread look like complete petty morons.
You have *got* to be kidding me. Putting a null check in compileExpression would kill your edge...
Sad.
|
|
|
Message #236019
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Jesse Kuhnert, I didn't know who you were until today but your attitude on this thread is making me not want to look into OMGL (or whatever it's called). If you write your api's like you write your comments, I worry that your code throws WTFExceptions with error messages like, "Figures, you have no idea what you're doing".
I'm sure that's fine with you though. You probably think I'm not good enough to use your language.
|
|
|
Message #236020
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Why, if I had done that it might have cost me enough ms. in runtime performance to not make everyone in this thread look like complete petty morons.
Jesse, could you list all the projects that you contribute to, so that readers who appreciate your attitude could flock to those projects, while the small and moronic minority of us who obviously don't "get it" could carefully avoid the same?
Thanks :)
Peace,
Cameron Purdy
Oracle Coherence: The Java Data Grid
|
|
|
Message #236021
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Oh I get it now....So first I'm attached with what amounts to personal insults and technical FUD - and then after having successfully fought that off I'm to be labeled a "not nice guy".
I guess I just can't win. Oh well, I'm not here to win the affection of the majority. I'm here to program because that's what I love to do. So long as I'm able to support myself doing that I doubt much will change with my attitude when confronted with people / arguments like this.
Why, if I had done that it might have cost me enough ms. in runtime performance to not make everyone in this thread look like complete petty morons.
Jesse, could you list all the projects that you contribute to, so that readers who appreciate your attitude could flock to those projects, while the small and moronic minority of us who obviously don't "get it" could carefully avoid the same?
Thanks :)
Peace,
Cameron Purdy
Oracle Coherence: The Java Data Grid
|
|
|
Message #236022
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
No, i think the point is that you're an pompous, condescending troll incapable of holding a discussion without insulting the intelligence of those involved. It's a common behavior in which I've seen you indulge in just about every discussion I've seen involving you. Your overweening arrogance is what some are objecting to. If you can't hold a technical discussion without insulting everyone, maybe computers aren't for you. You might be as brilliant as you proclaim so often and so loudly but I just can't get past the fact that you come across as a prick. But maybe that's because I'm a troglodyte.
|
|
|
Message #236023
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
Ok so just to be sure we're clear here.
Eelco is a developer on Wicket.
Justin is either a wicket developer or a very zealous user of wicket. http://www.antwerkz.com/wp/?p=1014
I'm not sure why Cameron is involved or where he fits or who he is but I know he posts here a lot and supposedly throws good parties. That's neat.
Ok, so is the picture clearly laid out here now? Sorry guys, you're just incredibly transparent and I can't let you all chime in with "but you're just a big meanie" without defending myself somewhat.
No, i think the point is that you're an pompous, condescending troll incapable of holding a discussion without insulting the intelligence of those involved. It's a common behavior in which I've seen you indulge in just about every discussion I've seen involving you. Your overweening arrogance is what some are objecting to. If you can't hold a technical discussion without insulting everyone, maybe computers aren't for you. You might be as brilliant as you proclaim so often and so loudly but I just can't get past the fact that you come across as a prick. But maybe that's because I'm a troglodyte.
|
|
|
Message #236024
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
hahahahaha. You think my involvement in wicket has something to do with the fact I think you're a dick? I also use and have contributed bits and pieces of code to testng over the years. I suppose that means all of testng devs are out to get you, too. Wait. <checks user list/> There you are. and hey! you're a dick there. i think maybe it's time to take your meds. You're clearly unbalanced and finding conspiracies where no exist.
|
|
|
Message #236025
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
Take my meds? If you are a testng dev then you will have possibly seen me openly admit to actually really having mental "quirks" which prevents me from interacting with you on a more loving/human level. It's called aspbergers and I'm not ashamed to admit to having it.
So, laugh all you want if it makes you feel good about yourself.
hahahahaha. You think my involvement in wicket has something to do with the fact I think you're a dick? I also use and have contributed bits and pieces of code to testng over the years. I suppose that means all of testng devs are out to get you, too. Wait. <checks user list/> There you are. and hey! you're a dick there. i think maybe it's time to take your meds. You're clearly unbalanced and finding conspiracies where no exist.
|
|
|
Message #236026
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
I don't laugh to make myself feel better. I laugh because your conspiracy theories and martyr syndrome make me giggle. If you have aspberger's (I really have no idea, I typically tune out once you start talking) then I'm really sorry to hear that. Your correspondence is still overwhelmingly hostile and condescending. And I, for one, don't care for it.
|
|
|
Message #236028
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of arrogant people
Ok so just to be sure we're clear here.
Sorry guys, you're just incredibly transparent and I can't let you all chime in with "but you're just a big meanie" without defending myself somewhat.
What you really ought to realise Mr Kuhnert is that there is a big difference between "defending yourself" with technical arguments, and being incredibly arrogant and writing condescending insults to anyone who puts their head over some imaginary parapet in your mind. Perhaps looking up the word "respect" would be a good start point. Respect others for what they are doing, and perhaps they may respect you more.
|
|
|
Message #236029
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Back in planet earth -> this is what we actually need here
1) The official choice - 'Unified EL' - has proven to be insufficient in real life web app projects. Most critically the lack of support for method call parameters is huge problem in everyday use.
2) In the said real life web app projects the performance of the EL has never showed up in the radar when doing profiling. The performance bottlenecks are simply elsewhere. The overall performance would not change significantly if you'd replace EL with something 100X faster.
What i'm saying is that your pissing contest is totally irrelevant for the majority.
What would be useful is if you'd get your big brains together, push Sun to revise Unified EL, fix what is broken and then, if you wish, make it faster at the same time.
/Henri Karapuu
|
|
|
Message #236030
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
Ok so just to be sure we're clear here.
Eelco is a developer on Wicket.
And what does that clear up then? I didn't mention Wicket in this thread, nor was it the reason I joined in.
Let's just put that silly my camp vs your camp crap behind us, ok? If you feel like attacking me, please do so on technical arguments.
|
|
|
Message #236031
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
Take my meds? If you are a testng dev then you will have possibly seen me openly admit to actually really having mental "quirks" which prevents me from interacting with you on a more loving/human level. It's called aspbergers and I'm not ashamed to admit to having it.
So, laugh all you want if it makes you feel good about yourself. Jesse... in all fairness, having Asberger's doesn't mean you get to be a jackass. It explains why you need to make more of an effort than others, I suppose -- but I'm familiar with the syndrome, as my oldest son has it.
I don't want to be condescending (yes, I know, probably too late), or I'd offer the sort of advice we were offered in trying to help my son become more socially capable. There's no doubt that it's a burden, but your behavior here does neither you nor other Asperger's sufferers any credit.
I understand the difficulties involved, but please restrain yourself somewhat on TSS, at the very least. Your overweening defensiveness is damaging the discussion and the sense of community.
I felt that Hani's comment was enlightening, honestly - it highlighted a behavior. You instantly verified the behavior in the thread. With all due respect: probably the wrong move. You're not my son, or I'd try to help you - I probably can. He exhibits many of the roots of the same behaviors you've shown here, even though Asperger's is a wide-ranging syndrome with many facets. I don't know if you have the same weaknesses he does, but you might do some credit by allowing some time for self-examination.
Asperger's sufferers tend to do really well technically, because they *focus*. (My son, in whom I am well pleased, is busy writing his own POSIX OS -- at twelve. I doubt he'll succeed, but holy moly...!) But sometimes allowing that focus free reign *hurts.* If you want to be more successful - note that I'm not suggesting you're not successful in the first place - you may want to consider tempering your natural tendencies a little.
Sorry for the advice - just that I don't allow my son to blame his behavior on Asperger's, and I hate seeing someone else who suffers it serve as a poor example.
.... incidentally, there's nothing wrong with "taking meds." One of the suggested treatments for my son was the use of some medications - which we haven't used, yet, because we'd prefer something else first. But if that's what it takes for him to be happy and able to interact well with others, we'll do it.
|
|
|
Message #236032
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back in planet earth -> this is what we actually need here
What i'm saying is that your pissing contest is totally irrelevant for the majority.
I understand it very much that people put their passion in their projects - regardless how important the topic of their discussion might be.
Though this thread is fun to read and a brilliant real life example for the Master thesis of a psychology student.
I for myself deem it a pity that in the end of this thread I still have no idea who now is the one with the biggest d**k (or the faster or better framework). Even if it may truly be irrelevant. Because in the end you all got lost in a mess of a - in the beginning very interesting - thread.
|
|
|
Message #236033
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So what are the numbers?
Lets take the "foo.bar.name" scenario for example.
According to tests by Christofer, OGNL is 15 or 9 times slower, depending on mode.
The same test by Jesse suggests OGNL 1.5 times faster in compiled mode and 1.5 times slower in interpreted one. Quite a different numbers.
Sources available for both tests. Can someone competent enough please explain
1. What results to believe.
2. What is wrong with the other test.
Thanks
|
|
|
Message #236034
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Can I get a copy of the source code used to generate your results. MVEL's are in: (SVN) https://svn.codehaus.org/mvel/trunk/src/test/java/org/mvel/tests/perftests/ELComparisons.java
I just had a look at your code to try to find out what you were doing in your tests. I hope you can manage your "copy&paste" code well. Don't you trust in the JIT capabilities of Java? :-)
Are your sure that your code does what you believe it to do? Are you capable of easily changing your tests when you realize they go wrong?
What I don't understand is that you guys praise your capabilities so much, but don't manage to keep your code clean.
|
|
|
Message #236036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back in planet earth -> this is what we actually need here
What i'm saying is that your pissing contest is totally irrelevant for the majority.
I understand it very much that people put their passion in their projects - regardless how important the topic of their discussion might be.
Though this thread is fun to read and a brilliant real life example for the Master thesis of a psychology student.
I for myself deem it a pity that in the end of this thread I still have no idea who now is the one with the biggest d**k (or the faster or better framework). Even if it may truly be irrelevant. Because in the end you all got lost in a mess of a - in the beginning very interesting - thread.
Maybe is due to my english understanding but after few posts I was no more sure about who was the "father" of what.
I always think that a certain point in the day is better to take a breadk and have good sex instead of still typing on a keyboard.
Guido
|
|
|
Message #236037
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
Ah, all of that sounds familiar.
Let's just hope that when he grows up no one posts any nasty little news items about him and then tries to reprimand him for defending himself.
..Sorry for the advice - just that I don't allow my son to blame his behavior on Asperger's, and I hate seeing someone else who suffers it serve as a poor example.
.... incidentally, there's nothing wrong with "taking meds." One of the suggested treatments for my son was the use of some medications - which we haven't used, yet, because we'd prefer something else first. But if that's what it takes for him to be happy and able to interact well with others, we'll do it.
|
|
|
Message #236038
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
Ah, all of that sounds familiar.
Let's just hope that when he grows up no one posts any nasty little news items about him and then tries to reprimand him for defending himself.
..Sorry for the advice - just that I don't allow my son to blame his behavior on Asperger's, and I hate seeing someone else who suffers it serve as a poor example.
.... incidentally, there's nothing wrong with "taking meds." One of the suggested treatments for my son was the use of some medications - which we haven't used, yet, because we'd prefer something else first. But if that's what it takes for him to be happy and able to interact well with others, we'll do it. Well, Jesse, that's always good to hope - but let's hope that his behavior doesn't provoke "nasty little news items" in the first place, and let's also hope that his reaction isn't to respond with vitriol, which would - of course - make things worse.
|
|
|
Message #236039
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Figures
Take my meds? If you are a testng dev then you will have possibly seen me openly admit to actually really having mental "quirks" which prevents me from interacting with you on a more loving/human level. It's called aspbergers and I'm not ashamed to admit to having it.
Heh, you probably wear it as a badge, because you like to think of yourself as having a high IQ/particularly skilled (despite much evidence to the contrary).
Not that I'm a mental disorder diagnosis expert, but you seem to actually have a weird form of autism (most autistic people I know have no trouble online, but fall to pieces in social situations, you seem to fall to pieces online, which is a novelty).
Still, good luck with that, and I guess you can't really be held too responsible given that your autism is the reason you're unable to have the introspection/projection required to actually understand anything anyone has said to you in this thread.
As an aside, Cameron, you'd be interested to know that Jesse is involved in Tapestry too. HWL might be a great guy, but he's useless at building a community, as evidenced by him having to take dimwits like Jesse in when many others have abandoned his pet project. He also I believe does some random shit with dojo. So dont worry Cam, you dont have much risk of running into his stuff. Tapestry just has a handful of poor bastard users who bought into it and are now stuck, nobody is switching TO it, thankfully.
|
|
|
Message #236040
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
Jesse,
I don't see how I have ever been nasty to you. I have only ever played a little game of friendly competition when it came to OGNL vis-a-vis MVEL.
I've taken a few jabs at OGNL, but I've never taken a jab at you. I've never insulted your intelligence, or lunged ad homimem insults at you in a public forum.
If your perception is otherwise, I suggest you carefully read all the correspondence we've ever had in forums.
The truth is, I think you'll find, you're the one who has always been mean sprited towards me. Yet, I have never responded in kind. I just continued to view everything at a friendly competition.
A lot of people here are trying to say something, and it's not that you're stupid. Rather, that you like to treat everyone else like they are stupid. As a result, that alienates yourself from others, and undermines what ever merit your arguments have.
Engineers are naturally proud of their work, and are often prone to tearing into others work. But most of us, it seems, manage not to take it personally, or turn it into something that is personal. That is what you seem to do in great frequency.
I don't have anything against you. In fact, when I wrote this post, I thought it would be a lot of fun.
To be fair: You've proven that MVEL's bytecode mode is not faster than OGNL's javassist based bytecode.
MVEL's reflection mode is still far faster than OGNL's reflection mode.
So we both have something we can brag about today. How's that?
|
|
|
Message #236041
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Do you know how much it would cost people performance-wise to do checks for parameters that may/may not even be needed? blockquote>
Do you know how much it would cost developers development time to do the same ?
|
|
|
Message #236042
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back in planet earth -> this is what we actually need here
What would be useful is if you'd get your big brains together, push Sun to revise Unified EL, fix what is broken and then, if you wish, make it faster at the same time.
Yes, we've been pushing Sun on this, and I believe that there is agreement to revise Unified EL in the EE6 timeframe. Certainly the EL needs stuff like:
* method parameters
* projections / collection iteration / closures (whatever you want to call it)
* better date handling
And a few other things.
However, just in case this is slipping through the cracks, its probably about time to give Bill Shannon another nudge on this issue ;-)
|
|
|
Message #236045
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Figures
Yes Hani, when it comes to being a small hurtful child you really do have me beat. I'm not as good at actual nastiness as you.
When it comes to actual software development though, I think you are a little out of your league - which I know makes you even angrier...
...blah blah blah...blah. He also I believe does some random shit with dojo. So dont worry Cam, you dont have much risk of running into his stuff. Tapestry just has a handful of poor bastard users who bought into it and are now stuck, nobody is switching TO it, thankfully.
|
|
|
Message #236046
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
No worries Chris. I hadn't taken anything you have done as particularly mean spirited - it's more all the little pot shot takers that have taken this golden opportunity to get their jabs in.
I would probably put forth the same kinds of challenges before entering in to battle in an online arena or just before getting thoroughly beaten by an older sibling - because shit talking is kind of fun sometimes so long as everyone knows that's what is happening.
Jesse,
I don't see how I have ever been nasty to you. I have only ever played a little game of friendly competition when it came to OGNL vis-a-vis MVEL.
I've taken a few jabs at OGNL, but I've never taken a jab at you. I've never insulted your intelligence, or lunged ad homimem insults at you in a public forum.
If your perception is otherwise, I suggest you carefully read all the correspondence we've ever had in forums.
The truth is, I think you'll find, you're the one who has always been mean sprited towards me. Yet, I have never responded in kind. I just continued to view everything at a friendly competition.
A lot of people here are trying to say something, and it's not that you're stupid. Rather, that you like to treat everyone else like they are stupid. As a result, that alienates yourself from others, and undermines what ever merit your arguments have.
Engineers are naturally proud of their work, and are often prone to tearing into others work. But most of us, it seems, manage not to take it personally, or turn it into something that is personal. That is what you seem to do in great frequency.
I don't have anything against you. In fact, when I wrote this post, I thought it would be a lot of fun.
To be fair: You've proven that MVEL's bytecode mode is not faster than OGNL's javassist based bytecode.
MVEL's reflection mode is still far faster than OGNL's reflection mode.
So we both have something we can brag about today. How's that?
|
|
|
Message #236047
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back in planet earth -> this is what we actually need here
I'm sorry, besides maybe Chris yours was the only actual technical discussion kind of response and I somehow completely missed it.
As far as saying expression bottle necks are the minority it is very hard for me to be sure they are/aren't because of my limited experience with anything other than OGNL.
Once you take DB access out of the picture it suddenly shows up very high in the list of naughty bottle neck culprits. I don't think I've compiled any really useful numbers to reflect the differences - but when dealing with small quantities of tens of ms at a time and having it take up at least half of that (or so), it really starts adding up.
With some sort of jit'ed solution that number goes back down to nothing. Probably not the most glamorous thing in the world to work on but we all know they are just incredibly convenient. Esp. when you don't have the benefit of a web framework that does hot class reloading of your sort of "sandboxed" web specific classes.
As far as Sun and whatever this "EL" is that you speak of I can't say I have much of a motivating reason for doing that. I saw a lot of Tapestry users complaining about OGNL perf. and then opened my big mouth on the struts dev list saying that someone could easily fix it with a little jit love - not expecting that anyone would actually allow me the chance to try it.
Beyond that ehh.....Maybe the MVEL guys will do something like that? (I do this for free still btw, what my wife calls "jerk off work" that is done for pleasure somehow. ) Not even knowing what EL is probably disqualifies me somehow anyways.
1) The official choice - 'Unified EL' - has proven to be insufficient in real life web app projects. Most critically the lack of support for method call parameters is huge problem in everyday use.
2) In the said real life web app projects the performance of the EL has never showed up in the radar when doing profiling. The performance bottlenecks are simply elsewhere. The overall performance would not change significantly if you'd replace EL with something 100X faster.
What i'm saying is that your pissing contest is totally irrelevant for the majority.
What would be useful is if you'd get your big brains together, push Sun to revise Unified EL, fix what is broken and then, if you wish, make it faster at the same time.
/Henri Karapuu
|
|
|
Message #236050
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back in planet earth -> this is what we actually need here
What would be useful is if you'd get your big brains together, push Sun to revise Unified EL, fix what is broken and then, if you wish, make it faster at the same time.
Yes, we've been pushing Sun on this, and I believe that there is agreement to revise Unified EL in the EE6 timeframe. However, just in case this is slipping through the cracks, its probably about time to give Bill Shannon another nudge on this issue ;-)
I wouldn't say the Unified EL is broken, its API is unbelievably flexible and there's room for additional [syntax] *features*, there's no reason why someone couldn't plug in any other syntax which included method params, projections, etc-- allowing frameworks to still produce/use the API assets with any syntax the end developer wants.
@see JBoss-EL.
Performance wise, there aren't any bottlenecks showing up and I don't see any reason/need for byte code enhancement here when you weigh in the pluggable resolution.
|
|
|
Message #236051
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why the vitriol?
Seriously - how did this post even make it? The wording of the post is written in such a nasty tone, I don't see how it warrants any kind of respect.
This could have been written in a much better way without personal attacks OR a childish, nasty tone. Stick to the facts, talk about your little library and performance enhancements, and that's it. Stop using a good resource for java news (theserverside) as your breeding ground for distributing vitriol.
Oh, and TSS mods - shame on you for even allowing this post.
|
|
|
Message #236052
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating the usefulness of discussions with wicket people
Jesse, don't know you, don't know the other guy.
Not interested either.
Interested in both your work though. So instead of pulling out all kinds of (for us) obscure technical arguments, decide on the testcases, write the testcode logic and each plugin in your library and compare. Done. No personal issues, either side. Don't care.
And, ah, about Cameron; he's one of the guys (the only one?) who started a library and made a zillion (or maybe just a tad less) when it was bought by Oracle. Cameron's opinion usually is very considered and respected.
|
|
|
Message #236053
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back in planet earth -> this is what we actually need here
I wouldn't say the Unified EL is broken, its API is unbelievably flexible and there's room for additional [syntax] *features*, there's no reason why someone couldn't plug in any other syntax which included method params
Well, i'v added proprietary support for method parameters back in 2005. And so have others. So what's the problem then? We have done it in different ways .. in ways that are not compatible with each other. So in effect 'unified EL' has become the most non-unified.
/Henri Karapuu
|
|
|
Message #236055
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back in planet earth -> this is what we actually need here
What would be useful is if you'd get your big brains together, push Sun to revise Unified EL, fix what is broken and then, if you wish, make it faster at the same time.
Yes, we've been pushing Sun on this, and I believe that there is agreement to revise Unified EL in the EE6 timeframe. However, just in case this is slipping through the cracks, its probably about time to give Bill Shannon another nudge on this issue ;-)
I wouldn't say the Unified EL is broken, its API is unbelievably flexible and there's room for additional [syntax] *features*, there's no reason why someone couldn't plug in any other syntax which included method params, projections, etc-- allowing frameworks to still produce/use the API assets with any syntax the end developer wants.
@see JBoss-EL.
Performance wise, there aren't any bottlenecks showing up and I don't see any reason/need for byte code enhancement here when you weigh in the pluggable resolution.
Sorry, I did not mean to imply agreement with the statement that unified EL is broken. It's not, it's merely missing some important features.
And shame on me for not plugging your work on jboss el.
|
|
|
Message #236056
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back in planet earth -> this is what we actually need here
Jesse, there is nothing wrong if you spend your free time helping tapestry developers to get more performance, i'm not criticizing that.
But the situation is getting difficult .. in the trenches .NET is attacking from left, RoR is coming from below, PHP still hovers there. Our tools our broken, our tool vendors are fighting each other, our new hires are struggling with the complexity. Considering this, i'm not worried about milliseconds.
/Henri Karapuu
|
|
|
Message #236057
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back in planet earth -> this is what we actually need here
Yeah, no kidding. I've been living this sort of double life for a while - where ajaxian.com is what this place is to them.
In that world people are mostly civil to each other, the most bitter of enemies are still able to take time out and praise each other for their accomplishments and the community overall seems to still act as one with a sort of general unspoken common goal in mind.
It's a real treat from the tiresome ignorance/meanness often found here. I'm not sure what people can do about it, but I secretly hope mr. yeggae succeeds in his efforts - even if it means my current work is made redundant somehow.
but...we musn't speak of this now. All is well and java and the community it fosters is great.
..But the situation is getting difficult .. in the trenches .NET is attacking from left, RoR is coming from below, PHP still hovers there. Our tools our broken, our tool vendors are fighting each other, our new hires are struggling with the complexity. Considering this, i'm not worried about milliseconds.
/Henri Karapuu
|
|
|
Message #236064
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thanks for the yucks boys
Never in all my life have I so thoroughly enjoyed a thread, the original topic of which I could barely care less about. Kudos! LOL
Seriously... seems like OGNL and MVEL both perform pretty well, and are improving over time... the rest is just noise... although very entertaining noise on a lazy Sunday afternoon when I should be doing some actual work ;)
|
|
|
Message #236071
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Sorry for TSS
That's a very pity to see such threads on TSS. I don't know where editors of TSS are looking to but probably to INFOQ :)
Such kinds of posts are having many replies but really, really no point. Meaningless competition with personalities involved, that's really a shame for TSS (I remember thread "Why I don't need Spring" or kind of, the same story there).
What was also very disappointed for me is that community of TSS is also involved, and even such respected as Cameron Purdy, which I haven't expected to see in such discussion involved, but...
For me such posts is real sign that TSS is dead or very close to it.
|
|
|
Message #236073
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Don't switch to WRap! Switch to my Tapestry Fork!
Hey, T5 is cool, Wrap is also Cool!
But I have a fork that uses Wrap and T5 and extract everything best from them!
Switch to my framework instead!!!
Switch to CRAP! Check out my JPA/Hibernate/JTA/JMS/JMX/JAXB/JAXM/OSGI inetgration!
|
|
|
Message #236076
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back in planet earth -> this is what we actually need here
I always think that a certain point in the day is better to take a breadk and have good sex instead of still typing on a keyboard.
Guido
Thanks, Confucius
:)
|
|
|
Message #236078
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
Well, I have to say that 'news items' like these are of dubious value, and could be left out. I am sure people who allow these posts to go up know exactly what to expect. You ordered blood and you got it, so do not act surprised or try to stay on the moral high ground. You have nothing to stand on.
-1 to Server Side.
|
|
|
Message #236097
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evaluating OGNL 2.7 vs. MVEL 1.2pre0 - Kuhnert's Challenge
I always think that a certain point in the day is better to take a breadk and have good sex instead of still typing on a keyboard.
Guido
So, that's only true at a *certain point* in the day?
I can't speak for anyone else, but I'll take a break for good sex *ANY* time of day!
Hell, I'll even take a break for *BAD* sex any time of day because, much like pizza, even when it's bad, it's still pretty good (Papa John's and Rosie O'Donnell being the obvious exceptions).
|
|
|
Message #236119
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Figures
Tapestry does have its share of problems as outlined by Dhanji. Also HLS and JK are not the most ideal stewards but...
Tapestry still beats all other HTML based Frameworks and lead the way in creating easy HTML web components. Facelets improved JSF by borrowing heavily these same Tapestry concepts.
Populaity does not equate to quality. Struts was hugely popular but was a waste of space. Many on this thread lack objectivity.
|
|
|
Message #236170
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why so much anger here?
Why is there so much anger and insults in this thread?
I think Jesse is a very good OS contributor, I appreciate his work on tapestry. He is a *real* contributor to many projects, not just a community activist.
I believe, Tapestry is a very good framework, many concepts are very well thought. Jesse work on Tapestry 4.1 is brilliant on the AJAX side. And HLS work on Tapestry 5 is terrific. You can disagree in the details, but the main design concepts make it the best web framework.
It is nice to have a better performance with OGNL, but I seriously don't understand why OGNL vs MEL has to be such a war zone. What Java needs is a unified, maintained and fast EL... It is nice if one framework can have few ms here and there but what is the sense?
I'm supporting a major website written with Tapestry 4. We have been using Tapestry 4 successfully for many years and over the years, I find the maintenance very satisfactory. OGNL hasn't been too much of a concern so far, the real ms are from the database and queries. However I plan to give a try to the new OGNL.
Henri
|
|
|
Message #236172
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why so much anger here?
It is nice to have a better performance with OGNL, but I seriously don't understand why OGNL vs MEL has to be such a war zone. What Java needs is a unified, maintained and fast EL... It is nice if one framework can have few ms here and there but what is the sense
Henri
http://weblogs.java.net/blog/jhook/archive/2006/11/el_comparisons_1.html
It's over a year old, but it does show (outdated) performance and feature comparisons between OGNL, MVEL, and the standard, unified EL within Java EE 5.
|
|
|
Message #236175
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why so much anger here?
Jacob,
I'm sure there are many practical/other reasons why you/sun shouldn't - but just in case I think it's fair to say that the invitation to hack away on OGNL is always open as well..
It's not like I created the library or know very much about EL's anyways....i just hacked on ognl to get the perf stuff until it worked. =p
http://weblogs.java.net/blog/jhook/archive/2006/11/el_comparisons_1.html
It's over a year old, but it does show (outdated) performance and feature comparisons between OGNL, MVEL, and the standard, unified EL within Java EE 5.
|
|
|
Message #236179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why so much anger here?
Why is there so much anger and insults in this thread?
Look at this exchange:
(Jesse in reply to Christopher)
Do you just enjoy being wrong? Retreat man, retreat...
You don't/aren't supposed to pass in a null OgnlContext (though I guess in many expressions you probably could).
(to which I replied)
You might as well state that in the Javadocs.
I would be very interested to learn what on earth is wrong or non-technical about that reply in the context of this discussion, and why you think Jesse's reply was anything other than outrageous.
He is a *real* contributor to many projects, not just a community activist.
That remark is insinuating. It's an indirect attack against anyone who said 'poo' against Jesse here and it carries the implicit message that only *real* contributors (of *really* important projects?) are worth listening to.
But let's just end this. The point has been made in this thread. The new OGNL and MVEL hardly differ performance-wise if you use it in the right way. Christopher had the chance in this thread to defend himself and MVEL against Jesse's public attacks earlier, and Jesse was able to prove that OGNL didn't perform as bad as Christopher's early tests indicated.
|
|
|
Message #236183
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why so much anger here?
Jacob,
I'm sure there are many practical/other reasons why you/sun shouldn't - but just in case I think it's fair to say that the invitation to hack away on OGNL is always open as well..
It's not like I created the library or know very much about EL's anyways....i just hacked on ognl to get the perf stuff until it worked. =p
http://weblogs.java.net/blog/jhook/archive/2006/11/el_comparisons_1.html
It's over a year old, but it does show (outdated) performance and feature comparisons between OGNL, MVEL, and the standard, unified EL within Java EE 5.
On some of the other threads, there is a strong desire to get behind a unified EL API, I would like to see a similar birth for EL of choice as with the Script API in SE 6. As Gavin mentioned, there's interest in doing another rev of EL in order to roll in additional syntax features as offered in OGNL and MVEL. The comparison I posted shows each solution has it's pro's and with a unified API, there's choice back on the framework developer and even the end developer.
|
|
|
Message #236184
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Unified EL
Agreed. It's silly that everyone should be re-creating the same thing all over the place if it looks like a general syntax / feature set is already mostly agreed on.
I don't have a lot of motivation for doing things here but whatever I can do to help (like asking for svn commit on OGNL for you, you know - easy stuff ;) ) is yours....unified el seems like a no brainer win for everyone.
.. The comparison I posted shows each solution has it's pro's and with a unified API, there's choice back on the framework developer and even the end developer.
|
|
|
Message #236185
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why so much anger here?
That's weird, I posted a reply and then when coming back to the site later it was gone. whatever..what I mostly said was:
Agreed. A unified EL sounds like a no brainer win situation for everyone involved. If there is anything relatively easy that I can do to help this along (like asking for svn for you/others ) then I'll do my best.
My long term goals don't have me wanting to really do a whole lot with OGNL beyond minor things here and there so I'd be happy to let someone(s) more interested in taking over things more if there was interest/reason to do that.
hopefully this post won't get "disappeared" like the last one..
..On some of the other threads, there is a strong desire to get behind a unified EL API, I would like to see a similar birth for EL of choice as with the Script API in SE 6. ..
|
|
|
Message #236221
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Disappeared? Hrmmmm
Jesse, do you have the time you posted the missing reply? We might be able to track the error in the server logs if something got lost.
The editors certainly had nothing to do with it. We don't normally delete comments. In fact, I remember only one or two such removals in the past three years - I could be wrong, but that's all I remember, and I regret each one of them, even though I felt justified at the time.
|
|
|
Message #236265
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Disappeared? Hrmmmm
Thanks Joe,
It looks like it might have just been some kind of delayed processing because of high loads or something similar sounding. The original message(Message #236184) was immediately visible after my last posting so it looks like the system was working fine after all. (the confusion came because after the original message was posted it displayed in the article for the immediate response that I saw, but later browsing the site it wasn't visible at all)
Jesse, do you have the time you posted the missing reply? We might be able to track the error in the server logs if something got lost.
The editors certainly had nothing to do with it. We don't normally delete comments. In fact, I remember only one or two such removals in the past three years - I could be wrong, but that's all I remember, and I regret each one of them, even though I felt justified at the time.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
