Use case: We are making a desktop application which will include
database on client side, and remote communication. We decided to use
JavaDB(Derby),  because the client does not have to install the DB,
also for reason that we have small amount to data to save on client
side. And we want our application updates/patches/releases should be
distributed by us.

Normally, thought to make the application using Swing. But the more we
tried to look into the trend, the more we found out that JavaFx is the
new technology that Sun/Oracle and others are talking about. So, we
decided to develop our desktop application using JavaFx.

But the deeper we are going, the more we are feeling like we made a
mistake. Reasons are -

1) JavaFX is tightly coupled with JNLP. If we distribute our
application without JNLP then use have to download JavaFX runtime. But
if we distribute with JNLP then, JNLP downloads JavaFX runtime. And we
do not want to ask our customers to download a new piece of software
for us.

2) Since, JNLP is tightly coupled, we thought to move forward with
JNLP. Then more problem pooped up. As I mentioned on our use case, we
want to ship our code, but do not want JNLP to download our jars from
any remote location. But still we have to write our jar location as an
URL. Now, even though all files are already locally installed still
JNLP copies those jars to sandbox before launching the application.
And that makes starting of the application slow.

3) Since the application will run from the sandbox, it looses its
context location (by context location I mean, the folder which
contains the jars, and other folders like db, icons, properties, etc).
And there is no way you can pass the location to application when you
are running through the JNLP. So there is no way, we can tell our
application where the DB is located when you run the application any
time after the first installation.


So, the point I am trying to make is, JavaFX is a nice technology, but
still its not ready for desktop application. And the funny thing is,
Sun/Oracle is not saying that anywhere. Which is misguiding. Its good
for jar distribution which is located on remote server, but not for
desktop application when jars are already co-located.

If anyone has any suggestion or solution to any of these problems,
please let me know.

Regards,

Jahid

-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to