Sometimes, based on the size or performance of your system, the JVM settings in SQL Developer / Data Modeler need to be adjusted within the “product.conf” file once SQL Developer is installed. A few most commonly parameters that may be tuned are:

• AddVMOption -Xms[memory size]
• AddVMOption -Xmx[memory size]
• SetJavaHome [full path to the Java Installation to use]

Unfortunately, when you upgrade to a newer version to SQLDeveloper, these settings are not always carried forward to the new version. This is particularly important in a scenario such as an RDP server where many users, each with their own product.conf, leverage common binaries.

Described below is an alternative to keep all users on a common product.conf. The solution consists of three easy steps and once completed, will check for common changed settings each time SQLDeveloper is launched.

---

First, start with constructing a “masterSqldevProduct.conf” based upon the “product.conf” which is created in your users “AppData/Roaming/sqldeveloper/[user]” directory. It is in this file that you can modify any settings that you would like to keep persistent. Once updated, save the file in a location accessible by all users on the system:

##############################################################################
#
# The format of this file is:
#
# Directive  Value
#
# with one or more spaces between the directive and the value. This file
# can be in either UNIX or DOS format for end of line terminators. Use UNIX
# style '/' path separators, although on Windows some directives, such as
# SetJavaHome, can take '\' path separators.
#
##############################################################################

#
# By default, the product launcher will search for a JDK to use, and if none
# can be found, it will ask for the location of a JDK and store its location
# in this file. If a particular JDK should be used instead, uncomment the
# line below and set the path to your preferred JDK.
#
# SetJavaHome /path/jdk

#
# Specify the initial size, in bytes, of the memory allocation pool. This
# value must be a multiple of 1024 greater than 1MB. Append the letter k
# or K to indicate kilobytes, or m or M to indicate megabytes, or g or G
# to indicate gigabytes. The default value is chosen at runtime based on
# the system configuration.
# Examples:  -Xms6291456
#            -Xms6144k
#            -Xms6m
#
# You can specify one value for any JDK using AddVMOption, OR you can specify
# separate values for 32-bit and 64-bit JDK's.
#
AddVMOption -Xms768m
# Add32VMOption -Xms128m
# Add64VMOption -Xms384m

#
# Specify the maximum size, in bytes, of the memory allocation pool. This
# value must be a multiple of 1024 greater than 2MB. Append the letter k
# or K to indicate kilobytes, or m or M to indicate megabytes, or g or G
# to indicate gigabytes. The default value is chosen at runtime based on
# the system configuration.
# Examples:  -Xmx83886080
#            -Xmx81920k
#            -Xmx80m
# On Solaris 7 and Solaris 8 SPARC platforms, the upper limit for this value
# is approximately 4000m minus overhead amounts. On Solaris 2.6 and x86
# platforms, the upper limit is approximately 2000m minus overhead amounts.
# On Linux platforms, the upper limit is approximately 2000m minus overhead
# amounts.
#
# If you are getting the 'Low Memory Warning' Message Dialog while running
# the product, please increase the -Xmx value below from the default 800M to
# something greater, like 1024M or 1250M.  If after increasing the value,
# the product is no longer starting up because it fails to create a virtual
# machine, then please reduce the modified -Xmx value, or use a 64bit JDK
# which allows for very very large value for -Xmx.
#
# You can specify one value for any JDK using AddVMOption, OR you can specify
# separate values for 32-bit and 64-bit JDK's.
#
AddVMOption -Xmx2048m
# Add32VMOption -Xmx800m
# Add64VMOption -Xmx1024m

---

After constructing a master “product.conf” you can then create a powershell script that will be referred to in the windows shortcut used to launch SQLDeveloper. In this case the powershell script is called “launchSqldeveloperCustomConfig.ps1”. Ensure that this script is also saved in a location accessible by all users on the system:

$MasterConfFileLocation = "D:\Apps\sqlDeveloperConfig\masterSqldevProduct.conf"
$sqldevdir = @(Get-ChildItem -Path $HOME\AppData\Roaming\sqldeveloper\*\product.conf -Recurse -Force | % { $_.FullName })
foreach ($element in $sqldevdir) {
  If ((Get-FileHash $MasterConfFileLocation).Hash -ne (Get-FileHash $element).Hash) 
  {
    echo "Copying $GoldConfFileLocation to file : $element"
    Copy-Item $MasterConfFileLocation -Destination $element
  } Else {
    echo "File : $element already set"
  }   
}

Start-Process -FilePath "D:\Apps\oracle\product\18.0.0\client_1\sqldeveloper\sqldeveloper\bin\sqldeveloper64W.exe"

Customize the above script as needed to reflect your system file locations on your system.

---

The last part of this customization is to create a shortcut that refers to this powershell script. Upon invocation, the product.conf will be checked and overwritten if necessary. This shortcut should be created in the desktop for all users:

Target:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -Command “& ‘D:\Apps\sqlDeveloperConfig\launchSqldeveloperCustomConfig.ps1

Start in:
D:\Apps\oracle\product\18.0.0\client_1\sqldeveloper\sqldeveloper\bin

---

Now, with these easy steps, any changes you make to customize the JVM or other product level options will now be persistent across upgrades of SQLDeveloper.