File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

"LocaleBug"

 
Anonymous
Ranch Hand
Posts: 18944
  • 0
  • send pies
  • Quote
  • Report post to moderator
Helo all!
Consider following code:

I was surprised to receive NoSuchMethodException when I run LocaleBug class. I first thought that it is a bug but soon after reading API documentation I realized that this version of constructor has been introduced in 1.4 version of JDK.
Okie, so I should not use this version of constructor for Locale instantiation. Now how do I construct Locale by the "specification" of LocaleBug? Any ideas appreciated, thx!
(hey, remember, it is NOT a bug, I was just using too new feature of JDK!)

------------------
Antti Barck
It Solutions Consultant -- NSD Oy
Sun Certified Programmer for the Java™ 2 Platform
 
Cindy Glass
"The Hood"
Sheriff
Posts: 8521
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can use
Locale l = Local.US;
Locale l = Local.UK;
Locale l = Local.CANADA;
Locale l = Local.CANADA_FRENCH;
etc.
 
Anonymous
Ranch Hand
Posts: 18944
  • 0
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Cindy Glass:
You can use
Locale l = Local.US;
Locale l = Local.UK;
Locale l = Local.CANADA;
Locale l = Local.CANADA_FRENCH;
etc.

Nice try, but does not qualify for my need. But thx anyhow
I'll have now either extend Locale to meet 1.4 specific construtor or declare the software 1.4 specific. Which would you prefer?
Now 1.4 is at beta stage so my software would be useful for only those who are crazy enough (ie. just like me) to run beta software on there boxes. I could, on the other hand, disable this feature that uses the new constructor and decide it runtime! (by catching the Exception, of course) Again, which would you prefer?
The idea behind this is that servlet gets client locale from browser and selects right string resource depending on that - not a bad feature, huh?
------------------
Antti Barck
It Solutions Consultant -- NSD Oy
Sun Certified Programmer for the Java� 2 Platform
[This message has been edited by Antti Barck (edited August 27, 2001).]
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All you need to do in earlier SDKs is pass a blank string for the country:
l = new Locale("en", "");
and you get the desired locale.
 
Anonymous
Ranch Hand
Posts: 18944
  • 0
  • send pies
  • Quote
  • Report post to moderator
Helo Jim!
I came to same conclusion Does it, however, perform exactly same behaviour? What do you think my scheme to use ISO-639 as source of the locale? (well, thats all you gonna get from the servlet request?!)
------------------
Antti Barck
It Solutions Consultant -- NSD Oy
Sun Certified Programmer for the Java� 2 Platform
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The docomentation doesn't seem to say much about just how it works, but you can look at the 1.4 source code in src.zip to see how it's implemented:
<pre>
public Locale(String language, String country, String variant) {
this.language = convertOldISOCodes(language);
this.country = toUpperCase(country).intern();
this.variant = variant.intern();
}

public Locale(String language, String country) {
this(language, country, "");
}

public Locale(String language) {
this(language, "", "");
}
</pre>
So new Locale(language, "") does have exactly the same behavior as new Locale(language).
I don't know what you mean about using ISO-639, so no comment.
[This message has been edited by Jim Yingst (edited August 27, 2001).]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic