Since our app is a security app, so one of the feature of our app is, it should be possible to export the app on a USB stick, and carry that with the user and use it on any computer he wants. Now consider I have taken my app on my USB and went to your computer, where there will be nothing on user.home folder if you did not install the app, so the app will fail. On the other hand, if you have installed your person app on your computer, then it will point to your own installation location and its state. So there is no way for us to load user app and its state from USB stick from another computer. This is only true for javafx, but not for swing or any other java programs. Because they always run from the current location, but not copied to a temp folder and run it from there. Now, any javafx fan might now agree that its disadvantage/problem with javafx, but still from the "java developer's" perspective is a disadvantage and they can blame for that. Even there if there were a way to pass a parameter (i mean as we do for java with -D) through jnlp then we could solve the situation. But its a shame, that there is no such opotion to pass a value to the runtime.
If still what I am talking about is not clear, then I am sorry. But if it is clear then at least its clear that javafx have that problem. On Aug 13, 4:27 am, Reinier Zwitserloot <[email protected]> wrote: > Being able to distribute your app via webstart is one of the very very > many reasons why "I'll just dump my resources in the application's own > directory" model is a bad one. It also completely breaks the mold on > e.g. linux, where apps just don't have home directories. The closest > simile to it (/usr/share/appname or /usr/local/share/appname) are only > writable by root, and are intended for read-only stuff. > > Blaming javafx for this is silly. > > On Aug 13, 3:47 am, jahid <[email protected]> wrote: > > > Reinier, > > > I see its as javafx faults, that's why I am blaming. I just can not > > understand that, being the developer, why I can not decide where I put > > my resources? Why I have to put my some specific directory (say as an > > example on user.home) to get hold of my installed directory. As long > > as runtime is there, rest of the thing should be upto the application, > > as it is from all other java application (ex. swing application). The > > developer decides where is the home directory of the application, and > > he keep all his res/db/properties on that location. And its for swing > > application, and javafx is not doing that, then why it can not be a > > fault of javafx. I looked many many forums and discussion, all of them > > are saying the same thing. Now if you do not want to accept that's > > javafx fault, then don't. But being the developer I see it as fault, > > and loading the location from other location is a "workaround". > > > >It's not javafx that runs stuff in a sandbox, it's webstart. Which you > > >want to keep using. > > > My bad, by javafx, i mean webstart in this case. > > > >I suggest you read up on how to manage resources > > >together with webstart, and if you don't want to bother with that, > > >instead, read up on the various posts in this very thread about how > > >you can legally ship JavaFX libraries with your program. > > > I have been searching forums for last 1 week. Its not only me who is > > having the problem, lots of other people are also having problem, and > > they are talking about that in the forums. > > > >Or stop insisting on a home directory for your app, which doesn't even > > >make sense on e.g. > > > I don't know why you say this. As long as you start the app with admin > > pass (ex. for ubuntu with sudo) you can decide any place where you > > want to put your app, and that place can be considered as your app's > > home dir. Look our app is a security app, where use will have their > > certificates and private keys. Loosing state of the app is loosing all > > his certificates and private keys which can't be retrieved. The main > > point I am making is, all other java app gave that flexibility of > > installing app any place you want, and run it from there as long as > > jvm is accessible. And this is the whole point I am and all other > > people who are talking in different forums are making. Indeed javafx > > is a nice technology, but still these is not solved yet. > > > On Aug 13, 2:04 am, Reinier Zwitserloot <[email protected]> wrote: > > > > Of course the RCP runs on the JVM. I have no idea why you think it > > > doesn't. Netbeans on windows is an exe because there's no such thing > > > as bash on windows. Nevertheless, it highlights the point: It's an > > > exe, not a jar. > > > > It's not javafx that runs stuff in a sandbox, it's webstart. Which you > > > want to keep using. I suggest you read up on how to manage resources > > > together with webstart, and if you don't want to bother with that, > > > instead, read up on the various posts in this very thread about how > > > you can legally ship JavaFX libraries with your program. > > > > Whatever you do, though, stop suggesting JavaFX is at fault here. > > > > Or stop insisting on a home directory for your app, which doesn't even > > > make sense on e.g. linux. On windows, use AppData. On a mac, ~/Library/ > > > Application Data. On linux, /usr/local/share/appname, or ~/.appname, > > > which is probably the best default in case you run into a somewhat > > > obscure OS, as they tend to be posixy, where ~/.appname is a decent > > > option. > > > > You can keep insisting this makes your app vulnerable, but that > > > doesn't make it true. > > > > On Aug 12, 5:32 pm, jahid <[email protected]> wrote: > > > > > Eclipse uses their own RCP which does not run on jvm. So for them it > > > > can be different case then all other cases. > > > > > On windows machine, both netbeans and idea are exe files, but not > > > > script. > > > > > Also, I am not sure why you are so up to how the resources are loaded. > > > > Because the point I was trying to make is, JavaFx runs the application > > > > on sandbox, but not on installed location. So, the application home > > > > is not present to the application when its running. That is why you > > > > can not refer to other folders of you application. For the running > > > > jars the MyClass.class.getResource(....) will always return the sand > > > > box location, because the jar is copied on sand box before execution. > > > > > On Aug 12, 3:18 pm, Reinier Zwitserloot <[email protected]> wrote: > > > > > > Netbeans, eclipse and friends use a custom executable to boot. My > > > > > eclipse for example, actually starts a mac os x native program. On > > > > > windows the same thing happens. Netbeans on my mac is a shell script > > > > > which uses some fancy bashisms to figure out where the file is (in > > > > > bash you can request your own location rather simply). All these tools > > > > > run before the JVM has even started, and thus the rule that you cannot > > > > > rely on your own jar's location don't apply. > > > > > > On Aug 12, 4:48 am, jahid <[email protected]> wrote: > > > > > > > > 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: > > > > > > > I deny that its my mistake, but I am following what is the trend, > > > > > > and > > > > > > not to teach end user a new lesson about not to delete folders from > > > > > > his home directory. I want user to use my application as like any > > > > > > other application, but not to download, or learn too many things > > > > > > (and > > > > > > remember them) for my software. Because that will push them away > > > > > > from > > > > > > my software. > > > > > > > > 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. > > > > > > > I already thought about it, but we can not do that. Doing that will > > > > > > mess up the jar signature, and webstart will not run the app coz the > > > > > > checksum will not match, since the jar is modified. > > > > > > > > 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. > > > > > > > I am trying to figure out what you mean by this part of your post. > > > > > > How > > > > > > all other software are loading their resources? I just looked into > > > > > > the > > > > > > NetBeans and IntelliJ IDEA after read your post. There are config > > > > > > files as xml files which is used by each of these IDE. How they load > > > > > > those (without current directory, or resource loading)? And why they > > > > > > fail to load the app if I take away those files? By the way, those > > > > > > are > > > > > > two Java based application I have installed on my computer. So can't > > > > > > look into more those two software. -- 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.
