VMS IDE for Java (Kotlin, Scala)

From VSI OpenVMS Wiki
Revision as of 20:55, 1 September 2019 by Andrey.logachev (talk | contribs)
Jump to: navigation, search
Note: support for JVM based languages (Java, Kotlin, Scala) will be available soon

Working on a Java, Kotlin or Scala project

Creating and building a project

The general development process includes the following steps:

  1. Change project settings:
    • project type - specify java, scala or kotlin
    • project name
    • root folder
    • source, headers, resource, and listing masks
  2. Write code
  3. Create MMS
  4. Upload source files
  5. Build the project
  6. Collect Java classes. This step is required for debugging.
  7. Run the project


Because the project target is compiled by one command for all source files, do not mix Kotlin, Scala, and Java source files in one project.


A Java, Scala or Kotlin project may depend on other Java, Scala or Kotlin projects.


Before starting debug

To be able to use breakpoints during debugging, run Collect Java classes after editing and building the project.

Running VMS JVM Debugger

  1. To start Debugger, press F5. If no debug configuration is selected, the Select environment dropdown will be shown.
  2. Choose VMS JVM Debugger. If all java classes are collected successfully, the entry class quickpick popup will be shown.
  3. Select one and debugging will start.

Creating Debug Configurations

You can configure 'launch.json' to start predefined debug configuration. To do this,

  1. Click 'Configure or Fix...' button on the DEBUG panel.
  2. The next step depends on the launch.json file existance:
    • If there is no launch.json file, the Select environment dropdown is displayed. Choose VMS JVM Debugger.
    • If the launch.json file exist, click Add Configuration button in the bottom-right corner of the VS Code and select VMS IDE: Launch JVM.
  3. Edit the launch.json file
      "type": "vms jvm debugger",
      "request": "launch",
      "name": "Launch JVM",
      "classpath": "${command:FillClassPath}",
      "class": "${command:FillClassName}",
      "port": "5005-5105",
      "arguments": "",
      "stopOnEntry": true
    • Do not change type and request
    • Specify the name
    • Set the class path - A colon-separated list of directories, JAR archives, and ZIP archives where to search for class files in. In case of "${command:FillClassPath}" class path will be taken from project settings.
    • Enter full class name with the static main method. In case of "${command:FillClassName}" the 'select executable class' quickpick will be displayed when debugging is started.
    • port is range of ports for JDB.
    • arguments is a string with arguments passed to the program.
    • stopOnEntry indicates whether do stop or not on the program entry.


Breakpoints are shown grayed until the corresponding class is loaded into memory. Also, they are grayed if no Java class information collected.

Function breakpoints

To add a function breakpoint:

  1. Click '+' in the Breakpoints view.
  2. Enter the function name using <full_class_path>.<method>(<arg_type1>, <arg_type2>...) format. You can omit any part of the function name. QuickPick popup with available functions will appear. Then select the required one.
  3. If no dialog appears, click Activate Breakpoints.

Data breakpoints

There is no specific UI for data breakpoints.

To create a data breakpoint, type watch all <class>.<field> in the debugging console input while the program is paused. To remove data breakpoints, type unwatch all <class>.<field>.

Note: This feature does not catch the changing of particular variables. It catches all changes to the <field> of all instances of <class>. Also, it does not work for local variables.

Displaying/Setting variables

A string variable is displayed as is, without escaping.
Char variable is escaped if its value is less than 0x20 or greater than 0x7f.
To set the value of a string or char variable, you can write an escaped string (using Java rules). Enclosing quotes are not required.

Debugging console

When a program is running, anything that you type to the debugging console is sent to the program. When a program is paused, anything that you type to the debugging console is sent to the debugger.

Note this to avoid issues with breaking the debugger. For example 'eval a=100' will change the value of variable a and this will not be caught by the extension.