A few things have changed when it comes to running SQL Developer on a Windows machine. In previous versions, the first thing you’d see when running SQL Developer would be a prompt asking for the location of Java.
Turns out, it’s hard for Java applications to run without Java.
On Macs and Linux/Unix environments, we don’t prompt for the location of the JDK. The OS tells us where it is. So why not do this for Windows too?
Well, for version 4.0, we’ve taken care of this.
The .EXE in the top SQL Developer directory does a few things when you run it in version 4.0:
- Is this machine 32 or 64 bit OS?
- Is Java here?
- Write the location of the JDK to the .conf file for future executions
So as long as this EXE can answer these questions successfully, you won’t see the old prompt for the JDK anymore. If it can’t, then it will ask you for some help. This will make getting SQL Developer up and running that much easier for Windows users 🙂
Now, for all time eternal, SQL Developer would look (for Windows) in the sqldeveloper.conf file to see where the JDK is installed and also where you could configure how the JVM runs with the appropriate set parameter flags.
In version 4.0, we no longer look in SQLDeveloper.conf for these specific Java flags and settings.
To accommodate shared Windows machines, we now look into the roaming profiles directory in the Application Data folder. Specifically for SQL Developer, it’s here:
Basically speaking, if you have 3 people sharing a computer, each of them can have their own settings for how to run SQL Developer.
If you open this ‘very well documented’ file, you’ll see the all-important line near the top:
If you upgrade your Java installation, you’ll need to update this file with the new location or install folder name.
A couple more notes
- The 4.0 Windows download packages will be:
- Windows 32 and 64 bit
- Windows with 64 bit JDK (Server JRE)
The Server JRE is a subset of the full JDK – but has everything we need to run SQL Developer. We’re making the Windows with Java download setup for 64 bit now as that’s the standard configuration for machines these days. This also includes Oracle SQL Developer Data Modeler.
Very informative article (as usual!)
I have many, many Java versions installed on my PC – usually to satisfy the needs of other Oracle software being certified differently.
I have been using JDK188.8.131.52 64bit with SQLDev 4.0.3 64bit for the past month. I have simply been ignoring the warning to upgrade JDK to 184.108.40.206 or later, but I have a niggling problem within SQL Developer which MOS cannot reproduce, so I am biting the bullet and upgrading to the latest JDK1.7 version for my PC, namely 220.127.116.11.
All installed successfully and swimmingly well.
Tried launching SQLDev and it still thinks I am on 18.104.22.168 (its still there, but so is 22.214.171.124).
I took your advice and went looking in C:\Users\alawlor\AppData\Roaming\SQL Developer on my Win7 PC, but I cannot find any subfolder called 126.96.36.199.0 and a full search of the contents of my drive cannot find a file called product.conf?
Am I thick or have I found an undocumented feature ?
Scrap that – I am thick.
I was looking in C:\Users\alawlor\AppData\Roaming\SQL Developer
and should have been looking in C:\Users\alawlor\AppData\Roaming\sqldeveloper
Still do not know why a windows file search did not find product.conf, though, but that is not an Oracle problem.
I am using windows server 2003 to run SQLDeveloper 4. My ORACLE DB 12c requires higher version of SQLDeveloper to connect. it is good that your article mentioned product.conf is involved. It is bad that this information is nowhere to find other than here.
Agreed 1000% – and we FINALLY have that rectified in the latest release and going forward.
I’m having a hard time with SQL Developer 4.0.3 setting up the OCI configuration. The last obstacle is “Error loading the native OCI library”
The native OCI driver could not be loaded. The system propertyjava.library.path contains the entries from the environment variable PATH. Check it to verify that
the expected native library directory C:\oracle\product\11.2.0\client_1\bin is present and precedes any other client installations.
java.library.path = C:\Program Files\Java\jdk1.7.0_67\jre\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\oracle\product\11.2.0\client_1\bin;C:\Users\sc58467\Oracle\product\12.1.0\client_1\bin;C:\oracle\instantclient_11_2;…
The thing is, java.library.path is supposed to get its value from PATH, however my PATH = C:\oracle\product\11.2.0\client_1\bin;C:\Users\sc58467\Oracle\product\12.1.0\client_1\bin;C:\oracle\instantclient_11_2;…
I can’t find a way to eliminate the references to “C:\Program Files\Java\jdk1.7.0_67\jre\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;” from java.library.path.
Any idea how to proceed from here?
I had the same problem. Turns out I was using a 32-bit JDK, and a 64-bit native library on a 64-bit Windows OS. After upgrading to a 64-bit JDK and changing product.conf my OCI configuration passed.
I need to create auto-deployment packages for both 32 and 64-bit. It looks like the 64-bit deployment will work since the jdk folder is included.
Is there anyway to include the jdk folder for the 32bit so that I can setup an auto-extract file?
Yes, just install a 32 bit JDK. Then scoop up that directory, and embed it on your SQL Dev package for 32 bit Windows.
Yeah I figured it out earlier- forgot to come back and update. Before having to install SQL Developer for people, I didn’t know what jdk, jre or this jse stuff was but I’m slowly learning!
Whatever happen to the standalone build that has the JDK/JRE bundled with it? No chance of having that back. Can’t get that portable bit trick working :(-
It never went away – it’s still on the download page.
Just want to check if I understand it correctly.
Can I run the JDK Installer, then copy the whole directory that it installed to to where I unzip SQL Developer, un-install JDK and then run SQL Developer and tell it where I copy the JAVA directory to and it should all work alright?
I believe from previous SQL Developer download, there is a with JRE and no JRE downloads. Now there is just the no JRE download 🙂
Yes, but why do you insist there is no download that includes the JDK? It’s the very first download listed, ‘Windows 64-bit – zip file includes the JDK 7’
Very much informative and helped in right time.
after extracting the sqldeveloper-188.8.131.52.21-x64.zip into c:\sqldeveloper64bit folder and i run sqldeveloper.exe it will launch an unknown app with 4 menus named GoTo, Tools, View and Window which just displays there and the Java flash window is stuck. Looks like the exe wont be be able to create the sqldeveloper folder in the Roaming folder to populate the product.conf with the java path.
You can ignore the last post. For some reason, when I extracted it, and then moved the files around, it must not have been done with the extraction process. I ended up with an incomplete installation. I reextracted everything to c:\sqldeveloper directly and it started up fine. Chalk this up to some kind of user error, though I can’t believe I would have done that.
Who knows…just happy to hear you have it up and running.
And not to mention, your article was spot on, and it worked flawlessly. I might have to think about putting TOAD aside. (did I say that?)
Yeah, I think you did!
After extracting the 4.0.2 version from OTN download (the one without the jdk), I tried to run the sqldeveloper.exe from the root, and nothing happens. I drop to DOS, run it, nothing happens. It was extracted to C:\sqldeveloper.
The JDK (full) I have installed is 1.7.0_51. This is running under Windows 7 Pro SP1. I have a java_home defined, a jre_home defined, and java.exe is located in the path at C:\java7\bin.
i was prompted to look at it based on the May/June issue of OTN for this year based on your article.
Thanks for any hints, tips, etc.
Hey Eric, thanks for the note re: the article! Feedback from those types of posts are much lighter than something like this blog, so I’m never sure how they turn out…
This with the roaming profile is OK. However, I chose a 1.6 JDK by mistake and the exe kept on presenting a dialog, that I should change the conf in sqldeveloper/bin/sqldeveloper.conf. Frustrating when it doesn’t work …
Yes, that message is wrong and has been updated for our next release.
Tank you for that very helpful article.
When I start SQL Developer, I see one more sqlseveloper blank console opening along with editable Oracle SQL Developer. I don’t understand why do I see 2 windows. If I close any of these two windows, the other gets closed. (No messages/logs/errors in the blank, black console window).
Is there any setting to be changed to not display that other blank window?
Sounds like your desktop shortcut is pointing to the exe in the BIN directory. You want to run the sqldeveloper.exe in the root directory.
I installed SQL Developer 4.02 and it is telling me that I am using java 1.70_25 when in reality I am using 1.70_55. I modified the sqldeveloper.conf to set the java home pointing to C:\Program Files\Java\jdk1.7.0_55 but I still get the warning message every time I start SQL Developer.
Where else should I change the java home?
If you’re on Windows, you need to set the property in the product.conf file. The directory is described in this post. We need to get the warning dialog message updated to reflect the new directory.
Thanks Jeff. It works now.
To add on to what Aldo was reporting, I got the same message, but the prompt was incorrect – telling me I needed to change “C:\dev\sqldeveloper4\sqldeveloper\bin\sqldeveloper.conf” (my installation folder) when in fact I needed to change “C:\Users\Kris\AppData\Roaming\sqldeveloper\184.108.40.206.0\product.conf”. Actually, I just deleted the latter file and sql developer recreated it.
yes, that’s a bug we hope to have fixed in the next release
Thanks you. It works. In my computer the folder is hidden. Take me some time to figure it out. :>
In prior version you could simply put SQL Developer on a USB stick and use it everywhere with your own settings.
You only had to change AddVMOption -Dide.user.dir=? to the letter where Windows mouted it.
With the new version you cannot do this, you have to start up at least once, then shut down and edit product.conf. And you are lucky if you don’t have to work on a restricted workplace where you are not allowed to change the Explorer settings so you cannot see the AppData folder.
It should be an option to store the data in the user profile but not as default.
It seems to work as portable app:
Edit \ide\bin\jdk.conf and add
Found at https://community.oracle.com/message/3594491#3594491
This article helped me figure out why Data Modeler was utterly ignoring my environment configuration and its own supposed settings file, and I just wanted to say thanks.
I have JDK 6 and 7 installed on my machine, and got the popup message requesting the JDK location. I pointed it to JDK 6 and got a subsequent popup stating that 6 is unsupported and that 7 is the minimum supported version. It told me I could continue as-is or update datamodeler\bin\datamodeler.conf and update the SetJavaHome property to point to a supported JDK.
I updated the property to point to JDK 7, using both absolute and relative paths, and Data Modeler ignored it and continued to pop up a warning about using JDK 6. I verified my JAVA_HOME was set to JDK 7 and verified my PATH was pointing to JDK 7 by testing ‘java -version’ and ‘javac -version’ and they all reported 7 was in use, and STILL Data Modeler ignored all settings.
At this point I realized it must have written the JDK location to a file somewhere. I reinstalled Data Modeler – still got the stupid popup.
Then I found this post, and saw I had a directory for Data Modeler under “%USERPROFILE%\Application Data” (this is the path for XP, anyway), and deleted it. Launched Data Modeler again, and got the JDK prompt. I pointed it to JDK 7, and it was happy.
Thanks for saving my sanity.
That message definitely needs updated to accurately reflect the location of the configuration for the JVM. Sorry it took you so long. Please don’t forget the release notes, help, forums, and of course MOS for next time you get stuck – and of course always feel free to reach out directly to me and I’ll do what I can.
Is there a way to change the default of “AddVMOption -Xmx800m” in product.conf when it is generated for the first time?
We have a shared windows machine with a large number of users and want the ability for the initial value to be much lower to control memory usage on the server. User then can increase if they run into specific issues.
You can use the launcher.sh script to make these changes, and you should also disable as many extensions as possible in Tools > Features to lower the memory footprint.
The better answer: get enough memory on the server to make the application and the users happy – memory is cheap. People are not.
the hint for changing launcher.sh only works for Linux/Unix.
For Windows, we had to “edit” the files launcher.dll and launcher64.dll, where the default values are hard coded in it.
Why are such initial values not available in an own configuration file, which can be normally edited?
Probably because Windows isn’t as user friendly as *NIX
Actually, MacOSX can prompt you for the JDK home
$ cd /Applications/SQLDeveloper.app/Contents/Resources/sqldeveloper
$ bash ./sqldeveloper.sh
Oracle SQL Developer
Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved.
Type the full pathname of a JDK installation (or Ctrl-C to quit), the path will be stored in /Users/yourname/.sqldeveloper/4.0.0/product.conf
to work around problems when upgrading to jdk1.7.0_51
Took a while to discover this magic as I managed to click yes on the location for the 1.6 jdk. Then every time I started sqldeveloper it said that I had the wrong version of java installed and told me to change these preferences in the sqldeveloper.conf file…
Please update the error message to point to the correct location in the roaming profile.
Installed version (220.127.116.11 Build MAIN_13.80)
It should be documented, and my blog is not the right place for that. I’ll see what I can do to make this more clear going forward. Sorry for poor experience Magnus, and thanks for bringing it to my attention.
This info helped me resolve my JDK issue!
Cool, thanks for sharing that Scott!
Despite changing location in sqldeveloper.conf, I cannot run easily sqldeveloper 64bit (on Windows 7 x64), I can always start it using directly sqldeveloperW.exe in the sqldeveloper/sqldeveloper/bin directory. When I succeed (sometimes) to apparently lauch the 64 bit version, the help.about windows shows always the 32bit version of java and jdk in java.home, changing the conf file doesn’t change anything. any idea?
Do you mean the product.conf – we don’t read sqldeveloper.conf for the JVM settings anymore, including the location of the JDK.
What do you see if you run sqldeveloper64.exe? You should get a command window console opening that would show any fatal errors.
Sorry I wasn’t in the right directory for the product.conf file, evrything is fine now.
sorry to disturb you, thanks you
Would it be possible to change the JDK path from GUI preferences, or the only way is to modify the .conf file? Also, did something change about SQLDeveloper.conf for linux installations, or SQLDev still looks there?
Maybe a little suggestion – the JDK directory will often change for people which follow the jdk_ jdk directory naming pattern. I would like SQL Developer to display that jdk location prompt if it is unable to locate the jdk in directory specified in product.conf and update it after user will point to new directory.
Probably not a bad idea.
However, most people don’t update their java installs that frequently. That being said, we should make the tool smarter about what to do if it the location changes.
Very timely article, as I just installed SQLDeveloper 4.0 and accidentally chose the 32 bit version of the JDK when prompted. I was looking everywhere in the sqldeveloper.conf file but low and behold the java_home parameter was missing. Now I can modify the product.conf file and point to the 64 bit JDK instead.
Just a little question : why SQLDeveloper need jdk, and not only jre ?
Our PL/SQL Debugger uses JDWP, which isn’t in the JRE.
Most of our analysts don’t use the Debugger, and we’d love it if SQL Developer could run on the JRE. It would save the headache of getting everyone repointed to the new JDK folder when Java updates itself (at least until Java moves to 1.8). Is the Debugger too integrated for a setting that would allow that?
How is your JDK updating itself?
You can run SQL Developer 4.0 and higher with a Server JRE if you’d like. And yes, we’d have to refactor the tool to not have the debugger, so not a trivial change. It’s easier to just let folks grab the SQL Developer with the embedded JDKs and be done with it.