To determine the resource limit configuration for your system, enter the following command:

/bin/sh -c 'ulimit -n'

If the value returned is less than 4096, set the system resource limit as follows:

When you define the user home directory, it will contain a system subdirectory that stores the user's preferences for JDeveloper, also known as the domain home. The user home directory also contains a separate subdirectory for user-generated content and other configuration files that are specific to a given user, also known as the application home.

If you do not define a user home directory, these subdirectories are located in different areas on your computer.

• The default location for the system subdirectory is $HOME/.jdeveloper/system14.1.2.0.0.XX.XX.XX, where XX.XX.XX is the unique number of the product build.

• The default location for user-generated content is $HOME/jdeveloper/mywork.

There are two ways to set your user home directory if you do not want your JDeveloper files to be stored at $HOME. Both methods set the user home directory for all instances of JDeveloper on your system.

Use either of the following methods to set the user home directory:

• Editing product.conf

• Setting the JDEV_USER_DIR environment variable, which requires you to restart your terminal session

Editing product.conf

With 14c (14.1.2.0.0), many JDeveloper settings, including the location of your JDK, are stored in product.conf. This file is created by JDeveloper on first startup unless the file exists from a previous installation. JDeveloper uses the settings stored in product.conf even if they are from a previous installation.

1. Find the product.conf file. It should be located at $HOME/.jdeveloper/14.1.2.0.0.

2. Open product.conf in an editor. Add a line to set AddVMOption -Dide.user.dir to your preferred directory path.

   For example, if your preferred directory is $HOME/mydocs/jdevfiles, your definition should look like this:

   AddVMOption -Dide.user.dir=$HOME/mydocs/jdevfiles
   

   Caution:

   Do not use a directory that contains spaces as the home directory. For example, do not specify $HOME/my projects as the home directory.

3. Save your changes. The changes should take effect immediately when you start JDeveloper. The changes made to product.conf will also override any environment variable that you have defined.

   When you start Oracle JDeveloper for the first time, you can verify that the user home directory has been set to your preferred directory by clicking About in the Help menu, toggling the Properties tab, and finding the definition for ide.user.dir.

Setting the JDEV_USER_DIR environment variable

You can set the JDEV_USER_DIR environment variable to your preferred home directory path. The following examples and syntax are for the bash shell on Linux systems.

When you start Oracle JDeveloper for the first time, you can verify that the user home directory has been set to your preferred directory by clicking About in the Help menu, toggling the Properties tab, and finding the definition for ide.user.dir.

To change a JDK location:

This sets the JDK path for all installations of JDeveloper on your system.

If you uninstall JDeveloper but do not delete the product.conf file, all settings stored in this file, including the JDK path, are preserved for future installations. If you reinstall the same version of JDeveloper as your previous installation, your new installation automatically reads that JDK location again.

To address this problem, Oracle JDeveloper provides a set of cursors to replace the default set. You must have write access to the JDK to replace the cursors.

To replace the cursors:

1. Create a backup copy of the default cursors located in the JDK directory at:

   jdk_install/jre/lib/images/cursors

2. Extract the replacement cursors from the .tar file as follows:

   1. Navigate to the following location on your system:

      JDEV_HOME/jdeveloper/jdev/bin/clear_cursors.tar
      

   2. To extract the replacement cursors from the tar file, run the following command:

      tar -xvf clear_cursors.tar
      

When you define a user home directory, it will contain a system subdirectory that stores the user's preferences for JDeveloper, also known as the domain home. The user home directory also contains a separate subdirectory for user-generated content and other configuration files that are specific to a given user, also known as the application home.

If you do not define a user home directory, these subdirectories are located in different locations.

• The default location for the system subdirectory is %USERPROFILE%\Application Data\JDeveloper\system14.1.2.0.XX.XX.XX on Windows platforms.

  In these locations, XX.XX.XX is the unique number of the product build.

• The default location of the user-generated content is C:\Documents and Settings\My Documents\JDeveloper\mywork on Windows platforms.

There are two ways to set your user home directory if you do not want your JDeveloper files to be stored at the default location. Both methods set the user home directory for all instances of JDeveloper on your system.

Use either of the following methods to set the user home directory:

• Editing product.conf

• Setting the environment variable JDEV_USER_DIR

Editing product.conf

With 14c (14.1.2.0.0), many JDeveloper settings, including the location of your JDK, are stored in product.conf. This file is created by JDeveloper on first startup unless the file already exists from a previous installation. JDeveloper uses the settings stored in product.conf even if they are from a previous installation.

1. Find the product.conf file. It should be located at %USERPROFILE%\AppData\Roaming\JDeveloper\14.1.2.0.0.

2. Open product.conf in an editor. Add a line to set AddVMOption -Dide.user.dir to your preferred directory path.

   For example, if your preferred directory is N:\users\jdoe, your definition should look like this:

   AddVMOption -Dide.user.dir=N:\users\jdoe
   

   Caution:

   Do not use a directory that contains spaces as the home directory. For example, do not specify C:\My Projects as the home directory.

3. Save your changes. The changes should take effect immediately when you start JDeveloper. The changes made to product.conf also overrides any environment variable you have defined.

   When you start Oracle JDeveloper for the first time, you can verify that the user home directory has been set to your preferred directory by clicking About in the Help menu, toggling the Properties tab, and finding the definition for ide.user.dir.

Setting the environment variable JDEV_USER_DIR

You can set the environment variable JDEV_USER_DIR to your preferred home directory path on a Windows system, including individual users of Oracle JDeveloper on a multiuser system.

When you start Oracle JDeveloper for the first time, you can verify that the user home directory has been set to your preferred directory by clicking About in the Help menu, toggling the Properties tab, and finding the definition for ide.user.dir.

To change a JDK location:

This sets the JDK path for all installations of JDeveloper on your system.

If you uninstall JDeveloper but do not delete the product.conf file, all settings stored in this file, including the JDK path, are preserved. If you reinstall the same version of JDeveloper as your previous installation, your new installation automatically reads that JDK location again.

Run the Oracle JDeveloper installer on your server as detailed in Installing Oracle JDeveloper. Do not start Oracle JDeveloper at the end of installation, because you must first configure the user home directories and terminal server clients as described in the following sections.

The system DLL ole32.dll was relocated in memory. The application will not run properly. The relocation occurred because the DLL Dynamically Allocated Memory occupied an address range reserved for Windows NT system DLL's. The vendor supplying the DLL should be contacted for a new DLL.

If you see this error, update the product.conf file in $HOME/.jdeveloper/14.1.2.0.0 file by uncommenting the following parameter:

AddVMOption -Xheapbase100000000

In addition, each user must modify the default project to apply this setting. To specify this value in the default project settings:

This release of Oracle JDeveloper requires that you migrate all projects with JavaServer Faces and JSTL to the latest versions of the technologies. In addition, any web.xml deployment descriptors must also be migrated.

For the most current information on migration, see the Oracle JDeveloper documentation page on the Oracle Technology Network (OTN): Oracle JDeveloper .

Using the option Parameter

You can use the following flags for the option parameter:

• -ade to connect to the current ADE view
• -dry to initiate a dry run and skip calling migrators
• -failFast to stop the migration after the first failure
• -generateDefaults to let migrator helpers generate a migration.prperties file, alongside the .jws file, that contains the defaults for migration options.

To view these values and their use cases, invoke the help file for ojmigrate at the command line.

Using the file Parameter

To migrate one application, specify the path to the .jws file you want to migrate as the value for file.

For example, to migrate example.jws with no option flag, the command is the following:

ojmigrate example.jws

To migrate more than one application, use the @file parameter described in the next section.

Using the @file Parameter

To migrate more than one application at a time, create a file that contains all the paths to the applications that you want to migrate, and use the @file parameter to point to this file.

To autogenerate this file, use a script like the following:

find . -name "*.jws" -printf "%P\n" > workspaces.txt

After this file is generated, check the file to make sure that all the applications you want migrated are included. You can also create the file manually.

Once you have created and saved this file, specify its path as the value for @file in the example command structure. The @ symbol must be preppended to your filename when you specify this parameter.

For example, if you have listed the location of multiple .jws files in example.txt, your command would be the following:

ojmigrate @example.txt

If you encounter errors during migration, you can try to troubleshoot them by using the strategies in this section. To isolate the cause of your errors, run ojmigrate with the -failFast flag. This stops ojmigrate after its first unsuccessful migration and analyzes the issue.

Migrating Applications With -ade

If you see messages about being unable to check out read-only files, migrate these applications in ADE.

Make sure that you are in ADE view and that you have a transaction started. Because the ADE extension is not part of the JDeveloper non-debug builds, you should either use a JDeveloper debug build or manually install the ADE extension.

Once you are in ADE view, invoke ojmigrate with the -ade flag.

The commands that are mentioned in this section resemble the following:

ade useview VIEW_NAME
ade begintrans TXN_NAME 
ojmigrate -ade @workspaces.txt

Using a Two-Pass Migration

Migration may have failed because some migrators require extra data normally provided in the migration wizard, or because the defaults that the migrators are using are not suitable for your application. In these cases, do a two-pass migration.

For the first pass, run the ojmigrate command with the -generateDefaults flag. The command resembles the following:

ojmigrate -genarateDefaults @workspaces.txt

This command generates a properties file that contains a list of defaults that are formatted as name/value pairs with comments. The key/value pair is per application and per NodeMigratorHelper, meaning that there is one set of key pairs for every application, and the key is prefixed with the class name of the corresponding NodeMigratorHelper.

The properties file is generated beside the .jws application that you are trying to migrate. Its title is formatted as workspacename.migration.properties.

If the file is generated, open it, change the appropriate values, and save your changes. If you do not see the file after you run the command, no migrators generated defaults.

On the second pass, run the command without the -generateDefaults flag.

ojmigrate @workspaces.txt

If you still encounter errors, then some migrators may not be headless-friendly. A developer should prepare your migrator for headless migration before you attempt the two-pass migration again.

Preparing a NodeMigratorHelper for Headless Migration

If you need data from the user before migration, do the following: