Jump to content
Excelsior Forums

Roger

Members
  • Content count

    0
  • Joined

  • Last visited

Everything posted by Roger

  1. Hi, A user in Japan just installed our product on their Windows PC which uses Excelsior JET v11.3. When they start the program it throws the following exception: Caused by: java.nio.charset.UnsupportedCharsetException: MS932 at java.nio.charset.Charset.forName(Unknown Source) at sun.nio.fs.Util.<clinit>(Unknown Source) Almost all Windows users in Japan use code page MS932(Shift-JIS) by default. Here is the full stack trace: Exception in thread "main" java.lang.ExceptionInInitializerError at sun.nio.fs.Util.split(Unknown Source) at sun.nio.fs.WindowsFileSystem.<init>(Unknown Source) at sun.nio.fs.WindowsFileSystemProvider.<unknown>(Unknown Source) at sun.nio.fs.DefaultFileSystemProvider.create(Unknown Source) at java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(Unknown Source) at java.nio.file.FileSystems$DefaultFileSystemHolder.access$000(Unknown Source) at java.nio.file.FileSystems$DefaultFileSystemHolder$1.<unknown>(Unknown Source) at java.nio.file.FileSystems$DefaultFileSystemHolder$1.<unknown>(Unknown Source) at java.security.AccessController.<unknown>(Unknown Source) at java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(Unknown Source) at java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(Unknown Source) at java.nio.file.FileSystems.<unknown>(Unknown Source) at java.io.File.toPath(Unknown Source) at javax.crypto.JarVerifier.getSystemEntropy(Unknown Source) at javax.crypto.JarVerifier.testSignatures(Unknown Source) at javax.crypto.JarVerifier.access$400(Unknown Source) at javax.crypto.JarVerifier$1.run(Unknown Source) at javax.crypto.JarVerifier$1.<unknown>(Unknown Source) at java.security.AccessController.<unknown>(Unknown Source) at javax.crypto.JarVerifier.<clinit>(Unknown Source) at javax.crypto.JarVerifier.verifyPolicySigned(Unknown Source) at javax.crypto.JceSecurity.loadPolicies(Unknown Source) at javax.crypto.JceSecurity.setupJurisdictionPolicies(Unknown Source) at javax.crypto.JceSecurity.<unknown>(Unknown Source) at javax.crypto.JceSecurity$1.<unknown>(Unknown Source) at java.security.AccessController.<unknown>(Unknown Source) at javax.crypto.JceSecurity.<clinit>(Unknown Source) at javax.crypto.JceSecurity.getDefaultPolicy(Unknown Source) at javax.crypto.JceSecurityManager.<clinit>(Unknown Source) at javax.crypto.Cipher.<unknown>(Unknown Source) at javax.crypto.Cipher.getMaxAllowedKeyLength(Unknown Source) at com.capitalware.mqve.MQVE.<init>(Unknown Source) at com.capitalware.mqve.MQVE.main(Unknown Source) Caused by: java.nio.charset.UnsupportedCharsetException: MS932 at java.nio.charset.Charset.forName(Unknown Source) at sun.nio.fs.Util.<clinit>(Unknown Source) ... 33 more What can I do to get Excelsior JET v11.3 to support code page MS932(Shift-JIS) ? Regards, Roger
  2. Japanese code page MS932 (Shift-JIS)

    Yes, I did a new build with 'Japenese Locale' and 'Extended Japanese Charset' and gave it to the end-user. After they installed it, they said everything works now. Regards, Roger
  3. Japanese code page MS932 (Shift-JIS)

    Hi, I was reviewing options in Jet Control Panel but didn't see anything related. I then went through the options in JetPackII and on the 'Runtime' page I found 'Additional locales and charsets'. When I expand that list I see 'Japenese Locale' and 'Extended Japanese Charset'. What is the difference? Or am I just suppose to include both? Regards, Roger
  4. Hi, I purchased the Excelsior Jet charity bundle for Windows and Linux last year. Anyway, 6-7 weeks ago I starting playing with Jet (v7.6 with MP6) on Windows building and testing my products and everything looks very good (I don't like the JetPackII installer on Windows but that's a different issue). This week I installed Jet v7.6 and MP6 on Fedora Core 4 64-bit server. Both jetcp and JetPackII worked very well. I tested my application after being built with jetcp and it worked. I used JetPackII to create an "Excelsior Installer Setup" package for my application on Linux. I used a different UserID on the same server (Fedora Core 4 64-bit) to install and test the application and everything worked. Next, I ftp-ed my application to another Linux server: Fedora 9 64-bit. It successfully installed but when I run it, I get the following error: Exception in thread "main" java.lang.UnsatisfiedLinkError: exception occurred in JNI_OnLoad at java.lang.Void.<unknown>(Unknown Source) at java.lang.Void.<unknown>(Unknown Source) at java.lang.Void.<unknown>(Unknown Source) at java.lang.Void.<unknown>(Unknown Source) I tried installing my application under different UserIDs on the Fedora 9 server, the application will install successfully but all fail to start and I get the above error. I did some searches and other people say it is a JVM conflict. I had both OpenJDK and gcc-jdk installed on Fedora 9, I un-installed both but I still get the same error. This is a show stopper for me. If I build my application with jetcp and JetPackII as an "Excelsior Installer Setup" package then I need it to work on any Linux server. Help. Regards, Roger Lacroix
  5. Deployment issue on Linux

    Sorry for the delay, I was busy with other work. LD_LIBRARY_PATH is not set. Did that (several times) and it did not make any difference. The exception looked exactly the same: Exception in thread "main" java.lang.UnsatisfiedLinkError: exception occurred in JNI_OnLoad at java.lang.Void.<unknown>(Unknown Source) at java.lang.Void.<unknown>(Unknown Source) at java.lang.Void.<unknown>(Unknown Source) at java.lang.Void.<unknown>(Unknown Source) This a GUI application, so I added some basic logging and began some head banging. After a bit of fooling around, I found that the exception was thrown with the following line: UIManager.put("swing.boldMetal", Boolean.FALSE); So, I changed the code to: try { UIManager.put("swing.boldMetal", Boolean.FALSE); } catch(Exception e) { e.printStackTrace(); } But it did not make any difference - the try/catch did not catch the exception. So, I commented it out and everything was fine until the code hit the following: try { UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); } catch (Exception e) { e.printStackTrace(); } Again, it crashed with the above exception and the try/catch did not catch the exception. First off, why is Jet having an issue with the UIManager class? Secondly, why isn't Jet catching the exceptions and allowing my code to handle the error in the "catch" clause? Recap: The application is build with Jet v7.6 and MP6 on Fedora Core 4 64-bit server and is being installed/tested on Fedora 9 64-bit. Help! Regards, Roger Lacroix
×