JVM default charset in IS 9.5

, ,
1

Hello everyone,

I’m stuck with a problem concerning the default encoding used by the Integration Server’s JVM in version 9.5.
Every method I tried to get the default encoding returned an alias of US-ASCII:


Charset dCharset = Charset.defaultCharset();
String name = dCharset.name();
String displayName = dCharset.displayName();

Both methods above return “US-ASCII”.

byte b = (byte)'a';
byte [] byteArray = {b};
InputStream inputStream = new ByteArrayInputStream(byteArray);
InputStreamReader reader = new InputStreamReader(inputStream);
String defaultEncoding = reader.getEncoding();

This returns “ASCII”.

String fileEncoding = System.getProperty("file.encoding");

This returns “ANSI_X3.4-1968”.

The IS is running on RedHat and when I try to see what is the default locale and charset of the system I get the following results (with the same user that also executes IS):

> locale

LANG=fr_FR@euro
LC_CTYPE="fr_FR@euro"
LC_NUMERIC="fr_FR@euro"
LC_TIME="fr_FR@euro"
LC_COLLATE="fr_FR@euro"
LC_MONETARY="fr_FR@euro"
LC_MESSAGES="fr_FR@euro"
LC_PAPER="fr_FR@euro"
LC_NAME="fr_FR@euro"
LC_ADDRESS="fr_FR@euro"
LC_TELEPHONE="fr_FR@euro"
LC_MEASUREMENT="fr_FR@euro"
LC_IDENTIFICATION="fr_FR@euro"
LC_ALL=
> locale charmap

ISO-8859-15

I didn’t set the “Dfile-encoding” option in setenv.sh or anywhere else, neither did I set the “-Duser.language” or “-Duser.region” options.

On another RedHat machine with the same locale, same charset and IS 7.1.3, we don’t have this problem, the JVM’s default charset is ISO-8859-15.

Trouble is, when we run old code that uses pub.string.stringToBytes or pub.string.bytesToString without specifying the encoding (I know it’s bad), we lose all non-ascii characters. I know I can use the “Dfile-encoding” option to solve this, but I’d like to understand where the JVM gets that US-ASCII configuration from.

Anyone knows what could be happening here? Is there a configuration somewhere that eludes me?

2

JVM get the locale setting from OS.
you can create a startup java service to reset it.

example:
Locale.setDefault(new Locale(“en”,“US”));

1 Like
3

I know how to fix it, but I don’t understand yet why the JVM picks up US-ASCII as default charset since it’s not the default charset of my OS, and it’s not specified anywhere at JVM startup.

After some research, I found out that the shell environment used by the JVM is not the same as the environment of my login shell, so it looks like the shell running the java process for IS did not inherit the environment from the shell running the startup.sh script. I’m going to look into this further.

1 Like
4

I think I found what happens.

My suspicion is that the shell variable LANG gets clobbered inside the sagis95 script. Indeed, the variable is first saved on line 194:

193 # save current LANG
194 LANG_SAVED=$LANG
195 LANG=C  # required for tr command
196 export LANG

But then it is saved again on line 259:

258 # Resolve the os
259 LANG_SAVED=$LANG; LANG=C; export LANG   # save and set LANG
260 DIST_OS=`uname -s | $TREXE "[A-Z]" "[a-z]" | $TREXE -d ' '`
261 LANG=$LANG_SAVED; export LANG   # restore LANG

But since it wasn’t restored in between, that second save actually overwrites the value saved in LANG_SAVED with the new value in LANG, so when the script restores LANG on line 261, it does nothing because LANG and LANG_SAVED have the same value at that moment. All subsequent saves and restores done on LANG are therefore rendered useless.

I tested it by adding echo locale commands throughout the script, and the results confirm this behaviour.

I think this calls for a ticket to SAG support.

5

SAG Support replied that this is a documented Known Issue published in the IS 9.5 SP1 Readme file.

And indeed it is stated there that lines 193 to 196 in sagis95 should be deleted to correct the problem.

I tested it and it works, problem solved! :slight_smile:

6

Thanks for sharing the solution!

7

Could you answer one question? I am having hard time solving this problem… From which file should the line 193 and 195 be deleted to solve the problem?

You said it is already a documented known issue published in a Readme file - Which file is it? Could you tell me how to find it?

Thank you :slight_smile:

8

check these two KB articles:
KB #: 1762476
KB #: 1752376