Why would you want EL in the JDK?

Discussions

News: Why would you want EL in the JDK?

  1. Why would you want EL in the JDK? (58 messages)

    Ed Burns, in "The Case for EL in Dolphin," is asking what use cases programmers have for the unified EL from JSF 1.2 and JSP 2.0. Along the way, he offers some possibilities he's already gathered: a common bean binding mechanism, better interoperability between frameworks, and usage outside of J2EE in the first place. From his blog:
    • Make it easier for different frameworks, notably web frameworks, to interoperate
    • Make it easier to write frameworks.
    • Make performing Inversion of Control easier, reduce complexity of frameworks using IoC. IoC is not just for server apps. It can benefit desktop apps as well (look at Spring Rich Client).
    • Be the underpinning of how Beans Binding links are specified.
    • Could enable a markup based UI descriptions in Swing and allow for easily specifying links between ui components and their data models.
    • Desktop applications also have the notion of scope, but it goes beyond the normal "request/session/application", and it tends to be more specific to the application requirements itself. For example, when doing a sub-dialog, you're really entering into a scope. It would be nice to have a place to store model objects in that scope that would automatically go away when the dialog is dismissed. EL is a good way to do that.
    What other use cases could you add? What comments do you have about the ones already enumerated? (Making web frameworks easier to write seems like a bad idea, considering how many there are already.) The JDK is already going to get Javascript, JavaDB (a port of Derby), and potentially its own web server for the purpose of providing a container for JAX-WS; does it need even more?

    Threaded Messages (58)

  2. I dunno about in the JDK...[ Go to top ]

    In the past, most EL's were pretty tightly bound to their parent systems (rightly so). OGNL is perhaps the historical exception to this. But the basic fact is that when folks went looking for a problem that could be well served by an EL, they mostly likely didn't find anything floating to the top of Google, simply because they may not have thought to type in "Expression Language". They'd think more evaluations, or parsers, etc. So, I think that ELs should get more publicity, as I think there's a need for something like them when you don't want to go to a full boat scripting language. One simple case is validation expressions. That's where it came up in our shop. We wanted to do simple validation expressions for a project, we tried to keep it as basic as possible, but eventually we found we were going to have write some kind of expression evaluator, and at that point we punted and just embedded Javascript to do the work. Even though we really just wanted an EL, we ended up with Javascript. It's not a terrible decision, but if I had known more about ELs (particularly independent, easily embeddable ELs), we may well have chosen one of those instead in order to just limit the scope of what is "possible" to do in a validation. So, the question I really have tho is this. Why should an EL have any different interface to the system than any other scripting language? So, if we already have Javascript in the JDK, why do we need another EL in the JDK? If I can simply plop in the JSP EL using the JSR XYZ123 Scripting Interface, is it necessary to actually bundle the EL in to the JDK? I would argue no. But that doesn't mean I don't think that ELs shouldn't get more promotion and exposure in the large.
  3. Do I even need to respond?[ Go to top ]

    My limitless fan club should know by now the scorn I heap upon JSP, its EL, JSF that uses JSP, and the clusterfyook that is JSF/JSP server-side/client-side EL. So, anyway, back in what, 1997?, java builds this powerful, extraordinary reflection api/feature into the JDK. Call any method, instantiate any class, introspect variables! Then creates a scripting/macro language for JSPs that ignores 90% of its power. Cue velocity, OGNL (tapestry), and others that offer more comprehensive and powerful macro/data access languages. I'd say "sure, if they fix it", but Sun hasn't produced a leading, visionary, heck, they haven't even produced a competent technology design in 5 years (we'll see how EJB3 goes...). I mean, how can you make a braindead logging API that's WORSE than commons logging and log4j? Amazing. And you don't even introduce a language feature to ease the check-logging-level-before-string-concatenation problem? Sun needs to branch java. You have your C++-ish fully strong typed version, and then they need to consolidate the scripting side: JRuby, JPython, Groovy, JavaScript4Java, BeanShell...we went through this with web frameworks...which produced JSF. Hmmm. I guess in the end: Sun, leave it out, because you'll just flub it. A better strategy: provide a language hook that people can plugin in a macro language. Is that even possible?
  4. Carl, You can look at the EL-API in different perspective (one that I've been trying to promote), such that you take it as a contract whereby OGNL or JavaScript could be implemented in the API (OgnlExpressionFactory or JavaScriptExpressionFactory). Beyond that, what do you gain?
    • Common contract for creating Expressions
    • Common pluggable interface for property/variable resolution (ELResolver)
    • Concept of a context (ELContext)
    So the end result is a case where you could have an OgnlExpressionFactory, combined with a SpringELResolver chained with an JndiELResolver. The next step would be to allow other APIs to utilize this API contract such that Swing/MVC/Templating/EJB/etc could be supplemented by other expression languages and various variable spaces from your IoC containers or custom applications. I don't necessarily agree with some of the quirks of the API (could be more generic), but I do believe that there should be something like this standardized. It's much more functional than the Script API added.
  5. Re: Do I even need to respond?[ Go to top ]

    Couldn't this be built on top of JSR-232? The API already provide ways to deal with multiple interpretors, invoke functions and pass java objects to the scripting engines. Maybe an EL infrastructure could be just a thin layer over JSR-232 specifying a set of interfaces that scripting engines interested in being EL "providers" must understand.
  6. A better strategy: provide a language hook that people can plugin in a macro language. Is that even possible?
    Another reason to make it pluggable is performance. People at Wicket have replaced ONGL for this reason, they chose to create something simpler but faster.
  7. Stripes[ Go to top ]

    Latest beta of Stripes is now OGNL-free; performance was one of many reasons.
  8. Re: Stripes[ Go to top ]

    Latest beta of Stripes is now OGNL-free; performance was one of many reasons.
    What did you switch to?
  9. Re: Stripes[ Go to top ]

    Latest beta of Stripes is now OGNL-free; performance was one of many reasons.


    What did you switch to?
    Much like Wicket, Stripes now uses it's own internal implementation with a fairly small functional subset of what OGNL provides. Stripes only ever used OGNL for property binding and fetching (or, as I like to say, as BeanUtils on steroids). Stripes' own implementation is significantly faster, partly/mostly due to being fairly built for the use cases Stripes needs. But it also handles things that OGNL doesn't do so well, like dealing with complex generics (wildcards, type variales, nested parameterized types etc). -Tim Fennell Stripes: Because web development should just be easier
  10. Carl, Know that you're not alone in your lack of faith in Sun. Sun is bad for Java and therefore bad for the rest of the community. The less they do, the better. The same goes for the JCP. Everything they've produced lately is crap. The last good thing they produced was the servlet spec. Seriously, look at the list of JSRs, ask yourself these questions: #1 How many do you care about? #2 How many have been implemented (or have you noticed that they've been implemented, refer to question #1). #3 Of the ones you care about that have been implemented, how many were implemented well and/or that have lived up to your expectations? Then realize that this IS the way that the Java language and core platform evolve -- at a snails pace, too little too late with a disappointing end result. Meanwhile Sun's blowing cash on free software that nobody uses or cares about (Glassfish and NetBeans). To a loss of $800M last time I checked. Cheers, Clinton
  11. I work with Documentum unfortunately, so the prospect of a JDBC-level standardization of content repositories via Apache Jackrabbit/JSR-170 is the only JSR I've cared about in a long time. XML->objects->XML? XStream (god I love xstream for fast config file coding) object/collection queries? JoSQL ORM? Hiberate + iBATIS Basic Web Tiers? Struts (cmon people, Struts was a good half-framework) Heavy Web Tiers? Tapestry, RIFE and others are cleaner than JSF. Seriously, there are TWO ELs in JSF? RPC? take your pick of XML services or something like Burlap/Hessien App server? Spring (yes, I'm on the bandwagon now) I heard a rumor that Sun's leadership in things basically went south when they shipped development overseas. That could be usual anti-outsourcing bias. But there was definitely a point when Java's creativity fell off a cliff.
  12. My limitless fan club should know by now the scorn I heap upon JSP, its EL, JSF that uses JSP, and the clusterfyook that is JSF/JSP server-side/client-side EL.

    So, anyway, back in what, 1997?, java builds this powerful, extraordinary reflection api/feature into the JDK. Call any method, instantiate any class, introspect variables!

    Then creates a scripting/macro language for JSPs that ignores 90% of its power. Cue velocity, OGNL (tapestry), and others that offer more comprehensive and powerful macro/data access languages.

    I'd say "sure, if they fix it", but Sun hasn't produced a leading, visionary, heck, they haven't even produced a competent technology design in 5 years (we'll see how EJB3 goes...). I mean, how can you make a braindead logging API that's WORSE than commons logging and log4j? Amazing. And you don't even introduce a language feature to ease the check-logging-level-before-string-concatenation problem?

    Sun needs to branch java. You have your C++-ish fully strong typed version, and then they need to consolidate the scripting side: JRuby, JPython, Groovy, JavaScript4Java, BeanShell...we went through this with web frameworks...which produced JSF. Hmmm.

    I guess in the end: Sun, leave it out, because you'll just flub it. A better strategy: provide a language hook that people can plugin in a macro language. Is that even possible?
    Hi Carl, This post made me laugh. Reminded me of my frustrations with java over the years! I think the core of the problem lays in the JVM itself. As I understand it it is very tightly coupled to the Java language. So as I understand it getting it to run Dynamic languages is... well challenging :^). So we may require changes to the VM that aren't backward compatible, and do you see Sun doing that? The idea of a fork and a more experimental version of Java is nice, but I don't see it happening. I think back to those heady days of the mid 90's when Java was put out in a bit of a rush, and these types of issues just weren't thought of. You know what they say, act in haste repent at leisure. Not sure of the way forward. My view is to swap languages to something that is inherently more dynamic (I won't mention that language starting with R in fear of a bun fight! :^)). Another approach is the one used in Strongtalk, now owned by Sun. Strongtalk is a Smalltalk implementation where you can add type annotations. The VM is dynamic, but you can use the annotations to perform static type checking on your source code. So Sun could come up with a Java to Strongtalk bytecode compiler as the new Java; but that would mean admitting that the current Java implementation is flawed and giving up on precious backward compatibility; so I don't see them doing this either. What is most likely to happen is that they will add the odd kludge byte code here and there and think of ever more powerful wizardry tools in the same vien as JSF for us all to use. Maybe Sun should have stuck to hardware and left programming language design to others. Paul.
  13. Example ???[ Go to top ]

    Can anyone give a example of how to use the EL in a java class instead of JSP...? I have no idea.. public int firstname = ${name.firstname}; ??? I wonder if it is so verbose....
  14. Maybe it is a bit off-topic here, but really: why would you want EL in the JSP? Dmitry Coldbeans
  15. Maybe it is a bit off-topic here, but really: why would you want EL in the JSP?

    Dmitry
    Coldbeans
    I couldn't live without EL in JSP :)
  16. Because I wanna[ Go to top ]

    Maybe it is a bit off-topic here, but really: why would you want EL in the JSP?
    Because EL is an easy way to access bean data, which dynamic pages require. This was one of my biggest complaints to using struts tags in the past. Need to pass bean data to a tag attribute... not happening.
  17. What we need is plain-old-and-stupid tamplating engine that is not bound to web tier, so we can generate all sorts of textual output easier (HTML, Java code, e-mails...) It if is based on standard EL, the better! Velocity is good, but not standard, and active development of it has stopped years ago.
  18. I love groovy's native in-string macro substitution. The single-pass check can't be all that bad of a hit for those strings that don't use it.
  19. EL as in JSP/JSF is really ugly square wheel invented for no reasons at all http://forum.java.sun.com/thread.jspa?tstart=0&forumID=427&threadID=563036&trange=15 OGNL should have been adopted instead or better yet yest standard configuration hook to specify what scripting engine is used by web application and interpret expressions in the specified engine. Aside from JVM support for scripting (retention of parameter names at runtime) there is no need to invent anything or try to enforce consolidation of scripting languages for JVM.
  20. EL as in JSP/JSF is really ugly square wheel invented for no reasons at all http://forum.java.sun.com/thread.jspa?tstart=0&forumID=427&threadID=563036&trange=15
    what crawled up your ass?
    OGNL should have been adopted instead or better yet yest standard configuration hook to specify what scripting engine is used by web application and interpret expressions in the specified engine.
    Ummm.... that's what we're trying to promote here under a common api for integration.
    Aside from JVM support for scripting (retention of parameter names at runtime) there is no need to invent anything or try to enforce consolidation of scripting languages for JVM.
    There is a strong distinction here between the EL-API and the EL script syntax. The script API was added to JSE with JavaScript-- does that mean that groovy or ruby couldn't be implemented and provide the same contract in the API to allow for pluggable scripting functionality?
  21. what crawled up your ass?
    JSTL disallows direct method invocation in the expression language
  22. what crawled up your ass?

    JSTL disallows direct method invocation in the expression language
    When did they add this? EL version 3.75? JSP 5.0? Servlet spec 3.5? Bah. I know it wasn't in the earlier versions. Too late. Way too late.
  23. what crawled up your ass?

    JSTL disallows direct method invocation in the expression language


    When did they add this? EL version 3.75? JSP 5.0? Servlet spec 3.5? Bah. I know it wasn't in the earlier versions.

    Too late. Way too late.
    I'll agree that historically, the JCP process has been disappointing. But participating first hand, the only conclusion I could come to is why individuals aren't taking an active role? You have many successful open source projects out there that could be standardized/integrated and it's obvious that these successful open source projects aren't run by idiots-- so why not get involved with the JCP and take control of the situation? It's the end developers who have to deal with the ins and outs of projects on a daily basis, it's that voice that should be heard on a daily basis within the JCP-- those who have solved real world problems instead of people who's job it is "to come up with stuff". One could say there's a point where you become so far removed from the real world experience that the contributions to the JCP are misdirected and damaging to the Java platform on many levels.
  24. ...You have many successful open source projects out there that could be ...
    Please no more integration! JRE is already a behemoth. Lets have project outside of JRE and non-standardized but easily downloadable into JRE. Take GNU-Linux distros for example: Gentoo, Ubuntoo, whatever - they do not try to put everything in one hairball. But all the parts can be easily added on demand as simple as emerge artifactName What we need is Java repository ala CPAN. Please look at the vision here: http://kgionline.com/annoying/java/cjar_vision.jsp http://searchj.org/info/about/cjar_everyday_use.png
  25. JSR participation[ Go to top ]

    I'll agree that historically, the JCP process has been disappointing. But participating first hand, the only conclusion I could come to is why individuals aren't taking an active role? You have many successful open source projects out there that could be standardized/integrated and it's obvious that these successful open source projects aren't run by idiots-- so why not get involved with the JCP and take control of the situation?
    As a project lead of an OSS project, I have asked myself many times whether I should start a JSR. The answer should be an obvious YES (its a definite JDK candidate), but the reality is far more complex. Starting a JSR involves committing myself to loads of beaurocracy, hassle and politics. All in my spare time. Any of the fun of the current OSS project is taken away. As just an OSS project I can work on it when I please, as much or as little as I want. As a JSR, there are going to be many interests involved, many things to coordinate, lengthy discussions to make, perhaps expensive international phone calls, timelines, project plans... The trouble is that the JSR process gives out a non-fun, management not coding, vibe. And my skill is in coding and design, not management.
  26. what crawled up your ass?

    JSTL disallows direct method invocation in the expression language


    When did they add this? EL version 3.75? JSP 5.0? Servlet spec 3.5? Bah. I know it wasn't in the earlier versions.

    Too late. Way too late.


    I'll agree that historically, the JCP process has been disappointing. But participating first hand, the only conclusion I could come to is why individuals aren't taking an active role? You have many successful open source projects out there that could be standardized/integrated and it's obvious that these successful open source projects aren't run by idiots-- so why not get involved with the JCP and take control of the situation?

    It's the end developers who have to deal with the ins and outs of projects on a daily basis, it's that voice that should be heard on a daily basis within the JCP-- those who have solved real world problems instead of people who's job it is "to come up with stuff". One could say there's a point where you become so far removed from the real world experience that the contributions to the JCP are misdirected and damaging to the Java platform on many levels.
    My impression of the JCP is that it is dominated by corporate politics. Which produces things like EJB and JSF that are fundamentally designed to enable expensive vendor lock-in, are poorly conceived, and the like. Which is why open source projects are started, incubated, become popular, and force Sun, BEA, IBM, and others kicking and screaming from their crappy application server licenses. A little guy would just get stomped in JCP, and plus, he probably has a full-time job, unlike I'd guess some corporation sponsored "evangelists" that sit on JCP committees, write articles for magazines, blogs, etc.
  27. what crawled up your ass?

    JSTL disallows direct method invocation in the expression language
    Correct me if Im wrong, but ${foo.bar} will result in a method call to a method i.e. foo.getBar() or foo.isBar(). In addition to this you can also bind static functions to be called as a result of expression evaluation. Given the starting point for JSRs -52 and -152, i.e. to create something that would give as much power to page authors as possible WITHOUT the problems perceived with scriptlets, I think it is quite understandable that they agreed on that arbitrary method invocations in expressions wasnt necessarily a feature needed, or even wanted.
  28. EL guys... come on[ Go to top ]

    what crawled up your ass?

    JSTL disallows direct method invocation in the expression language
    JSTL disallows direct method invocations? Obviously method calls are allowed, so this must be specific to the "direct" comment. You mean being able to use something other than a non-Javabean specced method call? This annoyed me at first with our application where I'm working now, but this is a totally good thing. EL is simple, forces reasonable standards on page designs with Beans, and it's a standard. No more guessing which script engine I'm using.
  29. Re: EL guys... come on[ Go to top ]

    You mean being able to use something other than a non-Javabean specced method call?
    Yes, I mean public methods which do not conform to the bean spec.
  30. Re: EL guys... come on[ Go to top ]

    what crawled up your ass?

    JSTL disallows direct method invocation in the expression language


    JSTL disallows direct method invocations? Obviously method calls are allowed, so this must be specific to the "direct" comment. You mean being able to use something other than a non-Javabean specced method call?

    This annoyed me at first with our application where I'm working now, but this is a totally good thing.

    EL is simple, forces reasonable standards on page designs with Beans, and it's a standard. No more guessing which script engine I'm using.
    One of the benefits of standardizing the API though is that you could take a templating solution like Facelets or JSP and swap out a different EL implementation with method invocation, projections, etc-- if you so choose.
  31. Re: EL guys... come on[ Go to top ]

    JSTL disallows direct method invocations? Obviously method calls are allowed, so this must be specific to the "direct" comment. You mean being able to use something other than a non-Javabean specced method call?

    This annoyed me at first with our application where I'm working now, but this is a totally good thing.

    EL is simple, forces reasonable standards on page designs with Beans, and it's a standard. No more guessing which script engine I'm using.


    Silly developer restrictions don't solve problems. What happens is eventually ou end of with getters and setters that roll back transactions, initialize (or null) orthogonal objects, and generally do all kinds of undocumented stuff. Why does it happen? Bugfixes. Sure, it's a hack, but when you prevent access, you build cruft.
  32. Re: EL guys... come on[ Go to top ]

    What happens is eventually ou end of with getters and setters that roll back transactions, initialize (or null) orthogonal objects, and generally do all kinds of undocumented stuff.

    Why does it happen? Bugfixes. Sure, it's a hack, but when you prevent access, you build cruft.
    Well, its not like they built some prison around your bean. You can still call whatever method you want in a scriptlet. At least that will make the hacks stand out like a sore thumb.
  33. Just a hack around NPE?[ Go to top ]

    I wonder if EL is a way of working around null handling in Java. Consider the following example, which might has two potential NPEs: String city = person.getAddress().getCity(); so instead, a good developer will code: String city == null; if (person != null && person.getAddress() != null) { city = person.getAddress().getCity(); } But, the clarity of our intent is lost with the NPE checking. An EL might help here: String city = ${person.address.city}; The intent is clearer to a degree, but you need to learn a new syntax, together with its restrictions. However, I'd like to consider whether some kind of proper null handling could be introduced into the language: String city = person#getAddress()#getCity(); This would compile to the standard null checked version, so there would be no JVM changes, just javac changes. The advantage with this null handling code would be that any valid Java code could be written, and developers wouldn't need to learn a new EL syntax (and handle its oddties and restrictions).
  34. You can use the EL, for example, from apache if you need to so there is no need to have it in any Java release. Ok, EL is far from what all people want. It is certainly lacking in some ways but I really do not think it was intented to be a full expression language either. I have used it for hundreds and likely over a thousand JSP templates without really needing it to do more than it does. Sometimes I wish I could have taken a short cut, but for the most part it works in the role it is supposed to handle. And oh no, Sun has really ruined Java once again. Please, stop crying over nothing. I am just waiting for Sun to open source it all, and lets see how many complainers are actually contributing. Quite frankly, all this mouthing is a result of lack of perspective and an example of centered "cubicle thinking". If someone is doing JCP, let them do it, and who cares. Last I checked, I was free to choose anything I wanted to use. Also, quite frankly, without Sun, people would still be writing their VB spaghetti, and consuming what ever the Redmond xerox machine cares to give people to work with. And what has Java done for the open source community...the chain leads to Sun; directly or indirectly. People might say what they want but Java is quite clearly one of the most influential languages ever created. That's the perspective I am coming from. Don't get me started on R. R needs someting like S, bad.
  35. You can use the EL, for example, from apache if you need to so there is no need to have it in any Java release.
    That's very short sighted. I'm the spec lead on JSR-303 Bean Validation. A powerful EL spec would be very valuable for the Bean Validation spec to be able to build on. I built the XWork Validation Framework which is used by WebWork, and we make extensive use of OGNL there to very good effect. It's really nice to be able to specify validations quickly as a bit of EL to compare some values, for example "password == password2" when you want to check that the password and password2 fields are the same when adding a new user.
  36. You can use the EL, for example, from apache if you need to so there is no need to have it in any Java release.


    That's very short sighted. I'm the spec lead on JSR-303 Bean Validation. A powerful EL spec would be very valuable for the Bean Validation spec to be able to build on. I built the XWork Validation Framework which is used by WebWork, and we make extensive use of OGNL there to very good effect. It's really nice to be able to specify validations quickly as a bit of EL to compare some values, for example "password == password2" when you want to check that the password and password2 fields are the same when adding a new user.
    That is if there really is a burning need to have a standard JDK-wide expression language. EL would work in many occasions and I have used it in many places outside JSP, but then again I am free to swich to Groovy, Java Script, ... when I want.


  37. That's very short sighted. I'm the spec lead on JSR-303 Bean Validation. A powerful EL spec would be very valuable for the Bean Validation spec to be able to build on. I built the XWork Validation Framework which is used by WebWork, and we make extensive use of OGNL there to very good effect. It's really nice to be able to specify validations quickly as a bit of EL to compare some values, for example "password == password2" when you want to check that the password and password2 fields are the same when adding a new user.


    That is if there really is a burning need to have a standard JDK-wide expression language. EL would work in many occasions and I have used it in many places outside JSP, but then again I am free to swich to Groovy, Java Script, ... when I want.
    Well, there's a burning need if any of the JSR specs want to use an EL. We're left with either defining our own or going without, since a spec can't be built on the moving target of an opensource project. Specs with standardized hooks into an EL are better than implementations of specs which each hook into some EL (not necessarily the same one) and each do it in a proprietary way.
  38. Well, there's a burning need if any of the JSR specs want to use an EL. We're left with either defining our own or going without, since a spec can't be built on the moving target of an opensource project.

    Specs with standardized hooks into an EL are better than implementations of specs which each hook into some EL (not necessarily the same one) and each do it in a proprietary way.
    This might sound stupid but... But why would you lock yourself into EL, and I mean EL as in syntax of EL? Why not instead define a simple interface that takes parameters, the script and returns the script results? You can then switch the expression language implementation any time you like. No need to define EL in the JDK, just standardize the interface. Or was that the idea?
  39. This might sound stupid but...

    But why would you lock yourself into EL, and I mean EL as in syntax of EL? Why not instead define a simple interface that takes parameters, the script and returns the script results? You can then switch the expression language implementation any time you like. No need to define EL in the JDK, just standardize the interface. Or was that the idea?
    That is available for many years already: Beanshell http://www.beanshell.org/manual/quickstart.html#Calling_BeanShell_From_Your_Application Jython http://www.jython.org/docs/embedding.html there is eval available in Jython too http://www.jython.org/docs/javadoc/org/python/util/PythonInterpreter.html#eval(java.lang.String)
  40. That is if there really is a burning need to have a standard JDK-wide expression language. EL would work in many occasions and I have used it in many places outside JSP, but then again I am free to swich to Groovy, Java Script, ... when I want.
    Well, there's a burning need if any of the JSR specs want to use an EL. We're left with either defining our own or going without, since a spec can't be built on the moving target of an opensource project.

    Specs with standardized hooks into an EL are better than implementations of specs which each hook into some EL (not necessarily the same one) and each do it in a proprietary way.
    Not so fast. There's a fairly large gap between something being specified via JSR (being a standard in the Java world) and being included in the JDK. For example, Servlets are a standard and are controlled by JSR. We don't have to bundle a servlet container in he JDK. Yet, there are still other specifications built on top of Servlets (i.e. JSP). I'm sure there are many other such examples (how may XML related JSRs are there that aren't bundled into the JDK?). I agree that it's definitely a worthwhile effort to define the EL with a JSR, but I'm not sure I'd want it included in the JDK... -Tim Fennell Stripes: Because web development should just be easier.
  41. You can use the EL, for example, from apache if you need to so there is no need to have it in any Java release.

    Ok, EL is far from what all people want. It is certainly lacking in some ways but I really do not think it was intented to be a full expression language either. I have used it for hundreds and likely over a thousand JSP templates without really needing it to do more than it does. Sometimes I wish I could have taken a short cut, but for the most part it works in the role it is supposed to handle.

    And oh no, Sun has really ruined Java once again. Please, stop crying over nothing. I am just waiting for Sun to open source it all, and lets see how many complainers are actually contributing.

    Quite frankly, all this mouthing is a result of lack of perspective and an example of centered "cubicle thinking". If someone is doing JCP, let them do it, and who cares. Last I checked, I was free to choose anything I wanted to use.

    Also, quite frankly, without Sun, people would still be writing their VB spaghetti, and consuming what ever the Redmond xerox machine cares to give people to work with. And what has Java done for the open source community...the chain leads to Sun; directly or indirectly. People might say what they want but Java is quite clearly one of the most influential languages ever created. That's the perspective I am coming from.

    Don't get me started on R. R needs someting like S, bad.
    It's amazing how sensitive people become when you mention the short-commings in Java. The hoops you need to go through just to write out dynamic html (text). I'm sure people would solve the problems if they could (including Sun), but as I said they are a bit fundamental. The other thing people forget is that there was a thriving Smalltalk community that was killed off as a result of Java. Most jumped onboard without reading the small print (myself included). I like Java, but the truth is that it's introduction was somewhat opportunistic and I'm sure the designers of Oak never intended it to be "THE" high level enterprise application language of choice. Low powered memory limted household devices like toasters was what they had in mind. So Sun has had there battle with Microsoft for "The Server", both sides have called it a draw and now they've kissed and made up. So where does that leave us? Proliferating JSRs and kludges to deal with fundamental issues in the JVM that we know if we where to address properly would break backwards bytcode compatibility. Rather than bad mouthing alternatives, maybe it's time for the Java community to bite the bullet and fork the code - otherwise Java could end up being the most successful blip ever. Paul.
  42. The other thing people forget is that there was a thriving Smalltalk community that was killed off as a result of Java.
    It is pretty well established historically that Smalltalk (nearly) killed itself off, mainly as a result of things like the merger of Digitalk (the DOS+PC+Mac Smalltalk that was at a price that almost anyone could afford), with ParcPlace, and the slow death of the company that sold the VisualWorks (again, was available at a great price) which was then rescued by Cincom. The result of this was that for a long while quality Smalltalk was priced and licensed into a niche market tool. It is thanks to great work by people like Andy Bower (of Dolphin Smallalk) that Smalltalk is available again as a low-cost product for developing real applications (although unfortunately, only on Windows). I know it can seem politically convenient to consider Java as this great killer and stifler of other languages, but as usual, the situation is more complicated....
  43. The other thing people forget is that there was a thriving Smalltalk community that was killed off as a result of Java.


    It is pretty well established historically that Smalltalk (nearly) killed itself off, mainly as a result of things like the merger of Digitalk (the DOS+PC+Mac Smalltalk that was at a price that almost anyone could afford), with ParcPlace, and the slow death of the company that sold the VisualWorks (again, was available at a great price) which was then rescued by Cincom. The result of this was that for a long while quality Smalltalk was priced and licensed into a niche market tool. It is thanks to great work by people like Andy Bower (of Dolphin Smallalk) that Smalltalk is available again as a low-cost product for developing real applications (although unfortunately, only on Windows).

    I know it can seem politically convenient to consider Java as this great killer and stifler of other languages, but as usual, the situation is more complicated....
    Hi Steve, Ofcourse you're right. Commercial Smalltalk scored more than one or two own goals. In many Smalltalk shops Java was seen as a "good enough Smalltalk" and Smalltalk and the high licensing costs were abandoned as a result. If you believed Sun's marketing at the time you could see why people came to this view. Over the years however the compromises made in Java have become apparent, which is what I mean by "the small print". In the context of this discussion EL is just an example. How about forking the VM? What do you think? Paul.
  44. The other thing people forget is that there was a thriving Smalltalk community that was killed off as a result of Java.


    It is pretty well established historically that Smalltalk (nearly) killed itself off, mainly as a result of things like the merger of Digitalk (the DOS+PC+Mac Smalltalk that was at a price that almost anyone could afford), with ParcPlace, and the slow death of the company that sold the VisualWorks (again, was available at a great price) which was then rescued by Cincom. The result of this was that for a long while quality Smalltalk was priced and licensed into a niche market tool. It is thanks to great work by people like Andy Bower (of Dolphin Smallalk) that Smalltalk is available again as a low-cost product for developing real applications (although unfortunately, only on Windows).

    I know it can seem politically convenient to consider Java as this great killer and stifler of other languages, but as usual, the situation is more complicated....


    Hi Steve,
    Ofcourse you're right. Commercial Smalltalk scored more than one or two own goals. In many Smalltalk shops Java was seen as a "good enough Smalltalk" and Smalltalk and the high licensing costs were abandoned as a result.

    If you believed Sun's marketing at the time you could see why people came to this view. Over the years however the compromises made in Java have become apparent, which is what I mean by "the small print".
    Of course, there was no small print. The language spec and features were available up front, and Java was free to download and evaluate. Anyone who assumed that Java was like Smalltalk in all features would soon have realised it was not, in a matter of minutes, not years.
    How about forking the VM? What do you think?

    Paul.
    Fork the VM? Not the best idea I have ever heard, I have to admit, to put it mildly. Java has been perhaps the most successful languages ever partly because of its compatibility. What needs to be done is to help open the VM to enhance the performance and capabilities of additional langauges. The range of languages on the JVM is already enormous, but their implementation could be made easier. There is an increasing realisation at Sun that support for additional languages will help to increase the popularity of the Java platform. I believe that a JVM that is both open sourced and has good support for more dynamic languages and dynamic features would be unstoppable, and this would not require any forking of the JVM.
  45. The other thing people forget is that there was a thriving Smalltalk community that was killed off as a result of Java.


    It is pretty well established historically that Smalltalk (nearly) killed itself off, mainly as a result of things like the merger of Digitalk (the DOS+PC+Mac Smalltalk that was at a price that almost anyone could afford), with ParcPlace, and the slow death of the company that sold the VisualWorks (again, was available at a great price) which was then rescued by Cincom. The result of this was that for a long while quality Smalltalk was priced and licensed into a niche market tool. It is thanks to great work by people like Andy Bower (of Dolphin Smallalk) that Smalltalk is available again as a low-cost product for developing real applications (although unfortunately, only on Windows).

    I know it can seem politically convenient to consider Java as this great killer and stifler of other languages, but as usual, the situation is more complicated....


    Hi Steve,
    Ofcourse you're right. Commercial Smalltalk scored more than one or two own goals. In many Smalltalk shops Java was seen as a "good enough Smalltalk" and Smalltalk and the high licensing costs were abandoned as a result.

    If you believed Sun's marketing at the time you could see why people came to this view. Over the years however the compromises made in Java have become apparent, which is what I mean by "the small print".


    Of course, there was no small print. The language spec and features were available up front, and Java was free to download and evaluate. Anyone who assumed that Java was like Smalltalk in all features would soon have realised it was not, in a matter of minutes, not years.

    OK, but a lot of people thought it was going to be "good enough". I know you disagree, but Java is struggling after only 10 years. C++ does what it says on the box. No thrills, low level and highly optomised for speed. The Dynamic languages have clearly staked out their ground: increased abstraction and developer productivity. Java sits uneasily in between the two.
    How about forking the VM? What do you think?

    Paul.


    Fork the VM? Not the best idea I have ever heard, I have to admit, to put it mildly. Java has been perhaps the most successful languages ever ...
    What does this mean? VB had way more users and look what happened to that. How are you measuring success?
    What needs to be done is to help open the VM to enhance the performance and capabilities of additional langauges. The range of languages on the JVM is already enormous, but their implementation could be made easier. There is an increasing realisation at Sun that support for additional languages will help to increase the popularity of the Java platform.

    I believe that a JVM that is both open sourced and has good support for more dynamic languages and dynamic features would be unstoppable, and this would not require any forking of the JVM.
    OK, but everything I've read on the subject by people who have actually tried to port languages to the JVM has said it is near impossible (assuming you want comparable to native performance of course). Apparently the JVM is even worst then the CLR in this regard. Sun may be slow in promoting the JVM as a common language runtime because they know the difficulties too. Time will tell, but I'm not putting my faith in an eweek article :^). Paul.
  46. I know you disagree, but Java is struggling after only 10 years.
    Yes, I certainly do disagree, so I doubt there is much point in debating further. I don't think we are even using the same language.
  47. It's amazing how sensitive people become when you mention the short-commings in Java. The hoops you need to go through just to write out dynamic html (text).
    My sensitivity has nothing to do with shortcomings of Java. I work with Java every day, so I am pretty much aware what's involved there. I am just pointing out that bashing Sun is quite unreasonable. A lot of it seems to do with hind sight and other questionable criticism. Sun included, I don't think anybody expected Java to become what it is today. So what if the language was meant for toasters - so what if the toasters are, well, bigger toasters that sit in the server room. It is quite undeniable, however, that Sun's influence is the key thing of making a little toaster language huge. It just underlines the required incredients for success, which many other languages can not and will not have regardless of their merits.
  48. It's amazing how sensitive people become when you mention the short-commings in Java. The hoops you need to go through just to write out dynamic html (text).


    My sensitivity has nothing to do with shortcomings of Java. I work with Java every day, so I am pretty much aware what's involved there.

    I am just pointing out that bashing Sun is quite unreasonable. A lot of it seems to do with hind sight and other questionable criticism. Sun included, I don't think anybody expected Java to become what it is today. So what if the language was meant for toasters - so what if the toasters are, well, bigger toasters that sit in the server room. It is quite undeniable, however, that Sun's influence is the key thing of making a little toaster language huge. It just underlines the required incredients for success, which many other languages can not and will not have regardless of their merits.
    You are right, Sun are not to blame. We are to blame if anyone. I'm merely making the point that the whole issue of how to do templating stems from limitations in the language. The question is what to do? There were better technical alternatives to Java at the time IMO (Strongtalk, bought out by Sun and buried in 1996 is one such example!), but as is often the case superior marketing and packaging rather than technical excellence won the day (VHS versus Betamax). It would be a brave move on Suns part if they did fork the language (as suggested by Carl earlier), and with a fresh run at the VM Java could be given a new lease of life. As it stands, I see Java boxing itself into a corner. Paul.
  49. I don't want another 'EL' at all. Near the top of my long list entitled 'Things I Least Want To See In Java' is this item : 4) Another small proprietary psuedo-language Please, gently remove your heads from your butts and build an IDE that works as well as Visual Studio .Net for, for instance, creating user interface on the Web. If you want to create a 'EL' to use internally to facilitate that task, go ahead. Just don't tell me about it, and don't clutter your technology with yet another low-margin hack you require me to learn. Hide that, make it look simpler. It's about being productive quickly, it's about tools usability. Why is that so hard to understand ? I'm not just trolling here ("not that there's anything wrong with that !"). Get this done, and you will recover 'mindshare' with astonishing rapidity. See, a lot of people don't really WANT to use .Net ... but DO need development to be significantly easier and faster. I haven't seen much progress toward that in the last 5 years or so in the Java world.
  50. I don't want another 'EL' at all.

    Near the top of my long list entitled 'Things I Least Want To See In Java' is this item :

    4) Another small proprietary psuedo-language

    Please, gently remove your heads from your butts and build an IDE that works as well as Visual Studio .Net for, for instance, creating user interface on the Web. If you want to create a 'EL' to use internally to facilitate that task, go ahead. Just don't tell me about it, and don't clutter your technology with yet another low-margin hack you require me to learn. Hide that, make it look simpler.

    It's about being productive quickly,
    it's about tools usability. Why is that so hard to understand ?

    I'm not just trolling here ("not that there's anything wrong with that !"). Get this done, and you will recover 'mindshare' with astonishing rapidity. See, a lot of people don't really WANT to use .Net ... but DO need development to be significantly easier and faster. I haven't seen much progress toward that in the last 5 years or so in the Java world. My sentiments exactly.. Especially:
    DO need development to be significantly easier and faster. I haven't seen much progress toward that in the last 5 years or so in the Java world
    There are better ways. Researchers have known them for years. There are even ways of getting the advantages of static typing whilst still having the benefits and increased productivity of a dynamic language like Ruby. The thing is that Sun and others are Businesses, and they will deliver what the market demands. So we end up with what we deserve. Take a look at this blog by a Chief Scientist at Sun who developed the Strongtalk VM I discussed earlier which solves all of these problems and with static typing back in 1996: http://blogs.sun.com/roller/page/gbracha He says about closures in Java:
    I personally argued for adding closures since 1997/98. My blood pressure still rises measurably when I recall the response I got at the time: "Our customers aren't asking for it, so why add it?".
    Software is a very immature proffession with a lot of research and development still needed. But if we choose to select familiarity and premature standardisation over innovation and science then we will end up with what we have today: C# and Java. We decide. Paul.
  51. Formatting..
    I don't want another 'EL' at all.

    Near the top of my long list entitled 'Things I Least Want To See In Java' is this item :

    4) Another small proprietary psuedo-language

    Please, gently remove your heads from your butts and build an IDE that works as well as Visual Studio .Net for, for instance, creating user interface on the Web. If you want to create a 'EL' to use internally to facilitate that task, go ahead. Just don't tell me about it, and don't clutter your technology with yet another low-margin hack you require me to learn. Hide that, make it look simpler.

    It's about being productive quickly,
    it's about tools usability. Why is that so hard to understand ?

    I'm not just trolling here ("not that there's anything wrong with that !"). Get this done, and you will recover 'mindshare' with astonishing rapidity. See, a lot of people don't really WANT to use .Net ... but DO need development to be significantly easier and faster. I haven't seen much progress toward that in the last 5 years or so in the Java world.
    My sentiments exactly.. Especially:
    DO need development to be significantly easier and faster. I haven't seen much progress toward that in the last 5 years or so in the Java world
    There are better ways. Researchers have known them for years. There are even ways of getting the advantages of static typing whilst still having the benefits and increased productivity of a dynamic language like Ruby. The thing is that Sun and others are Businesses, and they will deliver what the market demands. So we end up with what we deserve. Take a look at this blog by a Chief Scientist at Sun who developed the Strongtalk VM I discussed earlier which solves all of these problems and has static typing back in 1996: http://blogs.sun.com/roller/page/gbracha He says about closures in Java:
    I personally argued for adding closures since 1997/98. My blood pressure still rises measurably when I recall the response I got at the time: "Our customers aren't asking for it, so why add it?".
    Software is a very immature proffession with a lot of research and development still needed. But if we choose to select familiarity and premature standardisation over innovation and science then we will end up with what we have today: C# and Java. We decide. Paul.
  52. There are even ways of getting the advantages of static typing whilst still having the benefits and increased productivity of a dynamic language like Ruby.
    Yes, there are, and some of these ways have been around for a while on the JVM, and are now official JSRs: BeanShell and Groovy.
  53. There are even ways of getting the advantages of static typing whilst still having the benefits and increased productivity of a dynamic language like Ruby.


    Yes, there are, and some of these ways have been around for a while on the JVM, and are now official JSRs: BeanShell and Groovy.
    Hi Steve, So your speaking to me a gain :^) I've left a comment on Gilads blogs asking how much head room there is in the current JVM for more dynamic features. I'm not familiar with Groovy and BeanShell so I should check them out. All reports however are that they are pretty poor in comparison to something like Python or Ruby. The invoke-dynamic byte code expected in the next JVM release may be enough. We will have to wait and see. It will be interesting to see Gilads response. Paul.
  54. Hi Steve,

    So your speaking to me a gain :^)
    Nothing personal, I just felt there was a point where I could contribute here, as these were examples. I have an on-going problem with your posts in that I often find so many issues and points I disagree with that if I reply in any detail this will require long posts, and we will probably just be going over old ground; you will start to mention Croquet yet again, and we will be nowhere :)
    All reports however are that they are pretty poor in comparison to something like Python or Ruby.
    But there you go again. Why post before you have checked them out? Groovy and BeanShell are good at what they do. BeanShell is designed to be Java; same syntax, with no added features, but dynamic - great for scripting. It is used quite a bit for that. Any idea that it is poor compared with Python or Ruby is inappropriate - it is not designed to compete with them. Groovy is a far richer language, with additional features like closures, and a clean syntax for maps and lists. Not as elegant and rich as Ruby, but it has its benefits - seamless integration with Java, allows the use of Java syntax (although not yet 1.5) and the ability to compile to class files. Combine Spring 2.0's automatic re-loading of changed scripts with Groovy and you have a very powerful, dynamic and agile way to use Java features and Java syntax for J2EE development.
  55. Hi Steve,
    Combine Spring 2.0's automatic re-loading of changed scripts with Groovy and you have a very powerful, dynamic and agile way to use Java features and Java syntax for J2EE development.
    Gilad got back to me:
    4. Paul asks if the JVM is up to supporting this. Well, without VM extensions it is rather lacking, but still doable. However, we are likely to add VM support, if any of this gets done.
    The way I read this is yes it is possible, but likely to be slow even with VM extensions. Been playing more with Strongtalk and they were experimenting with unboxed floating point "objects". Their Mandelbrot Set floating point benchmark is 2-3 times slower than C! Pretty impressive as we are talking hard core floating point arithmetic. The irony is that many of the features in Smalltalk were overlooked in Java because they were thought to be too slow. Know it looks like we are going to get these dynamic features in Java anyway, but in a less elegant and a slower form then is possible with the best Smalltalk implementatons of 10 years ago.
    The thing is that Sun and others are Businesses, and they will deliver what the market demands. So we end up with what we deserve.
    We really need to wake up as a developer community and start thinking longer term! Paul.
  56. 4. Paul asks if the JVM is up to supporting this. Well, without VM extensions it is rather lacking, but still doable. However, we are likely to add VM support, if any of this gets done.



    The way I read this is yes it is possible, but likely to be slow even with VM extensions.
    I think that is just putting a bad spin on things. I would imagine if there was a such a penalty for features such as closures, it would have been stated.
    Been playing more with Strongtalk and they were experimenting with unboxed floating point "objects". Their Mandelbrot Set floating point benchmark is 2-3 times slower than C! Pretty impressive as we are talking hard core floating point arithmetic.
    Sorry to disagree yet again (I am not doing this deliberately!), but that isn't impressive at all. That sort of fraction of C speed is typical for most quality Smalltalks (I benchmarked exactly this sort of thing in the mid 90s, as I have an interest in numerical work), and for serious floating point work it is unacceptable. Incidentally, it one of the reasons why I would not use Java for such work for some time - even 60-70% of C/C++ performance in this area means you have to have justify using the slower language.
    The irony is that many of the features in Smalltalk were overlooked in Java because they were thought to be too slow.
    My impression from reading about language design was that they were not overlooked. There were deliberately excluded because they were considered unecessary bloat. That may look mistaken now, but much can look mistaken with 10-15 years of hindsight.
    Know it looks like we are going to get these dynamic features in Java anyway, but in a less elegant and a slower form then is possible with the best Smalltalk implementatons of 10 years ago.
    I seriously doubt that they will be slower. I don't get that impression at all from the blog entry, and I don't see why they should be anyway. They are only possibly less elegant if you don't want static typic. If you do, there is nothing particularly wrong with them - they look pretty clear.
    The thing is that Sun and others are Businesses, and they will deliver what the market demands. So we end up with what we deserve.


    We really need to wake up as a developer community and start thinking longer term!

    Paul.
    I guess I think all languages are compromises, and I disagree that Java is anything like as poor as (my impression is that) you think it is. Smalltalks were a also a compromise - they sacrificed performance for a far more dynamic nature. You make your choice about development technique and you pick your language, with its compromises. There is little that is intrinsically better one way or the other. But anyway, Java was designed for the long term - for decades of use. It was designed with as few frills and (debatably) 'superfluous' features as possible so that code can be read, and supported long-term. This was deliberate - a reaction to the code obfuscation of C and C++. There is much comment in this area that in my view is distinctly mistaken. We have heard talk of 10-year language cycles (well, Ruby is older than that, as is C++ and C). We have heard that Java has become suddenly difficult and bloated, and hard to learn, which surprises me as you can still write small Java programs just like 10 years ago, and with the same syntax. Far from struggling or plateauing, Java adoption is still increasing (albeit at a slower rate). It is easy to forget how innovative Java was, and still is. Far from being a 'rushed to market cut-back compromise', it was carefully designed over years before being released. It is worth re-reading some of the original articles and language definitions, like this. But, I guess, there is always an attraction for the new and different. Java has passed the 'wow' stage, and is perhaps less fun in many respects because of that, but that does not mean it deserves much of the current denigrating of the language that seems to be going on right now. My view is that the what is needed is for the Java language to continue to thrive and grow (as against just the JVM, which has a good future anyway) is for Java itself to become more dynamic. It looks like this is happening. Just to be provocative, but I would consider that thinking longer term would mean being extremely cautious about languages and frameworks which potentially change without guaranteed backwards compatibility - Ruby and Rails for example.
  57. Hi Steve, Gilad himself says that he thought Java should have had closures from the beginning. I've quoted the response he got from the marketing folk at Sun.
    I personally argued for adding closures since 1997/98. My blood pressure still rises measurably when I recall the response I got at the time: "Our customers aren't asking for it, so why add it?".
    IMO the Sun Engineers are good guys, but if the market doesn't demand change then Sun (marketing) aren't going to deliver it. If you read Gilads blog you will see that he is still a frustrated Smalltalk programmer at heart. So my point is simple. The onus is on us the developer community to demand change. At the moment Sun are happy playing catch-up with C#/.NET. If Microsoft weren't going all functional with C# do you think Sun would be considering closures? BTW Gilad makes the point that if closures were included from the beginning, that many of the Java class libraries would be a lot better today. Think of Swing/JFC or even Java Collections for starters. As for facts, which I know you love, here are a few: Mandelbrot Set (fractals - double precision floating point arithmetic) 200 iterations: C - 96ms Java - 109ms Strongtalk - 192ms To me Java seems excellent in this regard, don't see the need for C/C++ myself. As for Strongtalk - twice as slow as C is pretty good in anyone's book. My nervous system couldn't detect the 100ms difference put it that way :^). I'm not about justifying decisions made in the past. I'm talking about learning the leassons of history and looking to the future. IMO narrowing our options because "we can't trust ourselves" is not a future proof strategy, and the fact that Java is now back filling features that could have easily been added at the outset is testimony to this (not to mention the current implementation limitations imposed by backward-compatibility). If you are happy with your programming language direction being determined by Microsoft in Redmond then that's fine. But myself like many others on this thread feel that it is time for change. Funnily from Gilads blog it looks as though many in Sun also agree. They just need our support. Paul.
  58. Hi Steve,

    Gilad himself says that he thought Java should have had closures from the beginning. I've quoted the response he got from the marketing folk at Sun.
    You can pick any blog to back any viewpoint. Of course someone who worked on StrongTalk would most likely put forward that opinion. Others obviously thought different.
    IMO the Sun Engineers are good guys, but if the market doesn't demand change then Sun (marketing) aren't going to deliver it.
    Well that certainly isn't true. As Bracha says in that same post: "they [the market] never asked for Java or for garbage collection". Sun has always been innovative - in operating systems and software development. You can't seriously claim that the company that virtually invented the Unix Workstation and pioneered use of Open Systems is in any way restistant to change, or simply market driven - this flies in the face of years of evidence to the contrary. Sure, we may need to push if Java is going to change the way we want (I loved the Java 1.5 additions, and I like the idea of closures).
    At the moment Sun are happy playing catch-up with C#/.NET. If Microsoft weren't going all functional with C# do you think Sun would be considering closures?
    Yes, I do. I don't think what Sun does is that driven by Microsoft. To claim that Sun is 'playing catch-up with C#/.NET' is just political posturing, and not fact (if it were true, Java would have changed far more quickly!). Java is way ahead of .NET in many respects. Just look at Java's phenomenal portability.
    BTW Gilad makes the point that if closures were included from the beginning, that many of the Java class libraries would be a lot better today.
    Again, just one person's opinion. Others have different opinions.
    As for facts, which I know you love, here are a few:

    Mandelbrot Set (fractals - double precision floating point arithmetic) 200 iterations:

    C - 96ms
    Java - 109ms
    Strongtalk - 192ms

    To me Java seems excellent in this regard, don't see the need for C/C++ myself. As for Strongtalk - twice as slow as C is pretty good in anyone's book. My nervous system couldn't detect the 100ms difference put it that way :^).
    It really isn't good enough for many purposes. To give an actual example, if I wish to justify converting existing reasonably high-performance code where performance is a real issue, I can't justify this conversion (even though the target language may have other benefits) if they lose such performance - especially if the code can take hours to run. We may be talking about much more than fractions of a second! So, you can't say this is good enough in anyone's book, because you can't tell what their requirements are. For some of us, 50% of performance is poor. (And StrongTalk is only available for Windows....)
    I'm not about justifying decisions made in the past. I'm talking about learning the leassons of history and looking to the future.

    IMO narrowing our options because "we can't trust ourselves" is not a future proof strategy, and the fact that Java is now back filling features that could have easily been added at the outset is testimony to this (not to mention the current implementation limitations imposed by backward-compatibility).

    If you are happy with your programming language direction being determined by Microsoft in Redmond then that's fine. But myself like many others on this thread feel that it is time for change. Funnily from Gilads blog it looks as though many in Sun also agree. They just need our support.

    Paul.
    Again, lots of opinions here stated as if they were facts. Java at the beginning was a very different beast, in terms of performance, APIs and VM technologies. To claim now that things could have been easily supported at the start is without evidence, and to use terms like 'backfilling' is just political bias (after all, didn't you claim in an earlier post that adding them would have impacted performance?). I really feel that lessons aren't being learned. I see decades old mistakes being repeated and opinions being stated as if they were new. I hear DHH of RoR fame claim that Static Typing has few benefits in practice. Sorry, but I heard that 20 years ago from Smalltalk developers, and I saw the tangled results of that opinion many times. I hear many claim that Ruby code is beautiful and easy to read, then I encounter PERL-like coding that easily counters that attitude. These are issues that Java was designed to counter. My strongly held opinion is that "We can't trust ourselves" certainly is a very healthy and future-proofing attitude. I think it is perhaps the most important lesson that could possibly have been learned after decades of language development. I believe that no amount of testing, no amount of code analysis, and no amount of good development practice can overcome the need for clarity and safety in development, which can be provided by languages. You can get away with certain approaches at certain scales, but beyond that, there are always dangers. For example, I will be interested to see how the ability of Ruby developers to extend existing classes works out for larger scale applications, when one group's clever metaprogramming conflicts with another's. Testing for what someone else might be doing at any time to your (or other) classes is going to be.... interesting. (We have been here before, with Smalltalk, requiring the later addition of namespaces - again, have lessons been learned?) Don't get me wrong - I like Ruby, and I am using internal DSLs in JRuby to simplify various parts of my J2EE development - it is wonderful for scripting data loading (I use JRuby+JDO) and testing, for example. I just see the gradual drift towards promoting it as generally 'enterprise-ready' for major projects as wildly premature. I think we fundamentally disagree, but then, what's new? :)
  59. For those who are interested in using the unified EL (2.1) outside JSP/JSF now, consider JUEL. See also here for a recent news post.