Here’s what Sun database says about ‘losing’ the compile cycle: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4910812

In practice, there are JavaRebel: http://www.zeroturnaround.com/javarebel/features/ and Weblogic 10.3 FastSwap feature: http://www.infoq.com/news/2008/01/weblogic-tech-preview.

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.

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.

Janino is the most entertaining one. It’s amazingly fast. However, the error messages aren’t as good and some of the new language features are missing.

I used Janino for game prototyping. Together with media caching you can get “instant” turn-overs. A refresh of a simple 2D game for example took less than half a second on a 500mhz machine. Whereas the same kind of thing with javac and without media caching took over half a minute. The vast majority of the time was spent with startup (javac+java).

The biggest benefit of “full class scripting” is that you can compile it the usual way and swap the loader once everything is done.

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).

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.

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.

In JEE, Stateless Session Beans fit nicely into what you’re asking for. ApplicationContext shouldn’t have that much data, there’s just one per user session and anyway, you have to store somewhere the data to pass to the Beans, right?

To that respect you might be interested in the Project Caroline (https://www.projectcaroline.net/main/index.php?q=node/13). I just learned about this project this morning, so I don’t really know its current status, but seems to be similar to GAE.

On the second subject (the compile cycle) I can’t see the benefit. After all most IDEs do it automatically without any need of the JVM to be modified. And anyway, do you really want to see a syntax error when something is deployed?
In my experience the biggest problem is the deployment step. Being able to hot-switch class definitions without restarting your App Server is a bit time saver, and you can already do that except for inheritance hierarchy changes or modification of the list of attributes, methods or their signatures.

My biggest concerns would be start-up time (already addressed by java 6 update N), memory footprint, and maybe some way to limit the resource consumption of a module (CPU, memory, disk access, number of threads, ….), so it is easier to use in an hypothetical GAE-like environment.

An excellent idea. Could this be accomplished through a special kind of ClassLoader? I’m sure a reasonably competent developer could cobble together a proof-of-concept with some effort. Just point an environment variable to the JDK, compile your main() along with the bootstrap that sets your custom ClassLoader for the current thread, and off you go.

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).

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.

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.