4

I have an application that I developed/tested under 32bit Win (XP and Win7) and eclipse (indigo). I deploy the application using File->Export->Runnable Jar (with "package required libraries into generated JAR"). From there I wrap it into an executable.

I recently noticed that my application can not be closed (by neither the "top right X" nor alt+F4) in 64bit Win7 (32bit Win works fine). I started playing arround in 64bit Win7 and found out, that when started from eclipse, I can close the application. After I exported it into a runnable jar, I can not close it. Every other part of my application works fine (also under 64bit Win7).

I have a shutdown hook running like this:

// initialize JFrame frame;
frame.addWindowListener(new WindowAdapter() {
    public void windowClosing(WindowEvent e) {
        closeApplication();
    }
});
frame.setVisible(true);

public void closeApplication() {
    while (ConnectionManager.isConnected())
        try {
            ThreadManager.addMeasRequestPriority(eMeasRequest.DISCONNECT);
            Thread.sleep(100);
        } catch (InterruptedException e) {}
    ConfigurationManager.saveToXML(new File("ressources/settings/startup.xml"));
    System.exit(0);
}

I noticed that the GUI is disconnecting, but nothing more (but this means, that closeApplication() is entered). The problem is that I don't have the System.out when I am not running it in eclipse, so I can not see if there is any exception or what is going on. Do you have an idea how I could find the problem (or already know the problem)?

Possible candidates:

  • System.exit(0) has a different behaviour under 64bit (why would that be and is there an alternative?)
  • I can not create/write to the given file startup.xml (how can I check that?)
  • A tiny dwarf inside my 64bit Win7 laptop short circuits some stuff on the motherboard with his iron hammer and thus prevents the application from closing (how could I remove him?)
  • other

I would appreciate it if you could either tell me, whats going on here or how you would proceed to find out more.

EDIT: Thanks for your fast replies. I have found out, that I get the following exception:

java.io.FileNotFoundException: ressources\settings\startupPlot0.apph (Access denied)
  at java.io.FileOutputStream.open(Native Method)
  ...

But how can this be? This file definitely exists and is written to in non-64bit Win. Also, there are other files in the same directory that are written to just before the exception occurs on that file. They work (I just checked them). The only difference: For the other files, I use a new OutputStreamWriter(new FileOutputStream(File file)) for the other files and a new DataOutputStream(new FileOutputStream(File file)) for this one.

brimborium
  • 9,362
  • 9
  • 48
  • 76
  • can you launch the jar from command line and view ouput using java -jar program.jar? – barbiepylon Jul 13 '12 at 13:31
  • 1
    Is it possible some other process has a lock on that file? I've also seen weird permissions-related issues when running programs from the command line in Win7 vs. launched from the Explorer. I think Win7 defaults to run command-line processes with reduced, non-admin permissions or something, and fixing this requires fiddling in some advanced properties dialogs. – Alex Jul 13 '12 at 14:48
  • @Alex Nope, I checked that. I can also read from it (I load the plots from it on startup, which works). I just can write to it (i.e. open a `FileOutputStream`)... – brimborium Jul 13 '12 at 14:57
  • 1
    As a last resort, you can try right-clicking the directory in Explorer, going to the Properties -> Security tab, and grant every user full control on that directory plus all sub-directories. If that doesn't fix your problem, I'm out of ideas. – Alex Jul 13 '12 at 15:02
  • @Alex Thanks for the suggestion. I tried it, but it didn't help. :( – brimborium Jul 13 '12 at 16:11
  • @brimborium If you haven't gotten an answer to this yet, I would recommend strting a bounty. If you have found the issue, please post the answer so we understand what the issue was – Matt Westlake Jul 16 '12 at 17:08
  • @MattWestlake I have actually thought about reformulating the question because I have circled in the problem quite a bit because of this question here. The bounty would be also an option. – brimborium Jul 17 '12 at 07:24
  • Ok, I finally figured it out. I had nothing to do with java. I had no admin rights on the particular win7 user account (who the hell creates non-admin users on their private laptops? ^^). I now garnished my Launch4J executable wrap with a manifest demanding admin rights. That works perfectly. – brimborium Jul 19 '12 at 15:19

2 Answers2

3

I can verify that system.exit(0) works on 64 bit systems. If I had to guess, My answer would be that you are not disconnecting and you're throwing your Interupted Exception.

My recomendations: Put a system.out.print statement in your catch statement to see if you are catching.. If you are, you know you're problem, if not, you're not disconnecting and sitting in the while loop.

edit: try

FileOutputStream fos = new FileOutputStream("t.tmp"); // t.tmp is the directory&file name
ObjectOutputStream oos = new ObjectOutputStream(fos);
Matt Westlake
  • 3,499
  • 7
  • 39
  • 80
  • Good idea, the problem was not the disconnect (that works fine), but some access permission on a file (see my edit). I can not think of anything, why this should not work... – brimborium Jul 13 '12 at 13:57
  • 1
    add an if statement to your file location that reads if(!file.exists()) then file.makedirs() that makes sure the directory exists before you try to write anything to it. – Matt Westlake Jul 13 '12 at 14:39
  • I just did that and it told me that the file exists. I still get the exception when accessing it though. – brimborium Jul 13 '12 at 14:55
  • 1
    can you double click on the file to open it up in a reader? If so, can you edit the file? – Matt Westlake Jul 13 '12 at 15:27
  • Yes I can open it, edit it, etc. I can also read it from the application, I just can't write to it. Very strange... – brimborium Jul 13 '12 at 16:12
  • @brimborium just noticed this (can't believe I didn't see it before). You are disconnecting from the ConnectionManager and then trying to use it to save the XML. Maybe not but that's what I'm seeing. Edit: you said this works with 32 bit OS so that cannot be the issue. – Matt Westlake Jul 13 '12 at 16:31
  • Sorry for the delay (weekend ^^). To your edit: I will try it shortly. Thanks for the suggestion. – brimborium Jul 16 '12 at 09:14
  • The problem remains, I think it has nothing to do with the `DataOutputStream/ObjectOutputStream` but with the `FileOutputStream` that can not access the files... – brimborium Jul 16 '12 at 09:22
  • This is not the solution to my problem. But it helped me a lot in finding it, so here is your accept. ;) And I recommend to everyone having the same problem to try debugging it with `try/catch`. The solution for me can be found in the comment on my question. – brimborium Jul 19 '12 at 15:20
2

You can use the following to make sure you always call System.exit(0) irrespective of any exceptions:

public void closeApplication(){
        try{
            while (ConnectionManager.isConnected()){
                try{
                    ThreadManager.addMeasRequestPriority(eMeasRequest.DISCONNECT);
                    Thread.sleep(100);
                }
                catch (InterruptedException e){
                }
            }
            ConfigurationManager.saveToXML(new File("ressources/settings/startup.xml"));
        }
        finally{
            System.exit(0);
        }
    }

Though, you might also be looping infinitely in your while loop.

tom
  • 2,735
  • 21
  • 35
  • Thanks, that helped me a lot. Although I obviously have to do something about the error/exception/whatever is happening. ;) – brimborium Jul 13 '12 at 13:48
  • 1
    Well, if it exits now, you are not looping. So there is only one line that might cause an exception – tom Jul 13 '12 at 13:54
  • See my edit. There is something odd going on with file access. But it works with other files... – brimborium Jul 13 '12 at 13:58