J. O'Conner Consulting

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!

It’s just a personal poll, but it says a lot about the popularity of NetBeans as a JavaFX development platform. A full 87% of JavaFX developers prefer NetBeans over rival IDEs.

See NetBeans 6 dominates JavaFX development for more information about the other IDEs in my recent poll.

A new poll on the Learning JavaFX site asks the question:

What IDE do you use for JavaFX development?

I know what I use…NetBeans 6.7.1. How about you? Answer the question for yourself and show your support for NetBeans!

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.

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.

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.

You might want to go directly over the the JavaFX website to download the JavaFX SDK, but if you work in NetBeans 6.5 you don’t have to bother. JavaFX 1.0 is available to NetBeans 6.5 users with only a few mouse clicks. Seriously, only a few mouse clicks will get the JavaFX SDK plugin for you and integrate it directly into your NetBeans 6.5 IDE. Here’s how:

1. Select Tools->Plugins from your NetBeans 6.5 menu.
2. Select the Available Plugins tab.
3. Click on the Reload Catalog button just to make sure you have a fresh copy of all available plugins
4. Scroll down the plugin list to find the JavaFX 1.0 plugin, and click on its check box. You can also select a JavaFX debugger and several demos in the same area of the plugin list!
5. Click the Install button
6. Continue working until the download is finished and restart NetBeans IDE

That’s it. Now NetBeans 6.5 has the JavaFX 1.0 SDK integrated directly. You should notice a new JavaFX Project type available to you when you select File->New Project

Sorry for the short post, but I have to get back to my NetBeans IDE and JavaFX. I’ll be back later with more information about my initial overview of the SDK, the language, and much more!

Several months ago, I submitted a bug against NetBeans 6.1. Sure, I expected someone to see the bug, but I didn’t expect the real and substantial interactions that followed.

After logging the bug, I received an email thanking me for my submission. A couple days later, when a NetBeans engineer was able to evaluate the problem, I received another email…this time with comments and even questions just for me. I responded. The NetBeans team responded and made comments on the bug report. The team engaged me, asked questions, and took my feedback seriously.

What an amazing experience! I was impressed by the team’s commitment to engage with its community, to interact directly with an individual.

Just yesterday, I received another email…this time to let me know that the bug fix is in NetBeans 6.5. The NetBeans community didn’t forget about me. I guess someone figured that I’d want to know the status of a bug…especially since I took the time to report it in the first place. They were right; I was interested.

I’ve always known that I’m a NetBeans user, but I would never have gone so far as to call myself a community member. I feel differently after this experience though. I’m glad to be part of the NetBeans community. If you use NetBeans, you’re part of the community too!

As a community member, exercise your rights to be influential in shaping NetBeans. You use NetBeans. Now do something to shape it and to improve it.

How can you get more involved in the NetBeans community? Here are some ideas:

• Write about your NetBeans experiences and share with others. Post your NetBeans knowledge in a blog!
• Create a plugin. I can’t think of a better way to learn how NetBeans is organized and designed.
• Help write documentation
• Join a mailing list or forum. Ask a question. Answer a question
• Attend a NetBeans community event
• or…submit a bug report!

Getting involved is easy, and there are dozens of ways to participate in this thing we call the NetBeans Community. Pick one of these suggestions, or find your own way to contribute. It’s really pretty simple to get involved.

Jersey is the reference implementation of JSR 311, the specification for creating RESTful web services on the Java platform. NetBeans 6.1, the existing, current version of NetBeans, contains a copy of the Jersey library, but it may be outdated now. Recently, the Jersey implementation reached version 1.0, and NetBeans 6.1 contains a copy of an earlier 0.8 release.

If you’re already using the NetBeans 6.5 release candidate, you also have the Jersey 1.0 library. The truth is, however, that we can’t all adopt pre-release, beta software. If you fall into the latter group and need to continue using NetBeans 6.1, you may want to update your Jersey library to get the final, 1.0 version. In this blog entry, I’ll show you how to update your Jersey libraries in NetBeans 6.1.

Download the latest, stable release of the Jersey implementation. I don’t particularly like the way that the library is provided. The download page requires that you analyze your needs first, and you must select the set of jar files you need. This is difficult for the beginning Jersey user. I suggest an all-in-one download — perhaps a zip file — that provides EVERYTHING a beginning Jersey user might need. I’ll lead you through this for now, but you must understand that your real needs may actually differ from what I suggest as a basic set of starter files. Again, you need to read the download page to understand the full set of libraries and their dependencies.

In my opinion, a beginning user needs the following files to create a Jersey enabled, REST service:

• jersey-bundle.jar
• jsr311-api.jar
• asm.jar
• Jersey javadoc

Put this files together in a library directory. Put them anywhere. For this example, I’ve put them in c:\bin\jersey. From now on, I’ll refer to your directory of Jersey files as JERSEY_HOME.

Create the Jersey_1.0 library in NetBeans. Open NetBeans 6.1 and select Tools->Libraries. You should see a dialog like this:

Select the New Library… option at the bottom of the dialog. You’ll see a prompt for the new libary’s name. Let’s call it Jersey_1.0

Add Jersey jar files to the Jersey_1.0 library. Do this by selecting the Add JAR/folder… button in the Library Manager for the new libary you’ve just created. Navigate to your JERSEY_HOME directory and add each jar file to the library.

Add the Jersey library to your project. Now you have the updated Jersey 1.0 jar files. They are available to your applications when you add your new library to your application project. Right-click on your project in the project view, select Properties. Then select the Libraries option in the Project Properties dialog. Now you can select the Add Library… option on the right side.

Find your Jersey_1.0 library in the available libraries list. Now you’ve got it! You have the updated Jersey 1.0 libraries in your Netbeans application project.

I reported that NetBeans 6.1’s project charset encoding feature would allow an unsuspecting user to destroy file data. That’s still true…through no fault of NetBeans really. It’s just a matter of fact — if you start out with UTF-8 and convert your project files to ASCII or ISO-8859-1 or any other subset of Unicode, you will lose any characters that are not also in the target charset.

Read more…