DISQUS

@khalil Addressed your concerns in an updated version.

@Dave. To correct myself, I think if String.intern() is called each time a string key is used, one should get similar results without needing a Symbol class.

@Jacob. I agree with the non-warming up and the non accounting of symbol map lookup during Symbol construction time. Here's the rationale. Actually I am not so concerned with the timings for the usual (actually I should've called it identical). If a programmer can keep track of ensuring that the strings are identical - either explicitly or by always keeping a cached version of String.intern() result as suggested by Dave then Symbol class isn't really required. The 1% keeps on varying between slightly negative and slightly positive across different runs (basically the additional cost of lookup and the cached value of hashcode are being traded off with each other). Yes the test does not reflect the cost of creation of a symbol. But in most programs, the number of times symbol is created can be made to be much much lower than the number of times it is used for lookups. What you suggest of as a real world example is actually not necessarily a good real world example - since it is quite feasible to ensure that the symbols get created far less often than the getter is called.

@Dave. Have updated the post with the sources to be able to verify my findings. I missed the Strings.intern() part. I think it will certainly make for a simpler Symbol implementation. However the Symbol implementation will still be required.

@Jacob The *another* hash lookup you mention will try to check for the identity and then equality of keys. The class Symbol is constructed such that underlying strings are always identical (even if the symbol is constructed twice using two non-identical but equal strings). This is what makes the big difference.

You addressed the correct things, but dont think a “process per request” model is truely desirable. What we need is true Isolates and the MVM.

Yeah .. but where are the isolates and MVMs ? The project barcelona which researched them seems to have worked on JDK 1.3 and subsequently retired. Its newer version - project Joe declares its goal as : "Our goal is to design APIs, abstractions, and implementation techniques that allow people from all walks of computing to - figuratively speaking - spend their whole programming life without having to leave the Java platform" ... Scary !!!

If you want to get the “Strg+S…Alt-TAB…F5″ development cycle, you can use Grails. It basically combines the great ideas Rails brought to the web world with the robust libraries of the Java platform. It is truely amazing and empowers live websites with millions of page views a month (see Grails success stories).

I would love to see some metrics on how many web hosts today support shared hosting of grails applications and do so in a inexpensive and performant way. If we can host grails applications for a large number of shared tenants at comparable price and performance points achieved by PHP / Python / Ruby that would be very wonderful. If the java infrastructure can be updated to support multi tenant hosting and grails is the vehicle of losing the compile cycle and if that achieves the objectives - I am all for it.

@Pragma

Certainly an interesting idea. I am not sure about the issues that will crop up. But certainly something I will spend some time mulling over.

@eutrilla

The JEE designers have focused on making the most efficient runtime that they have negatively impacted the ability to host a large number of Java applications on a single machine. Thus if one has to host 200 java webapps on a single server (not unheard of in PHP) - this means either one tomcat with 200 web apps or potentially 200 tomcats (in case you want to isolate the various applications from each other from misbehaving runaway code). This simply will not scale for a large number of webapps. The issue is not how much data one puts into the ApplicationContext - it is the fact that the existence of the ApplicationContext requires a continuously running process (unless one were to serialise an application context just like the session context) and the fact that one misbehaving application stuffing its application context can lead to negative impact for many other shared apps. The only safe scalable way that I can think of to handle is to get rid of the ApplicationContext and any other constructs which require continuously running processes. While this is lesser efficient than the current architecture, it is more suitable for multi-tenant or cloud based processing models.

With regards to IDEs supporting it - they still require the app server (tomcat to effectively reload the webapp from scratch - this is a big time drain). If a Python / Ruby / PHP developer were to experience the time gap all you will get from him / her is a big groan.

Good to know its back. Actually I thought it was a rather innocuous article which just suddenly shot up in the viewership because of the emotive nature of the title. Of course it piqued my interest even more since it had gone offline. Good to know its back on.

Matt, Rick,

I like groovy as a language and imagine it to be quite helpful in a variety of activities to bring easy scripting to java. A good example is executing an inline groovy script through maven groovy plugin. (I would treat Rhino in a similar way).

It however seems that much of recent popularity of groovy is not because of its initial intentions (grails was nowhere on the radar then) but due to grails (This might be an interesting link : http://www.indeed.com/jobtrends?q=groovy%2C+gra... ). Now while grails might be serving its own constituency quite adequately, ruby+rails also happen to serving their base quite well. Rails is a partially disruptive development but it has helped create a large number of ruby developers. If I want something rails like I would much rather go for ror than for grails.

Java and Ruby are distinctly different languages with very different developer productivity and performance profiles Groovy to me occupies the intermediate territory between java and ruby, and given a much wider share (both in terms of momentum and actual projects / developers) of both ruby and rails, I think the software community will be served much better (Ruby not being a JSR notwithstanding), if java and ruby were made more interoperable (calling java routines from ruby methods or calling a ruby library from a J2EE app). That way I would use ruby if I wanted a really concise and powerful metaprogramming language with a framework on steroids, and Java if I wanted the entire industrial strength infrastructure that backs it up. Unless I find a reason to change my mind, I would still use groovy and js (rhino) to script in and around java for specific tooling or custom scripting - not yet to write full blown applications with.

Disclosure: I earn my bread using Java - not with ruby or groovy. - as yet I am playing around with them.