There are advantages and disadvantages to taking on more of the infrastructure load yourself. You have mentioned some of the advantages.
Here are some of the disadvantages.
1. Your solution is no longer portable. (Although it's true that the automatic Java Web Start support is also not portable. But support for app clients is mandated by the Java EE spec and it is possible and encouraged to write portable app clients.)
2. Each separate Java SE client you create this way will have its own copy of the GlassFish JARs, unless you become even more involved with sharing those JARs across multiple clients. And, again, unless you do that you cannot take advantage of Java Web Start's caching of the JARs that do not change from one build of the client to the next.
3. The developer must handle changes in the required JAR set from one release of GlassFish to the next. Using ACC (with or without Java Web Start) GlassFish will make sure that is taken care of automatically.
4. No injection support, as you mentioned.
Certainly the ACC is not perfect, but it does bring with it some advantages. The goal of the ACC is to ease the burden of development and, through Java Web Start support in GlassFish, the distribution and launching of app clients. We have our sights set on major improvements in the footprint (which directly affects the launch and start-up time) in V3.
And, in my experience anyway, most developers want to focus on the business logic in their application rather than the infrastructure. Of course if GlassFish's ACC implementation is not taking care of the infrastructure adequately for some people, they have alternatives as you've outlined. Ideally, ACC will improve to the point that very few if any developers want to roll their own infrastructure.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=234911