trying to open GUI Designer .form file crashes IntelliJ


I inherited a project at work where the Swing GUI was designed using IntelliJ's GUI Designer.  I have never worked with GUI Designer before, so this is a learning curve.


I know for sure that when I first was working on this project several days ago, that if I double clicked on its .form file that it would open up in a GUI builder layout window, which is exactly what I expect.  I have not, to my knowledge, ever touched the GUI code in this project.  But now, when I double click on that .form file, IntelliJ instantly totally crashes.  Same crash happens if I right click on the .form file in IntelliJ and choose Jump to Source on the context menu or if I left click on the .form file to select it and press F4. 


So, my first question is: how can I diagnose why IntelliJ is crashing?  Does IntelliJ log an error somewhere?  I tried searching my file system for files of the form *hs_err_pid* but that found nothing.


Second, concerning this particular crash...


As mentioned above, I do not think that I ever touched any of the GUI code or modified the .form file in any way.  The .form file definitely exists on my hard drive, and SVN says that it is the exact same version as in the repository, which has not changed in a couple of years.


I recently updated to the latest IntelliJ community release, 2016.1.3.  When double clicking on the .form file last worked, I think that I was using 2016.1.2.  So, did 2016.1.3 break something in this regards?  I searched the IntelliJ Issue Tracker, and did not find anything.


I have also tried invalidating my IntelliJ caches and restarting.  No dice, opening the .form file still crashes IntelliJ.


I finally note that if I run this project, the actual GUI comes up perfectly fine, which also indicates that the actual .form file must be OK.


I am really puzzled why this is happening...


Please provide `hs_err_pid*.log` files in IDEA_HOME\bin.

If you don't see them, add `-XX:ErrorFile=C:/temp/java_error_%p.log` into .vmoptions ( Make sure the specified folder has write permissions. Attach the log files after the crash.


Serge, thanks for your response.


I first note that I am running IntelliJ under the latest 64-bit JVM, as proved by this screen shot of the IntelliJ About dialog:

So, following the instructions in you support link, I added a line


to my ...\IntelliJ IDEA Community Edition 2016.1.x\bin\idea64.exe.vmoptions file.


Opening the GUI's .form file still immediately crashes IntelliJ, however, no java_error_... file is written to that Temp directory.


I tried adding that line to my idea.exe.vmoptions file as well, just to be sure, still no error file written.


I tried simplifying the line to


(as maybe the %p is problematic) and that still fails to produce a error file.


Finally, to prove that IntelliJ has write permissions to that directory, I added this line to my project's main method:

Files.write( Paths.get("C:/Temp/fakeError.txt"), "hello world".getBytes() );
It worked perfectly, writing the text file as expected.


So, I am at a total loss as to why IntelliJ is crashing and why it crashes so bad that it seemingly does not even write that JVM error file.


As stated in the document, editing .vmoptions file inside the bin folder is not recommended. If you edit is as non-admin user, the settings will not be visible to IDE. Please use IDE menu to edit .vmoptions instead. Also share your logs folder. idea.log will have the list of actual .vmoptions so that you can verify that this setting was applied.


OK, I read your support link more carefully, and this time I followed its recommendation to open the the Help | Edit Custom VM Options menu.  The file that popped up already had the line


at the end (as expected: your link says that IntelliJ should make a copy from the master version that I already manually edited).


I then tried to open the GUI .form file, and IntelliJ again immediately crashed, still no error file written.


The idea.log file, however is most interesting, thanks for pointing it out.  I have attached it.  There are 2 exceptions that seem to be related to indexing.  Given that they are logged at INFO level, I assume that they are more or less harmless.


But the 3rd Exception which starts with this

2016-06-10 12:15:33,335 [  52301]  FATAL - ral.equitycontrolgui.GetConfig - GetConfig.staticInitializer: caught an unexpected Throwable (see cause) while loading the config file config\ (The system cannot find the path specified)
    at Method)

is most interesting.  Evidently, loading the GUI .form file is triggering the class load of GetConfig, which is a custom class in this project.  A change has been made (probably by me) which causes it to not find an expected property file, so that class load fails.  This is a bug for me to fix.


That said, I think that IntelliJ has bad error handling.  A bug like this in my code should not cause IntelliJ to crash as well. 

Instead, IntelliJ should have displayed that final stacktrace to me and remained running.


Update: Serge, if you want a copy of my idea.log file, how can I deliver it to you?  I tried to do a file attachment using the picture icon, but it only allows graphics file to be uploaded.  I see no other options in the new very barebones forum options.


Maybe your custom class just calls System.exit()? That would explain why there is no crash log.


Serge, yes, the custom class does call System.exit in this case.


That said, do you agree that application code which calls System.exit should not exit IntelliJ itself?


When you run normal applications, this does not happen of course.  There must be something different in how IntelliJ loads a GUI .form file that a call to System.exit in a referenced class causes IntelliJ itself to die.


Serge: I was shocked to learn that double clicking on my project's .form file, which opens it in GUI Designer, would cause the side effect of loading other classes (e.g. the problematic custom GetConfig class you already know about).  I did not think it would do that.

I think that what is happening is that the .form file refers to named JButton fields that are defined in another class of this project, and those JButton fields have ActionListeners that ultimately cause classes like GetConfig to be loaded.

In particular, besides GetConfig, another class that gets loaded if you open the .form file is the DatabaseManager class.  The default config directory for this project is wired to tap into our prd database.  That raises the possibility that someone could double click on the .form file and then load code that could potentially modify our prd database.  Holy crap!

So, Serge, is there any documentation that you could point me to which discusses side effects of working with .form files in IntelliJ, best practices, etc?


Form class has to be instantiated by IDE so that it provides GUI designer features for the form. As there is no way to specify additional environment like working directory, it could happen that the loaded code fails in some way,

Calling System.exit() is really a poor practice and there is nothing IDEA can do to prevent that.

You have to redesign your form so that it doesn't depend on some file location in the system or so that it handles the case when it's loaded from the UI designer and not from the production app.


Please sign in to leave a comment.