Atlassian JIRA is a powerfull issue tracker which I am using it for a long time, as it is a good issue trakcer I bound to Localize it to my locale.
I found Their page in Linkedin and asked them if I can translate it, as it was welcomed in the community I started translating, I'd post first part of my translation for them and after a while they told me here that
Java does not support fa_IR locale.
and
try to force java to support fa_IR
refactor TAC so having locale is
What can I do to get JAVA attention to support fa_IR locale or something else to help JIRA supporting it? Actually I didn't get the minning of refactor TAC so having locale is how can I deal with it?
The Sun/Oracle Java implementation is based on OpenJDK (or rather, they've released the initial official implementation under GPL, as OpenJDK) and the two projects are closely linked.
You can check the contributor guidelines here: http://openjdk.java.net/contribute/ (which includes a link to http://bugs.sun.com/)
Update : Here is the page you can find the guidline to add another locale to JAVA
http://openjdk.java.net/groups/i18n/ look for Include locale in JRE in that page
Here's the original text
Alternatively, if the locale is
correct we will have to postpone the
implementation. There are two
solutions we can explore, but neither
in the short term:
try to force java to support fa_IR
refactor TAC so having locale is optional
Neither of these is anything you can fix. The first means Sun / Oracle will have to ship an additional Locale with their JRE, the second means Atlassian will have to rewrite their code to not use Locales. Neither of these are things you can do anything about.
You can't force Oracle to support "fa_IR". You can ask them. You can offer them large amounts of money to do it. But that's about the limit of your leverage.
Somehow, I don't think that attempting to put moral pressure on Oracle is going to work. They are a commercial organization whose primary responsibility is to make money for their share-holders.
You could consider implementing the locale yourself by modifying and building your own version of OpenJDK 6 / 7. Indeed, you could then contribute this back to the OpenJDK project so that other people will benefit from it in some future release. (Probably not until OpenJDK 8 now ...)
You can provision your own Java locales through the SPI - here's an example.
When it comes to I18N-enabling software, you'll have to make a decision about how far you want to go - currencies, calendars, time zones, UI layout, etc. Swapping strings is the easy bit.
Related
Firstly, I think I may have titled this question poorly, but I couldn't think of the right words, so please, feel free to suggest an edit and I will make it, so that the question is more educational and relevant to others.
I know that javax.Swing simply cannot be used for an Android project, and I've accepted this and learned Android XML based UI design, but just out of curiosity, I want to know exactly why.
I realize that the screen dimensions of a phone might be something Swing wouldn't handle well, but what is to stop a developer from simply importing the javax.Swing package (besides Android Studio simply not letting it happen in the first place), however deformed and hideous Swing windows might be on an Android device screen? I also realize that AWT and SWT would also have to be imported, but the same question applies to these packages as well.
I think my lack of understanding of this might really root from a lack of understanding of how the Java Virtual Machine and the Android equivalent (is Dalvik still used, or have they switched cold-turkey to ART?).
As always, any information or reading on the subject you can provide is greatly appreciated. I really want to learn more about the fundamentals of how the JVM, Dalvik, and ART work.
There are at least three fundamental differences:
the APIs differ; for instance, even the most recent versions of Android's SDK don't have JSR 203;
the binary formats differ; Dalvik/ART does not generate JVM bytecode;
the language level differs; it is partly a consequence of the previous point, since in order to support a given language level, Dalvik/ART has to reimplement all the parsing/bytecode production to fit its own VM.
The latter point means that as a result, there is still no mainstream support in Android of try-with-resources which appeared in Java 5 years ago; various efforts have seen the day to support this plus Java 8's "goodies" over time, but none of them is really Java "at the core"; understand, they do not use the JVM, they do not use the Java compiler.
Recent news tells that this is bound to change in "Android N" (which will actually use OpenJDK). Which is good news. Also, as to point 1, you may recall that infamous Oracle vs Google case with regards to APIs being copyrightable... This is still not completely settled.
This article might be helpful to you http://www.techentice.com/dalvik-vs-art-android-drop-dalvik-efficient-art/ although, it is somewhat outdated, ALREADY. It does, however explain differences between JVM and DALVIK and ART.
I am a hobbyist java programmer using NetBeans IDE. A problem I face with programming in Java is choosing the correct target JRE version. I understand that most of my friends have at least java 6, but few have a totally up-to-date version with which I compile. I know how to compile for a particular target run-time environment on NetBeans; the problem is that by using an earlier target release of Java, the compiler expects code written in that version.
For a specific example, I occasionally use a Java 8 lambda instead of a new Runnable(){}, however the compiler (or at least NetBeans) doesn't accept this 'modern' code. Another example is the use of the diamond operator, or the use of multiple-exception catch statement, neither of which are supported by Java 6. The language evolves and the compiler evolves, but older versions of Java cannot handle the change. To distribute my code, I am forced to use what some might consider outdated code.
My question is: Is it considered good practice or common practice to write Java for an outdated target version to provide compatibility? Is there some form of 'translator' or cross-compiler for Java code?
My question is: Is it considered good practice or common practice to write Java for an outdated target version to provide compatibility?
It is common practice.
Whether it is "good practice" or not, is highly context dependent. There is a pragmatic trade-off between supporting older applications whose developers don't want (or can't) upgrade, and holding back the development of your application by not making use of new (and presumably beneficial) features.
There is no universal "best" answer.
Is there some form of 'translator' or cross-compiler for Java code?
Effectively, no. For old versions of Java there were "retro-weavers" which allowed you to run "newer" Java on "older" platforms. However, this approach seems to have died out by Java 6.
To answer your first question, it really depends on the standards set by the company/office that you are working for.
From my experience, most of time big companies tries to stay with matured and well established development platforms, they might not give the cutting edge features of the new language, but the companies want the base platforms to be stable and secure first. And if the codebase is large and the project has been in development for a long time, they normally don't bother jumping into the new platform, since that means they might have to invest more resources to rewriting/refactoring a lot of code, which is not always economically lucrative.
I love using those features that you mentioned in my personal projects, but in my office works we are still using JDK6.
As for the second question, I think there are no workable things at this moment that can do the "translation" that you mentioned.
From my experience this isn't a big problem in the industry. Java is used mostly on the server, not so much on the desktop. And to setup a server with the required Java version is not a big deal. For desktop applications I also seen the approach to ship the JRE with the application. It is a little bit ugly to ship a small application (let's say 5 MB) with a 60 MB JRE, but in the "enterprise environment" it doesn't matter and is a practical way to provide the correct JRE. However, I don't like this approach since it leaves open questions, like how to ship security updates to the JRE.
And by the way: Is Java 6 still supported? To use an old JRE is pretty big security issue.
I am using the AWTUtilities class in my application to create custom window shapes. As far as I know, there is no other way to do it. It is a requirement.
The javadoc generation gives me this error:
warning: com.sun.awt.AWTUtilities is Sun proprietary API and may be removed in a future release
What exactly does this mean? I can use it, but it may stop working with any release? Why put it in, then? More importantly, and the real question here, if Sun takes it out, will they likely replace it with another way to do the same thing? Is that what the warning is for?
I suppose I could just check for the presence of the AWTUtilities class before calling the code. But that's just obnoxious if I don't need to do it.
Does anyone have any experience with similar classes? Were they eventually accepted into the API and the warning removed or replaced with another method of doing the same thing? Do I need to be concerned about this?
FYI, I have read this:
How to distribute AWTUtilities
The Oracle documentation states:
Note: the com.sun.awt.AWTUtilities class is not part of an officially supported API and appears as an implementation detail. The API is only meant for limited use outside of the core platform. It may change drastically between update releases, and it may even be removed or be moved in some other packages or classes. The class should be used via Java Reflection. Supported and public API will appear in the next major JDK release.
JDK 7 has been a long time coming so it could be awhile. Whether you should use it is a risk management question that only your company can answer. If we are talking about an internal application where the deployed JRE can be guaranteed then you are not going to have a problem because you can guarantee a compatible JRE. If we are talking about deploying to external customers then you need to have a support plan if this provisional API ever changes.
A stable way to do this would be to create a Shell in SWT as per this snippet and then use the SWT_AWT bridge to get a Frame to use in your application:
java.awt.Frame frame = SWT_AWT.new_Frame(shell);
If you are just deploying to a single platform (like Windows) then tossing a single SWT jar plus the native library. If you are targeting multiple platforms then this becomes a pain.
So those are the two choice: deal with the AWTUtilities risk or use the SWT_AWT bridge.
EDIT:
Some time has passed and Java 7 is out. There is documentation on the officially supported way to accomplish this in the Java Tutorials. The section "How to Implement a Shaped Window" at the bottom gives an example. This of course assumes you can mandate Java 7
You don't need a new Frame object, you can only use
this.setShape(shape);
or your frame name like this
Frame1.setShape(shape);
a lot of AWT methods has been applied to java.awt.Frame
I am staying India(has more than 20 languages) I am trying to implement java-internationalization in the website.
But in Locale.getAvailableLocales() the local languages are not available. is it possible to implement internationalization in my case?
If possible what will happen to the fonts? How am i going to load the proper fonts in the client browser?
Which framework to implement Struts or Spring?
I can't claim to be an expert in Java internationalization - all of my work which cared about localization dates back to when we had to do all that by hand.
If you don't want to do that (which is no harder now than it was back then), it appears that you can still make use of Java's automated I18N services.
It appears that in order to support languages, number formats, etc, which are for locales not yet supported, you'll have to create a Locale-sensitive service provider, which got much easier in 6
There's what looks like a good tutorial here.
I think you are asking multiple questions here, and they are orthogonal to each other.
For the Locale.getAvailableLocales() question. If the built-in locales are not enough, you can simply create more. The locale object just represent the locales that your program knows, it has nothing to do with you the system performs --- more specifically, no corresponding locale object does not mean you cannot support the locale.
For the font, typically you will use UTF-8 for a i18n site, so as long as your content type and charset is set properly it should render correctly in the client browser.
The framework question really depends on what you are trying to accomplish, and what do you want to gain from it.
I believe there are more locales available when using a JDK than a JRE.
Locale.getAvailableLocales() returns a list of locales whose LocalData is installed in sun.text.resources package of JRE.
This list may not matter to you. Currently, the LocalData only contains local number and date formatting information. If you don't have any special format, you can just pick a locale whose format is the same as yours, like "en_IN".
Charset is another issue. If you localized resources are in Unicode, you are all set. Otherwise, you need to make sure the charset/encoding is supported by Java so it can convert it correctly.
Don't worry about font. It has nothing to do with server. It's either specified in HTML or CSS. As long as the browser supports the fonts, you will be fine.
Java itself is I18N ready so it doesn't matter which framework you use. Struts provides taglib for I18N (bean:message) but you can also use JSTL (fmt:message).
In IE, I can use the classid "clsid:CAFEEFAC-0015-0000-0011-ABCDEFFEDCBA" to tell it to use java version 1.5.0_11. Is there an equivalent for Firefox and other browsers?
I can use the classid "clsid:CAFEEFAC-0015-0000-0011-ABCDEFFEDCBA" to tell it to use java version 1.5.0_11
Not any more, you can't, for good (security) reasons. See http://java.sun.com/javase/6/webnotes/deploy/deployment-policy.html
There is an IE-only clsid mechanism for asking for "5.0_(something)" in general - http://java.sun.com/javase/6/webnotes/family-clsid.html . This was introduced in 5.0u7 so if you have any one JRE from u7 onwards installed you get this behaviour, otherwise you get the old and incompatible behaviour.
Sun did not deign to provide a similar mechanism for other browsers until 6.0u10, when they added a bunch more mechanisms for choosing versions and deprecated all the old ones including the 5.0u7 family chooser. See https://jdk6.dev.java.net/plugin2/version-selection/ for all the gory details.
So what behaviour you get depends not only on the browser and whether the version of the JVM you want is installed, but what other versions are installed as well. The new behaviour is at least consistent, but it is completely different to all that went before and not entirely compatible. By the time your apps' deployment HTML has been updated to cope with it, they'll probably work with 1.6 anyway.
So in summary, as usual with applets, the whole thing's a bloody mess. Yay.