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.
