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...
Related
Recently i have been working with a project that requires Java 1.1 version. But whenever i try to run the
jdk-1_1_8_006-win.exe file , I have been receiving a message as shown below.
Image showing error:
After clicking ok on that:
I have seen one answer in stack overflow like
Get the Java installer files.
Execute jdk-1_1_8_010-windows-i586.exe When the error dialog is
displayed, open C:\USERS(User Name)\APPDATA\LOCAL\TEMP\~EXB0000 (Do
not click the OK button at this time) Copy all files to another folder
Click the ok button Download the tool and execute it.
Download Is3Engine.zip (ReactOS's InstallSheild Engine 3.0) Extract
Is3Engine.zip (containssetup.exe) Move setup32.exe to the copied Java
installers Execute setup32.exe
But the issue here is I am unable to find an Folder called APPDATA in my PC.
FWIW, this isn't due to AppData not being there; if it wasn't, your system would break in all kinds of weird ways. It's hidden and system, because messing with it can break it, but it's still there; you can change Explorer's settings if you really want to see it.
This error is because 16-bit software can't run on 64-bit Windows, and out of sheer inertia, the use of 16-bit installers continued all the way into the early 2000s. Windows x64 has workarounds for a few common ones, like Installshield and NSIS, but anything other than that will instantly fail.
There's really nothing you can or ideally should do other than installing it on a VM of an older system that it was meant to run on.
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 am using Eclipse Juno with Subversive plugin.
I have a java project set to compile automatically which creates a lot of bin dirs
No matter what pattern i put in window-> preferences->->team->ignored resources, eventually i see the bin dir and all of it's sub dirs in the team synchronizing perspective as new uncommitted files.
I have tried the following syntax:
*/bin,**/bin, */bin/, */bin/*
No luck.
Also, I have noticed that sometimes if I close eclipse and start it again, the ignored files disappear from the team synchronizing perspective as required, but still, some bin dirs are still present. This whole thing is very inconsistent.
Any idea ?
I have forgot to mention that I am using two worksets, one is the subset of the other, this add buggyness to the whole process appearently
Try the "Subversive SVN JDT Ingnore Extensions". It is located on the Juno Update Site, under "Collaboration". Its description says:
The feature is useful for Java development because it allows to automatically interpret output folders as ignored resources.
Seems like exactly what you want. Also, it should work independently of the name of your output folders which is an advantage if you use Maven for example (in that case, your output folders will probably be called target and not bin).
I gave up and switched to Subclipse. Now everything seems to be working fine, or at least less buggy.
What are the path variable supposed to be to ensure "javac" will work? Should it be in both system and user variables and should the "\bin" part be included?
I have a Program Files and Program Files(x86) and the JDK is in both. Which one should i use? Eclipse is working perfectly, it's only when using command line that I get this. Anyone?
Eclipse comes with its own Java compiler, it doesn't have to use an external one.
You should find the bin directory under whichever JDK you want to use and then add it to the path (I prefer the user path but, since I only ever run as one user, I'm not sure what the difference is).
And make sure it's the JDK, not just the JRE.
For example, mine is in c:\program files\java\jdk1.6.0_17\bin (32-bit WinXP).
One final thing, if you're changing the environment variables in the control panel, that won't affect cmd windows that are already open. You'll need to open up a new one to get the new environment settings (trap for wary players).
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.