I am finding any elegant method, how can I change default charset of Java machine to UTF-8 in Eclipse. I have found many methods, how to do from source code, but I would like to know, how to do it fast, easy, from Eclipse IDE without writing java source code.
Thanks.
You can change the workspace default encoding for all files in the Preference page Workspace, about the bottom left of the dialog. All new projects and files will have that encoding.
However, if you are using existing projects, be vary of three things:
Existing files saved with a different encoding might need conversion; it will not happen automatically.
Projects (or files or folders in projects) might have alternative default encodings (set Resource page of the Properties dialog). Those settings are more specific, and will not be affected by the generic workspace settings. Furthermore, these settings are shared with the project, e.g. through version control, so if you collaborate with others, make sure to set up encoding together.
This is not Java specific; there is no supported way to do it only for Java projects.
Edit: as you want to edit the default character encoding for your application, see the answer Setting the default Java character encoding?
In short, you have to set it up as a JVM parameter, like
java -Dfile.encoding=UTF-8 … com.x.Main
Related
I found abc.properties.tmpl file in a java project.Which is similar to abc.properties file.I am not aware why it is important to keep tmpl file in project.
What is the use of this file?
Since you haven't mentioned which IDE environment you are using and where (in which folder of the project) you found this, there could be lots of possibilities:
1) This might have been generated or kept by the IDE environment being used e.g. NetBeans, Eclipse. I cannot remember if it's specific to HTML or just any templates that require property settings.
2) This might have been generated by some old application which hasn't been cleaned up.
As I said, you have to update the question with more relevant information (perhaps some screenshots/snippets) for a better answer.
The file might have been copied twice and renamed. Or the guy created the tmpl file as a backup while working on abc.properties file.
Not known, "tmpl" would be "template." When there are multiple locales, en_US, nl_NL, nl, nl_BE they all are placed in their own properties file, having the same keys but different language texts.
So the tmpl file might be for a new language, or when a key/text is added, so all other properties must be updated by doing a text diff.
My guess is, that the tmpl file does not need to be distributed. Check the produced jar, the build, references to tmpl.
So I'm not sure what the reason is/was, but now (only)two out of my five .java source file are loading in Eclipse as a single row of squares. I opened it in notepad and it showed the encoding (a lot of East Asian characters and I even saw a sun and stuff), but now it only shows squares in Eclipse, and nothing elsewhere.
Can somebody explain what may have happened and offer a solution?
Right Click on the file in Eclipse and select 'Replace With > Local History' Eclipse will show you a list of previous versions of the file (if it has any). You can replace the bad current version from those.
Take the time to set up a backup system. Also use a version control system like Git or SVN to keep good copies of your files.
Try Preferences -> Workspace -> Text file encoding and other UTF-8
I know Java uses UTF-16 internally and expects .properties files to be in ISO-8859-1 by default.
I'm currently working on a project that was written in Eclipse, whose default encoding on our systems is cp-1252. I'm thinking utf-8 would be a much more sensible option, going forward.
However, given the scale of the project (it's split up into modules and uses libraries from all over the place), I can't just batch-convert all source code files in one go.
Will Java have a problem with some files in a project being in one encoding and some in another? (Clearly, having entire libraries written in encodings that are different from one another doesn't seem to be a problem - probably because they are all UTF-16 once compiled, anyway.)
Would Eclipse be able to handle that (i.e. different encodings per file) correctly?
Yes you can.
You can choose the default encoding to use for the whole Eclipse project:
right click on a project
resource part
Text file encoding zone, check Other and choose UTF-8 (or what you want) in the combo
You can also change the encoding for a particular file:
right click on the file
resource part
Text file encoding zone, check Other and choose UTF-8 (or what you want) in the combo
Preferences are store in the hidden folder .settings in your project. File encoding preferences are store in the .settings/org.eclipse.core.resources.prefs.
Thoses preferences can be commited using your favorite source control and shared with other developpers.
I check out a java project from svn repository include .classpath and .project files. And I import these codes into eclipse. But the eclipse will modify the content of .classpath file. How can I stop eclipse to do this? just write off build automatically option?
You can't. But instead of putting a JAR on the Java build path you could
choose an execution environment which should stay stable when you change
the JRE and hence the .classpath file will not change either.
.Project and .classpath files should not be checked in under svn repos.Blindly copying such files from one machine to another may be risky. These are the files that eclipse automatically constructs for you as per your project structure. If you want to edit, you can do that.
Here is the nice explanation What's in an Eclipse .classpath/.project file?
Adding information to a 2-year old question just in case of any one else is stumbling across this.
Due to insufficient detail in the original question, I am guessing that the problem experienced is due to the project's classpath pointing to a different location on the questioner's machine as on the original project author's machine. When a project uses 3rd party libraries (JARs) and is shared between different team members (as hinted at by the use of a version control tool), this is a common occurrence.
A solution to this would be to have all team members set up the location of the directory containing all 3rd party JARs to have an identical structure on all individual machines. So instead of changing the classpath, change the directory structure to that required by the classpath.
Unfortunately this is not always the best solution:
Team members may have different operating systems (Windows vs Linux) and you will not be able to have a (absolute) class path that works on all platforms (e.g. C:\libraries\3rdparty.jar vs /opt/libs/3rdparty.jar)
Team members may differ in how they prefer to organize their directory structure. Especially, if a team member places libraries into his home directory (e.g. C:\User\abcd\libraries\3rdparty.jar or /usr/abcd/libs/3rdparty.jar), another team member will struggle to replicate that directory structure.
Eclipse provides various methods to set up a project so that it can easily be shared between team members. These however require team members to all agree on the convention, and will be slightly easier if set up by the original project author right from the start. Two methods most commonly used:
Add all third-party libraries to the project itself (the usual convention is to have a /lib directory inside the project for this - on the same level as /src and /bin etc.). The classpath can now be set up to be relative to the project's root and thus usable across different setups. A variation for large multi-project-file projects would be to have a separate eclipse project containing the libraries, then add it to other projects as a dependency ("Required projects on the build path" in the "Java Build Path" dialog).
This has the benefit of being able to version control your JARs too. However, it may use up a lot of extra storage/bandwith, so may not always be desirable. For instance, I would not do this with Java Enterprise Edition JARs contained in my preferred Application Server distribution, as I may want to migrate my project in future to a new version or another product, without such dependencies - I also do not want to have my project saddled with duplicate JARs that are in any case already available in the AS distribution. So you need to think through your requirements.
Eclipse also provides the concept of a classpath variable. This may be set up to point to the root of a team member's JAR-containing directory, and be extended with subdirectories and filenames inside the classpath. This needs to be done only once, and is also accessed via the "Java Build Path" dialog.
Whenever a new team member uses the project for the first time, he needs to configure eclipse (once) to point that variable to the relevant path on his own machine.
The above mechanisms are explained in more detail on various web pages, here is one reference: http://www.informit.com/articles/article.aspx?p=367962
If I run a script to edit files outside of the ide I am using, will the ide recognize the changes made to the files?
More specifically:
-IDE: Netbeans 6.8
-Version Control: CVS
-OS: Windows XP
In general, yes. But the form designer of NetBeans considers some parts of the code "private", and you shouldn't modify these parts externally. They are identified by comments in the generated code:
* WARNING: Do NOT modify this code. The content of this method is
* always regenerated by the Form Editor.
These parts are in fact generated from an external proprietary .form file, and having the source code not aligned with the .form code will mess everything up.
Yes it should. Give it a whirl and check it out.
Yes, with some caveats:
If you have those files open, edited, and unsaved in the IDE at the time, then you will need to tell the IDE whether to discard or keep your in-IDE changes.
If you have them open and unedited, then depending on the IDE, you may have to tell it to reload those files (the IDE should warn you that the file has changed since you last opened it).
If you move files around, and your IDE has some kind of project file (that tells it, among other things, where all the files are) and you don't update it accordingly, you may have problems.
Any files that you don't already have open in your IDE should behave as expected, and I would consider it a bug if it didn't pick up the changes.