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.
