I'm into a very strange issue that's making me crazy .-.
I'm working on a relatively big Java project on Windows, using NetBeans and IzPack to prepare the graphical installation package.
Everything is ok, the compiled installer seems to work and my program is copied in 'C:\Programs\MyProject' folder.
But... when I double click on the myproject.jar in that folder it doesn't start at all. I obviously tried to open a prompt and type 'java -jar myproject.jar' but nothing, not even a line of error code.
The curious facts are two:
if I open it using the prompt with administration rights it works
in the same folder there is another jar, 'uninstaller.jar' created by izpack, and it works with double click.
I double checked my JVM installation, the PATH/JAVA_HOME/... values, and Properties->Security tab of my JAR but the permissions to execute/read/write for every kind of user are ok, and also are equal to the uninstaller.
So what's the problem? Thanks
This is almost certainly caused by Windows UAC on Vista and Windows 7.
Your program is probably trying to write to data files in the same directory as it is installed.
On Windows, well behaved programs write to the users or all users app data directory.
The location of that directory varies depending on the version of Windows.
You can use the system property "user.home" to find a safe place to store data.
You can also get a list of environment variables for shared and per user program data folders from here.
Related
I try to make a setup with Inno Setup for my program.
I have installed more file XML in the same folder as the .exe. The install work well, but when I run the program and modify the XML, the file is saved in another place, not the folder of the .exe and I can't find it. I think the file is stored in the PC because the program can open it without problems.
I also try to make the same setup with InstallAware Express 7 and it works well. Io I think it's not a problem in my exe but in Inno Setup.
Thanks
I think you are a victim of Windows File virtualization.
You probably install data files to Program Files folder.
That folder is not writable (unless your program runs with elevated privileges). If your program does not have application manifest, Windows considers it a legacy application that is not aware of its inability to write to Program Files and enables file virtualization. So, when your application tries to write the data/XML files, Windows redirects the write (and future reads) to a virtual store (C:\Users\username\AppData\Local\VirtualStore). The actual files in the Program Files are not modified.
It's difficult to answer, why it works with the InstallAware Express. If you tried it after the Inno Setup, the results can be affected by an existence of the file in the virtual store.
Anyway, the root cause is that your application tries to write the files in the Program Files. That's just wrong. No application should write to Program Files.
See also Application does not work when installed with Inno Setup.
Whenever I unpack dmg installer I see image containing launcher something like - "Installer - spring-tool-suite-3.6.0.CI-B1808453-e4 ". After I try to launch this installer the loading indicator hangs a little, disappears and nothing happens. I am being forced to migrate to Mac OS due to work environment. I can't even launch the installer.
I suspect this is due to default Apple Java (whatever that means I am not OS X expert) being deleted on this laptop and JDK8 is on the home path.
ALE:~$ echo ${JAVA_HOME}
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/
Well, this forces me to migrate to IntelliJ, but I can't just believe that because of someone else fashion I can't do the work usual way...
Any hint? I don't even get error message..
Had the same issue - download .tar.gz instead of .dmg distribution. There (sts-bundle/sts-3.X.X.RELEASE/STS.app) you'll have STS.app it should run.
Since there is an interest around the question I will post the valid solution. Now what I did which caused an error - deleted default mac os java, and installed java 8 as HOME. Now Eclipse (STS, JasperSoftStudio or whatever) which was installed using dmg will look up the java not anywhere near your HOME directory. (even if it is inside Library as it should be).
Solution: Go to eclipse distribution directory (typically under applications) find the launcher, right click on the launcher, "show package contents", go to MacOS folder, open the .ini file(will have different name for different distributions) and locate -vim entry which statically points to some mac os location attempting to find java lib which is not there and never should be. Make sure your java home path is set, as now it will start to behave normally and look up home path.
If this still did not fix the issue, attempt to delete workspace folder if left from previous installation(or rename it) and play with Locked/Unlocked on the launcher properties. However the last two options are rather dances around the fire to summon spirits. The first suggestion should work 100%.
Make sure the error we are solving is something like: "Unable to locate plugin bla bla" in the error log.
All the best.
I unsuccessfully attempted to install Groovy 1.8.6 (zip distribution) on a Win XP (sp3) machine yesterday and today (the error messages stated it was unable to find the groovyStarter then I received a lengthy stack trace...). Needless to say, it was a frustrating experience. So, I decided to use the Windows installer for version 1.8.5. Groovysh functions as it should but if I write a small Groovy script and place it in a file:
println "Hello Groovy Programmer!"
...no output is displayed. Using groovy -e "println 'Hello!'" has the exact same behavior.
Any ideas of what might cause this?
Thanks.
~Caitlin
I'm not sure what you mean by "installing" the binary ZIP distribution. You don't really install anything in the usual sense of the term... you just unzip the ZIP file wherever you like. On my Windows XP laptop, I unzipped its contents into C:\groovy-1.8.6\.
I have heard some people complain of problems when they unzip into a path that contains spaces (such as C:\Documents and Settings\YourUsername\Desktop)... so perhaps that could be your issue, if you unzipped to your Desktop or something.
Just unzip the ZIP file somewhere, and add it's /bin directory to your PATH. On a Windows XP machine:
Right-click "My Computer"
Select "Properties"
Go to the "Advanced" tab
Click the "Environment Variables" button
Edit the PATH variable, and add C:\groovy-1.8.6\bin (or whatever)
The Groovy installation instructions also suggest that you add a GROOVY_HOME variable (pointing to C:\groovy-1.8.6), and a JAVA_HOME variable pointing to the root directory of your Java JDK (not the JRE located inside of the JDK). However, to be honest, I only remember to add these two environment variables half the time when putting Groovy on a a new machine, and it's never caused me problems.
With the ZIP file unzipped, and its /bin directory in your PATH, you just open a command-prompt and type:
groovy <script name>
... or, to run the GUI interface:
groovyConsole
If by chance you saw those "groovyStarter" errors because you tried to run startGroovy, then use one of the two commands above instead. The "startGroovy.bat" command is an internal script intended for indirect use through the other scripts under /bin. It will throw a java.lang.ClassNotFoundException: org.codehaus.groovy.tools.GroovyStarter stacktrace if you call it directly... because it needs one of the other scripts to set some variable prior to calling it.
Good luck!
When I run it with NetBeans it's all OK. When I copy dist directory contents and run .jar, some stuff gets buggy. Most important, JTable editing gets messy, some fields lose focus only when you hit ESC (if you did hit ENTER before, changes are accepted, otherwise they are not, but you need ESC in both cases) and similar weird stuff. I got a feeling that I'm missing something obvious...
P.S. files are compiled automatically on save (NetBeans feature) if that matters.
Edit: when I just go to dist dir and run .jar, it works too. Problems begin when I copy dist dir out of NetBeans projects dir... can it be that some dependencies get broken or something?
Edit 2 (reply):
This problem was happening in my computer (Ubuntu 9.04), in my Windows XP inside Virtual Box and in another (real) computer with Windows XP. When I run it from console with java /path/to/main.jar it throws mainClassNot found exception and does not launch at all. When I run it with java -jar /path/to/main.jar, it works of sorts, but when it comes to said situations, it throws java.lang.NumberFormatException: null.
The only place I use NumberFormat (on table update) is:
DecimalFormat parser = new DecimalFormat("0.00");
And, possibly, this:
currencyFormatter = NumberFormat.getCurrencyInstance( Locale.getDefault() );
Where default locale is set to
Locale.setDefault(new Locale("lt", "LT"));
Java version is 1.6.0_18, both JDK used by NetBeans and JVM in said machines.
In NetBeans go to your project's properties (File > Project Properties). Go to the Libraries tab. Click Manage Platforms and see the value for the Platform Folder.
From a console, run <platform folder>\java -version.
Now try it again without the full path; just java -version.
I would expect these are returning different values.
The path used by the IDE comes from the platform definition which, by default, is created when NB is installed and never updated. The path used in the console is from the windows PATH environment variable. This is updated whenever Java is installed and will, over time, diverge from the path used by the IDE.
A good rule of thumb is when Java prompts that an update is available it's time to add a new Java Platform in NetBeans.
I usually keep several platforms around. At a minimum:
latest versions of 1.4.2, 1.5.0, 1.6.0, and an old version of 1.6.0 (currently u4, the version we recommended in our first product release).
Have you tried something as mundane as making a clean build to make sure all new changes and resources are copied to the dist library?
Interesting... JAR's are stored in ZIP format, so you could try comparing the JAR that you've compiled with Netbean's JAR (if you can find it) to see exactly what is different.
Different JRE versions? That would be my guess, looking at your symptoms.
There are different ways to do this, but you could get the complete details of both the processes (one launched by NetBeans and one without) using jconsole (jdk_dir/bin/jconsole.exe). This would give you the JRE, loaded jars, etc that you could then compare...
HTH...
Here is the scenario. I have an application which writes a configuration file in its directory (user.dir). When the user cannot write to that directory due to UAC issues, I would like to change that to write to user.home/.appname/. The problem is that Windows really lies to my application and writes to user.dir which is in the Program Files directory, but although it allows the write and the read (even after restarts) it doesn't store it there, it stores it in a hidden directory (the home directory/AppData/Local/VirtualStore/Program Files/appname), making it hard/impossible for the user to find if they want to edit the file.
However, I don't want to just change my application to write to user.home and be done with it because some users run the application off of a USB drive, at which point I want to use user.dir if it is available, because it would not be helpful to leave things around the user home directory in that scenario (on a guest computer).
So after that rather long winded background, is there a way from java to know if the local directory is really truly directly writable from Java or if vista is going to instead virtualize the directory writes to another location?
This problem occurs if the Java executable is not marked as Vista compatible (using the manifest). The current release from Sun is marked as compatible. So the simplest solution is to use the latest release. This means that now neither files nor registry entries are virtualised.
Edit from author of OP:
Java 6 Update 10 (bug 6722527) added the manifest to the relevant files. Bug 6737858 addressed further issues, and is recorded as fixed in Release 12, although it is not in the release notes. For JDK 1.5, the installer was fixed in Update 11, however there will be no manifests added to the exe by Sun. You can add one yourself by putting the manifest file in the same directory as the exe if it is important enough.
After writing your file, can you just check that the file suddenly appeared in virtualized directory? I'd do a small "touch" file at app start to set a global boolean variable userUserHome.
Prepare a native EXE that loads the JVM in process (java.exe does this but you will need your own).
Add a manifest file (or in RC data) that specifies UAC as invoker.
Try writing to the folder to see if it works.
Or decide this is too much work and use a config file.