Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Need help navigating or using the PTC Community? Contact the community team. X

About the JVM and how to modify it (Arbortext Editor)


About the JVM and how to modify it (Arbortext Editor)

Hello experts!

Ok, so I've been playing with the jvm and I would like to know the
flexibility provided by Arbortext in order to modify or not use the
jvm.dll provided by default in the installation folder. Until now I have
the idea that by first instance Arbortext Editor will always use the one
provided by default, is that correct? Do you know how many ways do I
have in order to personalize my jdk version according to my Arbortext
Editor? Is that possible? and also I would like to know, is that
recommended? In my case I have the Arbortext 6.0 32-bit and in my
computer I just installed the 32-bit Java7.

Thank you soo much for your time and suggestions/responses. Have a
wonderful day! 🙂

P.D. (I would like to know also if it's possible to know if my Arbortext Editor is using a 32-bit or a 64 version. Do you know any command to get this information using ACL?)

Paulette Zorrilla


Hi Paulette--

Probably the easiest way to select an alternate Java VM is to use the set JAVAVMPATH option in your init.acl file. You can read the details in the Arbortext Help Center, just search for "set javavmpath" and you'll find the info.

Note that they give a generic warning about not supporting other versions apart from the one that ships with Arbortext. So, theoretically you could run into problems. However, if you are going to a later Java version, I wouldn't expect too much trouble. You are more likely to have problems if you are trying to stick with an older version than Arbortext wants, or to switch vendors (say to use Microsoft's JVM instead of Oracle's)


We currently are stuck using java1.5 with Arbortext 6 due to some
third-party integrations that still use the old httpconnection methods.
That said, JAVAVMPATH has worked fine for us, without ever giving a warning.

Now, the issue we started to run into was when we began to upgrade users
from 32-bit to 64-bit machines. This caused our default JVM path to be in
either "Program Files" or "Program Files (x86)". Until now, I've been
dealing with it on a per-machine basis, in the hopes that we'd be able to
get away from our 3rd party dependencies. As that is looking like a
long-shot, my plan was to set our custom deployment to look at a common
path (eg: c:\jvm\jvm.dll), with a separate, one-time installer.

My question is do you know if there's a way to include the desired JVM.dll
in our deployment package (, but also have the JAVAVMPATH know
where to look for it? Custom gets installed in
C:\Users\<username>\AppData\Local\PTC\Arbortext\Editor\.aptcache\zc\1 or
2... so it's been a tricky one for us to reference.

No biggie if we can't, pretty easy to put that default dir c:\jvm or
whatever, but figured it didn't hurt to ask.

Keith Berard, MCG

Hi Keith--

You might be able to do this with something along these lines:

1) Put your Java VM files in a subdirectory of $CUSTOM/lib

2) In your init.acl file, include something like this:

$vmpath = get_custom_dir() . "\\lib\\jvm\\jvm.dll"
set javavmpath=$vmpath

The get_custom_dir() function knows all about zipped customizations, so it will point to the copy in {user appdata}.../aptcache/zc/... if that's what you're using.


Awesome, I'll give that a shot.

I try to stay away from acl wherever possible these days, so I'm not
exactly up on the available functions.

I'll let you know how it goes.

- keith

Just a note that Arbortext 6.1 supports Java 7.

Regarding testing whether the version is 64-bit, there isn't an environment variable that explicitly denotes this. However, if you've installed Arbortext into the default location (Program Files vs. Program Files (x86)), you could extrapolate the version based on the installation directory. The variable to try would be$aptpath (or $aptbinarypath to get the full path to the exe).


Finally getting around to trying this...

get_custom_dir() is not returning the correct path it seems, but I know
it's loading the right file, since the error message states:

[A18115] Error in initializationfile:
[A11683] Cannot access the Java Virtual Machine library "C:\Program Files
(x86)\PTC\Arbortext Editor\custom\lib\jvm.dll".

Any thoughts?
- keith

Could it be something as simple as the spaces in "Program Files (x86)"?

It's actually getting the correct directory I'm talking about.

We deploy patches using a file on startup, so I'm looking to
find the current custom dir, not the custom dir that's part of the program
files path, since that really doesn't help with me being able to deploy the
jvm.dll as part of the patch.

eg: c:\Users\BerarK\AppData\Local\PTC\Arbortext\Editor\.


If you fire up Arbortext and type the command below in the command window, what do you get back?

eval get_custom_dir() output=>*

If you have your customizations configured as an application (with an application.xml file), they you might need to specify the application name as a parameter to get_custom_dir(). For example, in the stock Arbortext application, get_custom_dir() with no parameter returns my regular $APTCUSTOM location. But if I ask for get_custom_dir('com.arbortext.dita') I get the location of the DITA application in the install directory.


Yeah, it's weird. When I run that from the cmd line, I still get:

C:\Program Files (x86)\PTC\Arbortext Editor\custom

The way I'm running the custom is to use the create_installer.exe to make a
custom installer that points to a custom location on a web server. Then,
at startup, Arbortext automatically looks at the siteprefs.xml on the
server, and downloads the newest patch ( if available.

Ultimately, this installer sets the URL location in: c:\Program
Files (x86)\PTC\Arbortext Editor\lib\deploy.xml, and looks like this:
<deploy resource="&lt;a" style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href=""></deploy>">"></deploy>

Now, per my previous email, I know it's looking in the right place, since
the acl fails first by showing me the location in
Maybe instead of get_custom_dir(), is there an acl method to get the
current dir? That is, the dir that the acl file is in? That way, since
it's in the correct custom\init, I could look for current_dir() + "\..\lib"
or whatever?

I still think you have a good idea simply setting this in the instance.acl,
but I'm going to look more into the deploy_guide.pdf as well, since I now
notice there's a <libraryfiles> tag that may be of some use.

- keith

Hi Keith--

A couple of other things you can try:

1) You can use a numeric index in lieu of an application name to get alternate custom directory locations. You could try checking get_custom_dir(1), get_custom_dir(2), etc. Eventually you should find the .../aptcache/zc location.

2) You can get the location of the file that is executing with the caller_file() function. Pass the parameter 0 and it will give you the file name of the file containing the currently executing function.


Man, you rock.

get_custom_dir(1) did the trick perfectly. I'll use that one for now, and
if I ever run into any snags, I know I can use the caller_file() as a

Thanks again!

- keith

Paulette Zorrilla

Guys! Maybe my next question would be more related with my computer's environment, however, when I was trying to set my jvm manually using the following ACL command "set javavmpath" I apparently didn't receive any positive response, since Arbortext seems to give priority to the jdk installed on my computer, the jvm that I was trying to set was in a different directory and of a different version of the which one installed on my computer; so I was thinking, How can I tell to Arbortext to ignore the Java version installed on my computer and use anyother? Any ideas?

Best regards!

Paulette Zorrilla

Hi Paulette--

You have to catch this pretty early in the startup cycle, or Arbortext will have already started up its own JVM. Once Arbortext starts its own, it's too late to ask for a different one.

You probably need to have this in an ACL file in your custom/init folder for it to fire early enough to take effect.

Top Tags