2007/9/11, glassfish_at_javadesktop.org <glassfish_at_javadesktop.org>:
> 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.)
You are right, but take a look at the amount of code that is actually
not portable, it is _nothing_ (in my case, it was few lines of code)
comparing to many other different things that are not portable across
server providers. And these few lines of code do not depend on
application, so when you are forced to change server, you can just
replace this tiny module and application will continue to work.
> 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.
Hmm, this is something I was not aware of. I am sure it is easy to do
it in a way, it will be not necessary for WebStart not to re-download
same jars. You are right, this is second thing you have to worry
about.
> 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.
Well, yes, but replacing 4 jars in application when you upgrade to the
new version of server is not complicated. But you are right again, it
is another disadvantage.
> 4. No injection support, as you mentioned.
Yes, but I am thinking, the injection as it is now, is not good at
all. Maybe in tutoriall apps, but in real applications... You have
absolutely no control over it, you cannot even say to user: "Please
wait...". We are getting really negative feedback from our customer,
users really do not know if application is starting... if it crashed
or what... You start application, WebStart loads, shows login dialog
and.... waiting, waiting... waiting.... And all you see is a desktop.
I cannot even catch when password was wrong and ask user for login
again... ACC just quits and no one knows if he or she has to wait or
start application again.
This is really serious disadvantage of using ACC, there is no
workaround for it but to get rid of ACC and do it manually.
> Certainly the ACC is not perfect, but it does bring with it some advantages.
Yes, but the lack of workaround for its disadvantages is worse.
>The goal of the ACC is to ease the burden of development
> [...] And, in my experience anyway, most developers want to focus
> on the business logic in their application rather than the infrastructure.
1000 x [yes!], but what to say to the angry customer?
>We have our sights set on major improvements in the footprint
> (which directly affects the launch and start-up time) in V3.
That is great, but V3 will not be production ready anytime soon :(
I am not saying ACC is all evil, but for many months I and my
co-workers, we were working really hard to finish that application, we
were doing really our best adding all the features required by
contract, and now there is nothing we can do but to replace ACC to get
rid of the really bad feeling, when user sits in front of his
computer, double clicks the app and look at us, as if he or she does
something wrong, because nothing is happening on the screen and we
really do not know if he mistyped a password or we just need to wait
50 seconds more to see main window.
> - Tim
> [Message sent by forum member 'tjquinn' (tjquinn)]
> http://forums.java.net/jive/thread.jspa?messageID=234911
Regards,
Witold Szczerba