5

I've been running NetBeans 8.0.2 on 64-bit Windows 7 with JDK 1.7.0_51 for some time. I recently installed JDK 1.7.0_79 and added it as a new platform in NetBeans. I would like that to also be the Default JDK, but the old way of accomplishing that - changing the netbeans_jdkhome reference in C:\Program Files\NetBeans 8.0\etc\netbeans.conf - no longer works. I've searched high and low for some other configuration file that contains a reference to the 1.7.0_51 JDK, but have been unable to find any.

Kevin Rahe
  • 1,609
  • 3
  • 19
  • 27
  • I found a way to force NetBeans to run with a different JDK, which is to use the `--jdkhome` setting on the command line as indicated [here](http://wiki.netbeans.org/FaqJdkHome). But that means manually modifying every shortcut I use to start NB. It almost looks like the installer hard codes the JDK reference into the NB binary at installation time - weird. That page also references the apparently obsolete method of making the change permanent. – Kevin Rahe Apr 21 '15 at 17:53
  • You could change the shortcut you use to start NetBeans passing the `--jdkhome` parameter on the command line –  Apr 23 '15 at 20:52

1 Answers1

3

The original method of updating C:\Program Files\NetBeans 8.0\etc\netbeans.conf to reference a new JDK continues to work. What might be happening if it appears not to is Windows holding onto two separate copies of the file - the original version and the one modified to reference the new JDK, with NetBeans reading the original version. This can happen if you try to edit netbeans.conf when the editor you use to update it is not running with Administrator privileges. This is bizarre, confusing and I dare say dangerous behavior on the part of Windows. It might even be a bug.

Kevin Rahe
  • 1,609
  • 3
  • 19
  • 27
  • Regular users not being able to write to `c:\Program Files` is **not** a bug. It's a security thing. Putting the `.conf` file into the program directory could be considered a bug. Configuration files that need to be changed by the end user don't belong there –  Apr 23 '15 at 20:52
  • just witnessed this myself: using UltraEdit the so called "uac virtualization" kicked in and the changed file ended up in `\Local\VirtualStore\Program Files (x86)\NetBeans 8.0\etc`, leaving the original file unchanged. Either use a different editor or explicitly enable rw on the file and delete the one in the VirtualStore folder – GWu Nov 15 '16 at 09:17