• Lift creates/destroys an Actor for each Comet request. This rapid creation/destruction of Actors caused memory back-ups, and the existing Actor code seems to be oriented to long running Actors rather than Actors with Object-length lifespans.
• The FJ libraries used for Actor scheduling have problems on multi-core machines and are also a source of memory retention issues.
• Replacing the FJ libraries with a scheduler based on java.util.concurrent exposes race/deadlock conditions related to the fact that some parts of the Actor processing (e.g., testing mailbox items against partial functions while the Actor itself is synchronized)
• The Actors require external threads to function and it's not possible to create external threads in the Google App Engine (making Actor-based functionality including CometActors non-functioning in GAE apps)
• Actors are fragile when exceptions are thrown
• Actors have running and not running states (as compared with objects which can always respond to message sends). In practice, managing the running and not running states is as hard as managing memory in C.
• There are hidden actors associated with each thread which display the above fragility and state management issues
• And as a practical matter, I've got a couple of applications that are going into production over the next few weeks and cannot wait for the various fixes to make it into Scala 2.8 and the hacks and work-arounds that I've done to the 2.7.4 Actor libraries became too complex for my comfort.

{title updated}

I was talking to Miguel about the advantages and disadvantages of the CGI way of making web apps, and had in mind the yearly years of it and how alternative solutions like Java Servets proposed a much more sophisticated way to handle the emerging web application needs. Then I stumble upon a @voidspace's blog entry: Is CGI dead? and the argument of simplicity (as I remember Miguel rightfully pointed this also) was put on the table and I don't disagree at all with it. And interesting is to notice that even Java Servlets simplicity (although not as simple as the CGI protocol is) made it the very foundation of several other famous frameworks, which in the end do a lot of the dirty work that software developers used to have.

It's always the tradeoff: with a very simple (but elegant) solution you easy it's adoption, and on its solid base several other layers of software can be built, providing each one more features to the components that will lay on top.

Other good but obvious point goes to pop ups and one that I personally hate is the one described on the item 9: Drop down menus where the user needs to be very skillful in the arts of mouse maneuver.

• "it is perfectly fine to distribute your JavaFX applications, in fact we encourage it";
• "Yes, it is and the runtime will be open sourced";
• A Java FX WYSIWYG;

A new scripting language, JavaFX Script gives Java developers the power to quickly create content-rich applications for the widest variety of clients, including mobile devices, set-top boxes, desktops, even Blu-ray discs. Content creators now have a simple way to develop content for any Java Powered consumer device.

Consumers are looking for exciting, dynamic content on the Web and expecting a more interactive experience with Web services. JavaFX can help you deliver visually compelling applications, such as maps and mashups, video, audio, and pictures, that you can standardize across cell phones, TVs, and more.

... JavaFX Script will appeal to content authors because the structure of the written code closely matches the actual layout of the GUI ...

• Page Development
• Java Programming Model
• Request Processing Life Cycle
• Navigation
• Event Handling
• Component State Management
• Standard Components
• Component Development
• Validation and Conversion
• Internationalization
• Testability
• Developer Productivity
• Ease of Learning
• Industry Momentum
• Extensibility