You're blaming a tool for your own mistakes. That's not fair.
If you insist on this somewhat odd distribution model (where you
somehow don't trust a user when you put files in his or her settings
dir), then perhaps this scheme will work:
You have a custom installer. Make this installer write into the app
jar file a text file, probably in META-INF someplace, listing the
actual installation location. You can then read this out (via
Class.getResource) during system start, and then boot up derby,
pointing it at this location.
General piece of advice: Relying on either of the following two things
is *NEVER* a good idea. Ever. Don't write code that does this.
1. The current directory.
2. Using the resource URL hack to determine the location of your jar
file*.
Java's class loading model and file model are fundamentally not
designed to accomodate whatever you'd want to do with either piece of
information. You *CAN* use the current directory for shell-like tools,
of course. Just as long as you don't attempt to use it to load
resources.
*) This is where you use MyClass.class.getResource("/" +
MyClass.class.getName().replace(".", "/") + ".class) to get a URL,
then toString this, strip off the file:/// at the start and the '!/com/
package/MyClass.class' part, which leaves you the absolute path to
your own jar file.
On Aug 11, 10:50 pm, jahid <[email protected]> wrote:
> 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.
