The release of Studio 2014 brought about some great new features and performance gain that to me finally make Studio a mature Translation Environment Tool, but not everything went completely smooth as soon afterwards along came the now infamous Java Update 45 that broke pretty much the entire terminology editing functionality in Studio and MultiTerm 2014. With the recent release of Cumulative Update 2 this incompatibility between Studio and MultiTerm 2014 and the latest Java version has been resolved, at least for the most part, but another nuisance that loomed over Studio 2014 since its release remains unchanged: the controversial delay when trying to add or edit terms in a termsbase.
This delay is quite the source of controversy among users, with some even claiming that it is a productivity showstopper that prevents them from switching to Studio 2014 or forces them to revert to a previous version of Studio. I sympathize with their sentiment and can understand how these short delays can add up with time, especially for those who do a lot of terminology editing.
In an attempt to better understand what causing this delay and to find out if it could be avoided, I decided to investigate (within the scope of my limited knowledge on the subject) further into this issue, and came up with what I consider to be a satisfactory workaround for most users.

Java Security Checks

Before talking about any potential workaround or solution it is important to understand what is the cause for this delay in terminology editing in Studio and MultiTerm 2014.
With Studio and MultiTerm 2014 SDL has adopted and adapted to Oracle’s (the company developing Java, which is the software platform that MultiTerm uses) security concept. Under the requirements of this security concept the components need to be digitally signed so that their validity could be verified. This is a basic and common security concept in the computer security world, used to minimize security risks and mitigate vulnerabilities by preventing malicious developers from posing as trusted entities in an attempt to execute their malicious code in the systems of unsuspecting users. In other words, the validity of a software component must be verified before it is allowed to run, and this verification process is the cause for the terminology editing delay in Studio and MultiTerm 2014. Although this delay should be most noticeable on the first editing attempt in a session and much shorter afterwards, some users (me included) report a noticeable-enough delay also in the subsequent editing attempts.

It should be pointed out that this security check is not just a random, arbitrary step that slows everything down for no reason. The benefit of adhering to the requirements of Oracle’s security concept is a more robust Java integration that should reduce the amount of security prompts that a user experiences and the required number of workarounds to be applied that for some users have historically been a serious security and/or productivity problem – and just as much of a nuisance as this delay – and overall improve the stability and reliability of Java operations within Studio.

Personally I think that conforming to Oracle’s security concept is a good thing as long as Java is used. This relatively short delay in terminology editing is generally an acceptable price to pay in the interim for achieving a more stable terminology working environment, but when doing a lot of terminology editing work these little delays do add up and there is no denying that they impede productivity.

Java Revocation Checks: Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP)

I knew that the security check is most likely the cause of this delay, and because I do not know a whole lot about Java I set to investigate this subject a little further in an attempt to learn how they work. Although I have learned quite a lot in the process I do not pretend to be an expert on Java, so the following explanation is just a quick and superficial overview of this quite broad subject.

As mentioned above, to improve security and stability the Java components that Studio uses are now digitally signed. This signature is called a certificate (think of it as an Identity Card) that can be set to expire after a certain amount of time, or on-demand. Before any Java component is allowed to run in the system, the validity status (called revocation status) of its certificate is verified to make sure that it is what it claims it is, and that its certificate is still valid and has not been revoked for any number of reasons. If the component passes this verification process it is allowed to run; if it fails, a security prompt is displayed to the user and/or the component is allowed/disallowed to run, all depending on the system Java security settings.

The Java platform uses two mechanisms for performing this check:
Certificate Revocation List (CRL): a Certificate Revocation List, or CRL for short, is a list of certificates that were issued by an issuer and since have been revoked (i.e. expired). This is basically just a simple file that is downloaded and cached in the local system.
Online Certificate Status Protocol (OCSP): An internet protocol, and an alternative to the CRL method, used for obtaining the revocation status of a certificate by sending a request to an OCSP server that returns the revocation status of the certificate. This mechanism is generally considered preferable over the CRL method because it always has the most up-to-date information, its more resource efficient, and generally considered more secure.
Recent Java versions have both these methods enabled by default, and from my investigation and little experiment on my system, the OCSP method seems to be the culprit causing the delay. However, I’m not sure exactly why or where things could possibly be optimized.

The Workaround(s)

In this article I’m suggesting two workarounds for disabling the OCSP security check, and in more extreme cases (that should be rare), both security checks; thus considerably shortening the delay. However, it is very important to note that the resulting performance gain is achieved by sacrificing some security, although.
That said, for the average Studio and MultiTerm 2014 user in a Small or Home Office environment, where Studio and MultiTerm are the only (or at least the major) Java-dependent software being used, and one that follows a common sense and some basic computer security best practices (such as keeping the Operating System and program up-to-date, not installing or opening files from unknown sources, avoiding questionable websites, etc.), the security compromise involved with this workaround is quite acceptable and well within tolerable margins, and for many users the performance gain probably outweighs this risk.

Disclaimer: Please note that this workaround is intended for users maintaining their own system and/or local IT infrastructure. It is NOT intended for users in an organization or other work environment in which their system and IT infrastructure are managed by a dedicated IT team. In such case please contact the person responsible for maintaining your system. It should also be noted that I don’t take any responsibility for any issue that may arise from applying this workaround. Therefore, proceed at your own risk and understand that while I did successfully test this workaround on my system, there are far too many system-specific variables to account for, so your mileage may vary.

Preferable Workaround: Disabling the Online Certificate Status Protocol (OCSP)

This is the preferred workaround because for most average users the resulted security compromise is almost negligible.

1. Open Windows Control Panel;
2. Click the Programs icon and then the Java (32-bit) icon to launch the Java Control Panel;
3. Switch to the Advanced tab
4. Scroll down to the Check for certification revocation using settings group;
5. Select the Certificate Revocation Lists (CRLs) option;
6. Confirm to close all windows and exit the Java Control Panel;
7. Restart Studio and/or MultiTerm 2014, as appropriate.

<

h3>Secondary Workaround: Disabling Revocation Checks

If the preferable workaround described above did not work as expected, it is possible to disable both revocation checks altogether. Note that this workaround results in a bigger security compromise, but for the average user it is still considered minimal and acceptable.

1. Open Windows Control Panel;
2. Click the Programs icon and then the Java (32-bit) icon to launch the Java Control Panel;
3. Switch to the Advanced tab
4. Scroll down to the Perform certificate revocation checks on settings group;
5. Select the Do not check (not recommended) option;
6. Confirm to close all windows and exit the Java Control Panel;
7. Restart Studio and/or MultiTerm 2014, as appropriate.

Conclusion and a plea to SDL

SDL Trados and Studio have a long history of Java-related issues. Even thought they usually stem from the Java side of the equation – which is not under SDL’s direct control – SDL responsibility lies with their decision to use Java. This last terminology delay issue serves as an excellent example for why I [since long] think Studio should get away from Java; while this issue is not a problem from a technical standpoint (because there is nothing to fix really, this is just how the security mechanism works) it is very much so from a User Experience perspective and SDL will do right by addressing it from that angle instead of the more traditional and obvious technical one.
While most of the time these Java issues are eventually resolved by a patch or workaround, it is almost always a little too late as far as many users are concerned. I strongly urge SDL to drop Java altogether, which I think will enhance the User Experince, and potentially also the Secutiry and Stability in the process.