Best practice: Use UTF-8 as your source code encoding


Software engineering teams have become more distributed in the last few years. It’s not uncommon to have programmers in multiple countries, maybe a team in Belarus and others in Japan and in the U.S. Each of these teams most likely speaks different languages, and most likely their host systems use different character encodings by default. That means that everyone’s source code editor creates files in different encodings too. You can imagine how mixed up and munged a shared source code repository might become when teams save, edit and re-save source files in multiple charset encodings. It happens, and it has happened to me when working with remote teams.

Here’s an example, you create a test file containing ASCII text. Overnight, your Japanese colleagues edit and save the file with a new test and add the following line in it:

String example = "Fight 文字化け!";

They save the file and submit it to the repository using Shift-JIS or some other common legacy encoding. You pick up the file the next day, add a couple lines to it, save it, and BAM! Data loss. Your editor creates garbage characters because it attempts to save the file in the ISO-8859-1 encoding. Instead of the correct Japanese text from above, your file now contains the text “Fight ?????” Not cool, not fun. And you’ve most likely broken the test as well.

How can you avoid these charset mismatches? The answer is to use a common charset across all your teams. The answer is to use Unicode, and more specifically, to use UTF-8. The reason is simple. I won’t try hard to defend this. It’s just seems obvious. Unicode is a superset of all other commonly used character sets. UTF-8, a specific encoding of Unicode, is backward compatible with ASCII character encoding, and all programming language source keywords and syntax (that I know) is composed of ASCII text. UTF-8 as a common charset encoding will allow all of your teams to share files, use characters that make sense for their tests or other source files, and never lose data again because of charset encoding mismatches.

If your editor has a setting for file encodings, use it and choose UTF-8. Train your team to use it too. Set up your ANT scripts and other build tools to use the UTF-8 encoding for compilations. You might have to explicitly tell your java compiler that source files are in UTF-8, but this is worth making the change. By the way, the javac command line argument you need is simply “-encoding UTF-8”.

Recently I was using NetBeans 7 in a project and discovered that it defaults to UTF-8. Nice! I was pleasantly surprised.

Regardless of your editor, look into this. Find out how to set your file encodings to UTF-8. You’ll definitely benefit from this in a distributed team environment in which people use different encodings. Standardize on this and make it part of your team’s best practices.

“Unicode and the Unicode Logo are registered trademarks of Unicode, Inc. in the United States and other countries.”

NetBeans 7 has no UML tools?

After mentioning earlier that I am using Omnigraffle to create UML diagrams, I remembered that NetBeans once had a decent UML tool. Unfortunately I haven’t been able to find anything for the most recent NB 7 or 7.0.1 version. Oddly, the NetBeans page itself refers us to JDeveloper for UML support. Why point me to JDeveloper? I really want to use NetBeans.

The same page above also recommends a 3rd party plugin from Visual Paradigm, but Visual Paradigm seems limited to NB 6.2 if I’m reading its page correctly.

My suggestion for the above “UML support” page is this…just remove it. Having the page refer to out-of-date plugins or different IDEs altogether is no help. NetBeans crew, you know I love the product, but I also have to say it how it is. If there’s no current UML plugin, just say that and maybe give us an indication whether one is in the pipeline. Don’t tease me with a support page that points to other IDEs and outdated, presumably non-working 3rd party plugins for older versions.

NetBeans vs Eclipse for Maven Projects

I thought yesterday that I had pumped up NetBeans unfairly without regard to other tools. To be fair, I decided today that I’d try to open up the very same project in Eclipse, just to see if it matched NetBeans’ ability to immediately understand the project.

First thing I noticed was that Eclipse did not automatically understand Maven. A quick search of “maven plugin eclipse” put me in contact with a couple plugins. I tried the first one. Installed it like Eclipse likes by pointing to the plugin repo. Downloaded the plugin and then restarted eclipse. I thought Eclipse would behave like NetBeans on this, but no it didn’t. No good; the plugin options, if they even exist, don’t appear anywhere in the menus.

So, back to the search. I find another maven plugin. This time, I’m more successful installing the “m2eclipse” plugin. It actually exposes a “Maven” project in the menu system this time. So I point to my source code, and try to open the pom file. It opens the pom file, but it doesn’t open up all the modules or seem to understand that I want to see the source code in my ide. Hmmm, I wonder if I’m just not doing something right.

Of course, I’m not doing something right. I’m really a maven newbie. If I really knew what I was doing, I’d have this project up and humming in only minutes. Instead, I’ve been fiddling around with Eclipse for 1.5 hours, trying to figure out how to open an existing maven project in the tool. I can’t show anything productive for my labor. I’m disappointed.

So I go back to NetBeans, wondering if what I did before was something special. I did nothing but point NetBeans at the file directory, chose the File->Open Project menu and pointed it to the root directory of my Maven project. NetBeans just understands this is a Maven project. And I downloaded how many plugins? None, nothing at all. Worked right out of the box…again.

Yes, I know I didn’t give Eclipse a fair shake this time either. But why should I at this point? I can become an expert in Maven later and learn whatever it is that I need to integrate Eclipse later. But I have coding to do now, and don’t have time to mess with Maven. I have to work on my actual product, and time wasted on integrating my IDE with it is just wasted time.

Gotta love NetBeans. It just works.

Rediscovering NetBeans

After the longest of waits, I’m finally rediscovering NetBeans. My team uses it to create their translation tools and accompanying web services. Really, I couldn’t be more delighted.

We’re using Maven, and my first response is wow! NB really nows how to integrate with a Maven project. The setup couldn’t be more simple. Open Project….bam. Everything is there, no fussing with classpaths, nothing. Thousands and thousands of lines of code with a dozen subprojects and dependencies just build without a single glitch. Beautiful.

Of course, this says something great about my team. They obviously know how to set up a maven project with all of the dependencies, etc. But to simply unleash an IDE for the first time on nothing but the downloaded SVN code and have it work immediately….I’m just impressed. That’s it. Just impressed and felt like saying “Thanks NetBeans!”


NetBeans finally imports my Eclipse projects

After once declaring that NetBeans still coughs on spaces, I’m ready to declare that NetBeans has resolved this issue.

At my current day job, I’ve been using Eclipse almost exclusively. Not of my choice really. Sometimes while in Rome, you have to do as the Romans. These particular Romans like Eclipse, so I too must use it. And really I didn’t have a lot of choice because the Eclipse projects had spaces in their names…and NetBeans just pitched a fit over this, making an easy migration to NetBeans practically impossible without changing the projects. I don’t think NB really cared that spaces where in project names, but the Eclipse migration tool itself sputtered on it. Until now.

That’s right. This week after cursing Eclipse’s support of Javascript, I longed for NetBeans. I thought I’d give it another try. Using NetBeans 6.7.1, I imported my Eclipse projects and NetBeans appears to work properly. No errors, no problems. My Eclipse projects are working in NetBeans 6.7.1 despite the spaces in their names.

And guess what….I’m going to use NetBeans again after 2 years away! Of course, you know the Java support of the IDE is amazing. But did you also know that NetBeans does JavaScript FAR BETTER than Eclipse does. Seriously. I’ve been in JavaScript hell for two years now, and I’ve wanted to scratch my eyeballs out sometimes because of Eclipse’s poor handling of JavaScript files. For example, just because I don’t create a whole “JavaScript project” in Eclipse, the Eclipse IDE doesn’t easily recognize JavaScript files. And that IDE just refused to give me method completion or even jump to a helper class if I CTRL+click the name in the IDE. But NetBeans handles this without a single problem.

I’ve always appreciated NetBeans for its excellent Java editing, but now I have another reason to use it. It works great with JavaScript too! …much better than Eclipse!

My valiant attempt to install JavaFX 1.2 into NetBeans 6.7

If you follow NetBeans development, you know that NetBeans 6.7 has been released this week. By far the friendliest IDE for JavaFX development has been NetBeans. However, in a very surprising twist, the latest NetBeans 6.7 release does not include the JavaFX SDK 1.2. Instead, the download’s information page clearly indicates that you’ll need NetBeans 6.5.1 if you also want JavaFX.

I’m sure there’s a good reason for not including JavaFX with NB 6.7. No one has said a thing to me, but I suspect he reason for not including JavaFX 1.2 is the JDK requirement. JavaFX requires Java SE 1.6 Update 13, and Update 14 is recommended. NetBeans requires only JDK 5 Update 18. Perhaps the NetBeans team doesn’t want to require Java SE 6 Update 13, even though the JavaFX team apparently must.

The NetBeans team didn’t include JavaFX 1.2 “in the box”. Maybe they want you to be able to continue using NetBeans on the older JDK? The JavaFX team, on the other hand, does not have the same large user base. They can require an upgrade to Java SE 6 U13 because, well….they simply don’t leave too many existing users behind by doing so. That’s reasonable I think, but it leaves you wondering whether JavaFX SDK 1.2 will even work on NetBeans 6.7. I mean…the NetBeans site doesn’t actually tell us whether it works.

Of course, I had to try to install the JavaFX SDK 1.2 anyway.

First, the JavaFX SDK plugin simply doesn’t appear in the list of available plugins for NB 6.7. That’s ok, you can add the NB 6.5.1 update site to the list of plugin repositories.

Once you do this, the JavaFX plugins show up in the plugin catalog:

Now that’s exciting to see. You’re just a single “Install” button click away!

Or so I thought…no. As soon as I pressed the “Install” button on the plugins page, a warning/error dialog tells me that an unmet dependency stands in the way. Something called the “Editor Hint” plugin is necessary:

Suppose we just forget the referenced “JavaFX Kit”? Would that work? I unchecked the JavaFX Kit plugin. Nope. The next complaint is against the weather example plugin. OK, let’s get rid of that. Now the only thing selected is the JavaFX SDK itself. After pressing the “Install” button again, I watch NetBeans 6.7 download and install the “JavaFX SDK for Windows”. OK so far, but I’m not sure what I’m going to miss without the JavaFX Kit plugin.

Other than a short message about the unsigned nature of the plugin, this JavaFX SDK plugin appears to install without a problem. But what does it give me? I quickly realized that all the JavaFX Project and JavaFX file type references that usually show up in the New Project and New File dialogs just aren’t available yet. Hmmm….that “JavaFX Kit” plugin is necessary after all. I bet it contains exactly what’s needed to add JavaFX file types to NetBeans. But that requires something called the “Editor Hints” plugin….sigh.

I’ve checked around the NetBeans plugin site. I can’t seem to find the “Editor Hints” plugin. If you know anything about it, let me know. Until then, we’ll have no JavaFX 1.2 in NetBeans 6.7. I feel like I’m close, very close. So come on Joshua M, Jasper P., one of you guys…if you’re listening….give me a hint. I know you know how to make this work…even though it’s not “officially” supported by NB 6.7 yet. :)

Will Oracle support NetBeans?

By now you know that Oracle intends to purchase Sun. It’s a welcome deal that will no doubt be approved by stockholders. It certainly has the board’s approval. So let’s assume that Oracle will own Sun by the end of summer. Now we can start asking some questions.

Will Oracle embrace NetBeans? Like many open source projects, NetBeans gets a lot of support from corporate interest. In this case, it’s no secret that Sun pours cash into NetBeans. However, Oracle already supports an IDE. Let’s make that two IDEs: JDeveloper and Eclipse. Both receive financial backing from Oracle already, and…well, my first thought is that Oracle simply won’t need a third IDE.

As Oracle continues to evaluate its new assets, how will it value NetBeans? Although I personally enjoy and use NetBeans, I don’t think Oracle will care much for it. Not that NetBeans isn’t an excellent product, but like I said, Oracle already has IDEs. In my opinion, NetBeans and its users will have to find new support elsewhere. I doubt Oracle will continue funding its development.

Hey, this is just speculation. I’d enjoy hearing your ideas, particularly if you think that Oracle will champion NetBeans in the future.

NetBeans 6.5 still coughs on spaces


I’ve been trying to slowly introduce NetBeans to my colleagues for over a year. I think they’d actually use it in our current products and projects, but NetBeans won’t make it easy for us. How’s that you ask?

It turns out that we have several projects named with spaces. For example, one project is Tag Server, and another is Agent Registry. Why spaces? Well, the original project was developed using Eclipse, and well…no one told the team that they shouldn’t use spaces. So they did, Eclipse doesn’t mind, and…. that’s the current situation.

I was really encouraged when I found out that NetBeans 6.5 has an Eclipse project importer. It slurped in our Eclipse workspace and projects in what appeared to be just an easy, casual task. It looked fine at first glance. I beamed with pride. My NetBeans was doing so well.

My smile didn’t last long. NetBeans soon began to sputter, gag, and choke. The problem is that NetBeans has had a long-standing problem with path and project names that contain spaces. NetBeans coughed up on the project when trying to compile and run it. It complained that my problem “might be because your user directory is on a Windows UNC path (issue #46813).” I don’t have a UNC path in this project; everything looks like very old-school paths. It’s all on my D:\workspace\… subdirectory. OK, yes, there are some spaces in those subdirectories. But spaces in file and directory names aren’t really special anymore.

Ugh. NetBeans is so close to being perfect in so many ways. Unfortunately, despite the fact that it could be my team’s IDE for most reasons, it cannot be our IDE for one reason. So why don’t we just change our paths and remove the spaces. One reason is that we have dozens of ANT scripts that work with these directories, and we’re on a short timeline ALL of the time. We just don’t have time to mess with it if it doesn’t work. So, NetBeans doesn’t get any traction here.

So, despite the fact that bug id#46813 is supposedly fixed in NB 6.5, something still apparently haunts the product when spaces are involved. Sigh…maybe I’ll try again another day.