For the code below I get a different result when I run it like this, and when I run it inside a Tomcat web app.
public static void main(String[] args)
{
System.out.println(System.getProperty("user.language"));
System.out.println(System.getProperty("user.country"));
System.out.println(Locale.getDefault(Category.DISPLAY));
System.out.println(Locale.getDefault(Category.FORMAT));
Locale l = new Locale("de", "DE");
System.out.println(l.getDisplayLanguage());
DecimalFormatSymbols dfs = new DecimalFormatSymbols(l);
System.out.println(dfs.getDecimalSeparator());
l = new Locale.Builder().setLanguage("de").setRegion("DE").build();
System.out.println(l.getDisplayLanguage());
dfs = new DecimalFormatSymbols(l);
System.out.println(dfs.getDecimalSeparator());
}
Standalone result (expected):
en
US
en_US
en_US
German
,
German
,
In Tomcat:
en
US
en_US
en_US
German
.
German
.
Can someone suggest what else influences DecimalFormatSymbols (and NumberFormat for that matter) that it doesn't use the locale provided.
I'm using JDK 1.8 with language level 1.7.
EDIT: This only happens when Tomcat runs in Eclipse. Eclipse/OSGi seems to interfere with the locale-based formatting, but only in a specific situation.
Tomcat our ENV setting might have an issue i see it from the post here.
Try starting the tomcat as suggested in the above post with the following params set as a batch file:
-Duser.timezone=Europe/Berlin
-Duser.country=DE
-Duser.language=de
Related
In my springboot application when I can fortify to check vulnerabilities, I got some issues related to Locale Dependent Comparison . I have number of files where fortify shows to fix Locale Dependent Comparison issue.
I have 3 options to change:
I have to go and change all those files by using Locale.US like below.
from
switch (strngvariable.toLowerCase())
to
switch (strngvariable.toLowerCase(Locale.US))
During the spring Boot Initialization I can set the default locale as
public static void main(String[] args)
{
Locale.setDefault(new Locale("en","US"));
SpringApplication.run(OWDNApplication.class, args);
}
In the first REST call, set the default locale as
#GetMapping("/applogin")
public ResponseEntity getSignonDetails(#RequestParam("uname") String uname)
{
Locale.setDefault(new Locale("en","US"));
}
I know the first thing will work. I want to know will the 2 and 3 options work ? which would be the best choice.
I can try on my own and figure it out if by running Fortify scan on my eclipse. Unfortunately the fortify plugin is not showing me all the issues on my local.
I have to deploy onto server and run the software on server. this would be time consuming to test the changes.
I am trying to parse a german number from a string. Here is a minimal example:
String stringValue = "1,00";
double value = NumberFormat.getInstance(Locale.GERMANY).parse(stringValue).doubleValue();
// value = 100.0 (locale machine from cmd, server jdk)
// value = 1.0 (locale machine from cmd, locale jdk)
Somehow the format is permanently stuck at an englisch formater. I debugged the line and had a look at the symbols.decimalSeperator and it is still a dot.
I must admit, that I can only reproduce this behaviour if I run the application with a JDK from a server in our company. Running it with my locale JDK everything works fine and as expected. So maybe the locale Locale on the server is englisch, but how can this override my hardcode Locale.GERMANY?
We are using Java 8.
I'm writing a very simple and small example class to try and show how the .getCurrencyInstance() of the NumberFormat class in Java works, but my output is looking a little funky. It seems the class is working, but when it tries to print out the actual symbols for currency (like the Japanese yen symbol or the British pound symbol) I get weird symbols instead. Is there any way to fix this? Is there something I need to import to get these symbols on my computer?
Here's my code:
import java.util.*;
import java.text.*;
public class CurrencyFormatExample
{
public static void main(String[] args)
{
double convert = 9398.9398;
NumberFormat currencyFormat = NumberFormat.getCurrencyInstance();
System.out.println("American: " + currencyFormat.format(convert));
Locale swedish = new Locale("sv", "SE");
NumberFormat swedishFormat = NumberFormat.getCurrencyInstance(swedish);
System.out.println("Swedish: " + swedishFormat.format(convert));
Locale japanese = new Locale("ja", "JP");
NumberFormat japaneseFormat = NumberFormat.getCurrencyInstance(japanese);
System.out.println("Japanese: " + japaneseFormat.format(convert));
Locale russian = new Locale("ru", "RU");
NumberFormat russianFormat = NumberFormat.getCurrencyInstance(russian);
System.out.println("Russian: " + russianFormat.format(convert));
Locale british = new Locale("en", "GB");
NumberFormat britishFormat = NumberFormat.getCurrencyInstance(british);
System.out.println("British: " + britishFormat.format(convert));
}
}
Here is the output I get with this:
American: $9,398.94
Swedish: 9á398,94 kr
Japanese: ?9,399
Russian: 9á398,94 ???.
British: ú9,398.94
As you can see that's clearly not right. Any way I can remedy this?
In jGRASP: "Settings" > "Font", "Charset" tab. Change "I/O Charset" to UTF-8. In the "Compiler" tab, "Flags / Args" sub-tab, for "FLAGS2" of the "Run" command, add "-Dfile.encoding=UTF-8".
The "file.encoding" change will also change the default encoding files that your program reads and writes. Unfortunately, Java does not provide a way to specify a different charset for normal file I/O and I/O from stdin, stdout, and stderr when they are connected to pipes rather than a console (most IDEs will use pipes). So if you want native encoding to be used by default within your program and still want UTF-8 for I/O to the IDE, there is no way to do it. Thus, it would not be wise for the IDE to automatically add the "file.encoding" flag, unless there is a "Just use UTF-8 for everything" setting.
If you're executing this code in Eclipse, adjust your Window > Preferences > General > Workspace text encoding to UTF-8
I have to apply toUpperCase on a name that may contain accents ("é", "à", etc.).
Problem:
with JUnit, "é".toUpperCase converts to "E", the accent is removed
in my application (a Spring REST API), "é".toUpperCase converts to "É". The input comes from an Ember frontend, but the encoding is the same (UTF-8)
JUnit tests and Spring application use the same characters set (UTF-8) and the locale is French. Both running on Oracle Java 8, on the same machine (Jenkins CI on Debian, but I can reproduce this behavior on my computer: Windows 7).
I tried to specify the locale toUpperCase(Locale.FRANCE), but it doesn't solve my problem.
Are you aware of something that may explain this difference?
As in the conversation with #JonathanLermitage this is not a Java problem but is related to the embedded database (h2) used in the unit tests that is not correctly configured.
I'm using Java 8, no particular configuration.
#Test
public void test()
{
String a = "àòùìèé";
String b = a.toUpperCase();
System.out.println(b);
System.out.println(Locale.getDefault());
assertEquals(b,"ÀÒÙÌÈÉ");
}
Returns
ÀÒÙÌÈÉ
en_US
I had the same problem once and it was fixed for me by setting the default Locale:
Locale.setDefault(new Locale("fr_FR"));
Servers on unix machine are always using en as default locale.
Following is locale output
LANG=en_US
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=C
I just don't understand if LANG is set correctly then why servers starts with en locale.
In Linux/Unix/Mac, the settings LC_ALL and LANG can control the default locale for Java programs. In Windows, the locales are set from the Control Panel, under Regional and Language Options.
When the JVM starts in a *nix environment, it will do this:
Scan the environment for LC_ALL
If LC_ALL doesn't exist, scan the environment for LANG
If the JVM setting user.language is set, use that in place of the environment variables.
If nothing is set, default to en_US (I believe this is the final failure case)
In your environment, you have LC_ALL set to C, which is just the C locale. It's basically a traditional fallback to the days when locales weren't used.
You can change LC_ALL in your case, and restart your JVM, and you should get a new value for java.util.Locale.getDefault().
Example:
import java.util.Locale;
public class LocaleTest {
public static void main(String[] args) {
System.out.println(Locale.getDefault());
}
}
Here's running:
> LC_ALL=en_UK java LocaleTest
en_UK
> LC_ALL=ja_JP java LocaleTest
ja_JP
Also note that if you're running Java 1.7.0-b147, there is a bug with the JRE not recognizing environment settings for locale, and will always use the default system locale.
Bug report here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073906