Recently I encountered a problem, where Notes Java agent contained strange characters. My Domino Designer was set to UTF-8 and everything looked fine when I changed those characters to correct ones, but only until I reopened this design element again.
I tried to reproduce the issue in different VM, but the problem didn't occur and since I have never seen it before, I started to blame Windows 8 for that, since other VM was Windows 2003 and both were English versions with default region for non-Unicode programs set to Czech.
Only option I had was to switch back to non-Eclipse editors, but when I tried to open the element, it looked even worse.
For example this code (check the line with a comment):
When reopened:
When reopened in classic editor:
This can get really bad when such characters occur in string constants.
Only solution was to fix the element in classic editor and leave it this way. Not really good for development.
Today, I was testing the agent again and when I decided to try to print the code to console, the output wasn't correct either (which was just fine in old VM).
Hopefully this lead me to the solution. When you hit 'p' in Java console, you can get some basic information about the environment. And to my surprise it mentioned file.encoding=Cp1252, which is default for English windows, but I really want to deal with UTF-8 only.
To change this option, you can set this option on JVM startup, or use environment variable JAVA_TOOL_OPTIONS. I didn't want to experiment with eclipse.ini for Notes client, so I just created environment variable JAVA_TOOL_OPTIONS : -Dfile.encoding=UTF8
After I restarted my Notes client everything seems to work just fine. Console outputs all characters and I'm able to edit same code from both old and Eclipse based editors. Also non-binary export to ODP seems to contain valid UTF-8 version of the code.
I'm not sure if this setting can break something else, but I really try to default encoding to UTF-8, so I'm willing take the risk.
I tried to reproduce the issue in different VM, but the problem didn't occur and since I have never seen it before, I started to blame Windows 8 for that, since other VM was Windows 2003 and both were English versions with default region for non-Unicode programs set to Czech.
Only option I had was to switch back to non-Eclipse editors, but when I tried to open the element, it looked even worse.
For example this code (check the line with a comment):
When reopened:
When reopened in classic editor:
This can get really bad when such characters occur in string constants.
Only solution was to fix the element in classic editor and leave it this way. Not really good for development.
Today, I was testing the agent again and when I decided to try to print the code to console, the output wasn't correct either (which was just fine in old VM).
Hopefully this lead me to the solution. When you hit 'p' in Java console, you can get some basic information about the environment. And to my surprise it mentioned file.encoding=Cp1252, which is default for English windows, but I really want to deal with UTF-8 only.
To change this option, you can set this option on JVM startup, or use environment variable JAVA_TOOL_OPTIONS. I didn't want to experiment with eclipse.ini for Notes client, so I just created environment variable JAVA_TOOL_OPTIONS : -Dfile.encoding=UTF8
After I restarted my Notes client everything seems to work just fine. Console outputs all characters and I'm able to edit same code from both old and Eclipse based editors. Also non-binary export to ODP seems to contain valid UTF-8 version of the code.
I'm not sure if this setting can break something else, but I really try to default encoding to UTF-8, so I'm willing take the risk.
Comments
Post a Comment