1 2 3 Previous Next


197 posts

Back in the Saddle Blog

Posted by joconner Nov 14, 2012
After a long time away, I'm raising my head again on the java.net site. I once roamed these java.net streets as a JDK developer at Sun Microsystems, then as an end-user of the JDK while at a few startups, and now...well, I'm back again. This time, I've acquired years of J2EE experience, have created my share of SaaS and web service offerings, and have way too much to say about globalization of the world wide web to keep my mouth shut. Let's take this slowly. I don't want to get bruised and battered immediately. However, I can definitely say that I'm back in the saddle. You'll hear more on this blog about web globalization issues, Javascript, HTML 5, Unicode, and whatever bothers or excites me. But first...does anyone know how I can set up my OWN blog client for this system. I tried and tried for a couple years without much success. I'm hoping someone finally figured it out. :) Later, John O'Conner

This is a test of the java.net blogging system to see how well it supports non-ASCII, UTF-8 text.

Fight ?????

I notice that many of my older posts from the pre-Drupal days are now munged; non-ASCII, UTF-8 chars are now garbage characters.

Sigh...but new blogs seem to be correct.


I was experimenting with Java 7's Locale and ResourceBundle classes recently. Java 7 introduces two new Locale categories: DISPLAY and FORMAT. You can set the default locale for localizable user interface resources independently from the default locale for data Format subclasses. For example, you supposedly can set up a DISPLAY locale to display Spanish (es) resources for the user interface text but use American English (en-US) for date formats.

Sorry for the redirect at this point. I tried to submit the full blog post here, but had so much trouble with formatting the code snippets, that I have to send you to the full blog post elsewhere...sorry, really.

Read this and other blog entries at my blog site: joconner.com


Changes in Java 7 Locale Blog

Posted by joconner Sep 12, 2011

I admit that I haven't been particularly active in the i18n or Java standards bodies in the last few years. Pardon me, but I had a wild rumpus in a startup for almost 3 years, then joined Yahoo for a couple years, and BAM! ... during that time, the Unicode Consortium added emoji, and the Oracle Java folks overhauled the once relatively simple java.util.Locale class among other things. That'll teach me to turn my back on those folks.

You can almost forgive the Unicode people for their addition of emoji... BUT more interesting to me right now...have you seen java.util.Locale lately? What the heck happened there? Java 7 introduces Locale.Builder, Locale.Category, and a Locale.forLanguageTag method. With Java 7's support of BCP 47 (the best practices for language coding), the Locale got a beefy new Builder inner class to help with...well, to help with building BCP 47 compliant locales. More on this in a different post. With the BCP 47 support, I suppose you might need the forLanguageTag method too. Now here's what stumps me though -- that Category class!

As far as I can tell, this category is to help you differentiate a locale instance for two different purposes: user interface language and locale-sensitive data formats. The new categories are the following:


Do we really need a separate Category class to make that explicit?

Locale has another new method: setDefault(Locale.Category, Locale newLocale). I can't wait to play with this a bit more. I suspect that this will set the default resource bundles (DISPLAY) for UI language and the default FORMAT for things like DateFormat, etc. However, I can't understand why these two categories are actually needed in the platform libraries. Convenience maybe? You could always use two different Locale instances for this in the past, but I suppose this makes that easier? I'll have to play around with these to find out more.

You can see this blog and followups on my own joconner.com site.


Java 7 on Mac OS X? Blog

Posted by joconner Aug 20, 2011

I recently installed Java 7 on my Mac OS X system. Although the installation went smoothly, I did run into one problem that might not be a big issue for you.

I didn't go through the hassle of compiling it for myself. Instead, I opted to grab a precompiled JDK from here: http://code.google.com/p/openjdk-osx-build/downloads/list?q=label:Featured

Specifically, I chose the OpenJDK 1.7 universal (32/64 bits) from Mac OS X branch download. Then I ran the /Applications/Utilities/Java Preferences.app to 1) pull both 1.7 versions to the top of the list, and 2) select those 1.7 versions, and 3) unselect the 1.6 JDK I also have installed.

NetBeans seems to run just fine. I'm able to create a new target JDK for the IDE, etc.

Now the problem: I tried running jrunscript from the command line to do some simple tests of new functionality in Java 7. I have found the simple jrunscript JavaScript interpreter to be an excellent way to quickly access Java classes for simple tests, confirmation of APIs, etc. Oddly, the tool didn't run correctly despite being available in the JDK's bin directory. Here's the output of my attempt:

$ which java
$ which jrunscript
$ jrunscript
script engine for language js can not be found

 Apparently, the JavaScript engine isn't also included in this download? Ever see this? Hava a solution?

NOTE: I've updated this blog to avoid "mojibake" -- garbled characters. For some reason, the word TA in TANAKA in the name query key in examples was garbled. Originally all occurences of the word ? were prefixed with the character for TA...for the common family name TANAKA. After removing the mojibake, I think you can still understand the purpose of the blog. But it does make me ask....just what is wrong with displaying TA under this system.

Are you a web service API developer? A good one? Even great? Wherever you are on the greatness spectrum, I have a tip today that is going to make you better. But first, I have something to say. Yes, it is obvious really, but it's worth repeating. The web truly is a world-wide web. Unfortunately, a great number of globally unaware developers are on the global web. This creates an odd situation in which web services are globally accessible but only locally or regionally aware.

There are a few important things to remember when creating a global web service. Let's just cover ONE today: non-ASCII query parameters are valid, useful, and often necessary for a decent, global web service.

It seems so obvious to me, and it probably does to you. Sometimes a service needs to exchange or process non-ASCII data. The world is a big place, and although English is an important part of the global web, more people speak a different language. English is a big percent, but lots of people use Chinese or an Indic language too. Let's make sure your web service can process all those non-ASCII characters in English or any other language!

Let's look at some examples of non-ASCII query params:

In these examples, you must perform two steps to get the query params (both keys and values) into the correct form:

  1. Convert the keys and their values to UTF-8 if they are not already.
  3. Perform the "percent encoding" on each UTF-8 code unit

To do #1, you'll need to use whatever character conversion utility you have: iconv, the Java charset encoding converters, whatever.

The #2 step is the important one for this blog. For each hexadecimal code unit in the UTF-8 query portion, you must "percent encode" the code unit. Let's look at the first example query params:


The JavaScript function encodeURI actually does a good job of doing this for us:

encodeURI("name=?&city=??") produces the string:


Notice that you should also include this encoding for the keys in the param list. In the next example, I've used Japanese values for both keys and values.

encodeURI("??=?&?=??") produces this string:


Note that both the keys and vaues have been "percent encoded".

On the server side, your server will understand how to decode these values into their correct UTF-8 string values if you have configured it correctly. Correct configuration of a server usually involves a charset conversion filter for a servlet container and sometimes just a config setting for Apache.

More on this at a later time.



test Blog

Posted by joconner Aug 20, 2010

this is a test

I've wanted to know how to do this for over a year. Not having the time in the past, well, the task just got delayed over and over. Now I finally figured this out, and I'm sharing with you. Surely there are other bloggers that prefer to use their own blog client and MarsEdit in particular if you're using an OS X client.

So, without further delay, here is how I set up my own MarsEdit client to blog on java.net:

  1. Create a new blog account. Name it "java.net" or whatever you prefer.
  3. Provide the blog url as "http://java.net/blogs/<username>". For me, this was "http://java.net/blogs/joconner".
  5. For the System Name setting, choose "Drupal".
  7. For the System API, I chose Metaweblog. However, you may also be able to use the Blogger API or even AtomPub.
  9. The API endpoint URL is this: ?http://java.net/xmlrpc.php
  11. Maybe the most important part of this is the your blog id setting is "blog"....not anything numeric as you may have expected or have used in the past. Do not use a number here, use the text string blog.
  13. Your username is the same as <username> above.
  15. When asked for a password, you need to use the long blog password generated here: ?http://java.net/blogpass.php

I have one last problem to resolve. When I send my blog entry to java.net, the resulting entry is in draft state. I had to go up to java.net, log in and manually change this from draft to published. That's inconvenient.

If you know how to get me over this last hump, I'd very much appreciate it. I want to blog at java.net again, but I just would really prefer to use my own tool instead of the drupal web interface.


Yesterday a coworker complained that Excel wasn't displaying a CSV (comma separated values) file correctly. Our application allows the user to send a report via email. The application provides the report as a CSV file. Because the report can contain multilingual text, we've decided to encode it in UTF-8. Unfortunately, when users click on the file to display it, usually in Excel, all of the multi-byte UTF-8 characters display incorrectly.

The problem was immediately clear to me...Excel was opening the UTF-8 encoded files, but it was incorrectly identifying them as Latin-1 encoded files. In the absence of any charset identification, Excel must guess about a file's content encoding. In our environment, many host PCs use en_US locales with Latin-1 as the typical charset. Excel uses that default to read and display CSV files.

My solution to the problem was to use the byte-order marker (BOM) to identify the CSV file as a Unicode file. I instructed my colleague to prepend the FEFF character to the file. The Java application that writes the file uses a FileWriter that encodes to UTF-8 to create the CSV file. It was simple to just output the BOM as the first character in the file.

Now when our customers double-click on these files, Excel opens the file, notices the BOM, and automatically selects UTF-8 as the file's charset encoding. Now Excel displays the previously mangled characters correctly. And I was able to help resolve a problem with an easy solution.

Maybe you can give your applications a hint about plain text files as well. Writing the BOM to your file can help Unicode-enabled applications know how to decode your Unicode files.

 Everyone has something to say about the past. Few can see the future. Here are my predictions for 2010!

  1. Oracle will prefer Eclipse and will let NetBeans go. I don't like it anymore than you, but why would they support two (three with JDeveloper?) competing IDEs? Oracle's existing staff knows and loves Eclipse, their tooling is built around Eclipse, their plugins are built for Eclipse. Why change something if you don't need to? My only question is who will pick up the support for NetBeans, which is otherwise a great product and is definitely worth saving...just not worth it for Oracle.
  3. Chrome OS and Android OS will converge. The world doesn't need two new operating systems from Google, not for web apps. I know that these two OSes are coming at web apps from two different scales: desktop/laptop/notebook vs mobile phone. However, the APIs should be the same for maximum acceptance from the community, and that means these two will become one. You can read more about this prediction in one of my prior blogs.
  5. Google will buy LinkedIn. Although useful and still a great site, LinkedIn is getting a bit stale. Google could inject new ideas to make a good product even better.
  7. Oracle will sell off Sun's hardware business. Oracle with hardware? I can't believe it. It's too much of a departure from their software business. I think Oracle will push the hardware off to HP.
  9. Adobe will steal some of JavaFX's thunder this year prior to JavaOne by announcing its own, improved designer tool for Flex that actually exists and is available at the time of their announcement. Sun's JavaFX Designer tool will limp into existence at JavaOne 2010 and everyone will forget that Sun promised it before the end of 2009.

Got predictions of your own? Let's hear them!


Today's announcement of Google's Chrome OS is exciting in a few ways. I think it has implications for Java developers. With hindsight, I now think that Larry Ellison was hinting about Google's Chrome OS when he expressed some of his desires for JavaFX on small netbook-like devices.

So, without any real knowledge and armed with nothing more than a vivid imagination, I provide some of my predictions/speculations for the upcoming Google Chrome OS and the devices it will power:

  1. Google Chrome OS will be a slightly more beefy Android OS. More beefy because it will have additional hardware driver support you might find in a netbook. However, its essence will be Android OS.
  2. The Chrome browser (or a slimmed down cousin) will be the primary application on that OS. It's already integrated into Android via Webkit
  3. The developer API will be very similar to what Android G1 developers already use. Android G1 apps are essentially Java apps written to a Java-like API. Same Java language on top of the most important, core packages of the Java SE platform. And, of course, Google won't be able to call it a "Java" platform because it will be stripped down to what Google engineers consider only the core, "good" parts of Java SE APIs + Google's own Android APIs of course.
  4. Google Chrome OS will be attractive to Java engineers because it looks and feels so much like the the JVM...except it's really the Dalvik VM. Many simple applications that run on Java SE will be able to run on the Dalvik VM after a recompile. Or maybe you'll just have to run your class files through a simple converter to target the Dalvik VM. At any rate, Java developers will feel right at home.
  5. Google Chrome OS devices will need to get onto the network easily, seamlessly, regardless of Wi-Fi availability. Google really does believe that "the network is the computer". Without the internet, these devices will be severely hampered. Expect these devices to have multiple network access technologies built in. Wifi hardware will obviously be on board. But you can imagine it also having a cellular transmitter/receiver built-in too.
  6. Remember all that cellular radio spectrum that Google was interested in only one or two years back? Wouldn't it be just an awesome thing if Google purchased a huge portion of that and used it to make their Google Chrome OS devices be able to instantly jump onto that for network access? You  buy the device, punch in a pre-purchased code for access, and your notebook is on the net in 5 minutes! It will be incredibly, insanely easy to get on the network with your Google Chrome OS-powered device.
  7. Hey, what's that Google Voice project anyway. Only one of the coolest telephony projects around! Maybe Google will leverage this service? Here's a scenario for you: you buy a Google Chrome OS device, open it up, agree to the terms of a Google voice membership, get a Google voice number and Google account (if you don't already have one), and the device then connects to the network using the built-in cellular hardware to connect to some of that cellular spectrum that Google will or has already purchased.
  8. After all of this, or perhaps even before this, we all start to feel a little uneasy about just how pervasive Google really is. And despite Google's mistrust and derision of Microsoft, they begin to look a little bit like Microsoft too...really, really big and really, really powerful and located at every digital turn. But this time, instead of controlling your PC, they control your network. Ooh, there's a suspenseful novel in there somewhere.

Ok, some of that's just silly, crazy talk...or is it? We'll see over the next few months.

Oh, one last thing. I just cannot resist the urge to compare Google Chrome OS to Sun's Java OS. Do you remember that? I could hardly find any references to it, although I did find an old article called Inside the IBM JavaOS Project. At some point, Sun apparently enslisted IBM to help. At any rate, the Java OS project started (and ended) a long, long time ago. It's been a decade at least. Remember the Hot Java browser? I actually ran it and used it. I remember that one of our tests at Sun was to run the SwingSet demo on it. But now I'm just distracted. What was I saying? Oh yes, there are even more similarities. Java OS is to Google Chrome OS as the Hot Java browser is to the Chrome browser. Maybe Google Chrome OS will finally be the successful reincarnation of JavaOS?

It's all fun to think about, and as I suggested, pure speculation at this point.

The Flex guys have enjoyed this for a long time. When I discussed JavaFX with a friend who is familiar with Flex, he shrugged the feature off, clearing unimpressed with JavaFX despite his appreciation for the feature itself. Still, for Java enthusiasts, bind is a welcome language feature.

Another link and run post. Read more about using the bind keyword in JavaFX in the blog tip Binding var and def variables.

I hate to simply drop a link and run, but that's essentially what I'm doing here until others learn about my new blog Learning JavaFX.

My most recent dip into JavaFX involves for-loop constructions. And this experience brings up an interesting question for me. How do you access a variable outside the loop if it contains the same name as the "formal parameter" of the loop itself?

For examples of this and more details, read the blog entry:

Variables in a for-loop


Learning JavaFX? Blog

Posted by joconner Jun 14, 2009

Long ago, I started a series called JavaFX Learning Curve Journal. Those articles/journals were on java.sun.com at the very beginning of the JavaFX project. I recently tried to find some of those articles, and I think they've been removed or improved significantly. They're certainly not recognizable in their original form. That's probably a good thing. The language has changed since then, and we all know how absolutely misleading and frustrating an outdated article can be.

I'm still interested in this new language though, more so now than then really. When I moved from Sun a couple years ago, I knew JavaFX wasn't ready for prime time. I stopped tinkering with it. I stopped reading about it. I stopped writing about it. However, I'm re-evaluating now.

JavaFX certainly seems to be the future of desktop applications. I know there was a lot of denying that Swing and JavaFX were competing. But let's just face the truth ok. Limited resources, limited time, limited developers....Sun can't put its continuous efforts into both, right? Something will get starved for resources. I spent a lot of time becoming proficient with Swing. If you are a Swing developer, you most certainly put in a lot of time learning it as well. However, if you want to continue developing Java desktop user interfaces, I think the future is JavaFX. Sun just isn't backing down from it. Despite its shaky start, JavaFX does seem ready for serious consideration at this point.

So, I've done two things to jump back into the JavaFX mix:

  1. I've started a new blog called Learning JavaFX. If you're just learning this language, you can fumble along with me. We'll figure out some of it together. If I can do it (which is not yet proven), you most certainly can! I learn by doing and sharing. Hopefully, you'll benefit too!
  2. I've started a Twitter account learningjavafx. Subscribe to those tweets if you'd like. You'll find out where I'm succeeding with the language. And if you've read my blogs before, you know I don't pull punches either. If I don't like something about a tool, I say it, trying to be fair of course. So I hope to give it to you raw, my experience learning JavaFX.

I'm just getting started of course. So this isn't a bad time to start listening in, especially if you're just getting started too. We'll tackle this learning curve together, and hopefully have some fun along the way.

At JavaOne 2009, Sun demonstrated a new JavaFX designer tool. You can even view the demo online. To shortcut right to the section that shows the tool, move to about 23:00 minutes into the video.

There are obvious questions that are not answered. So obvious, in fact, that I'm slightly baffled that I can't yet find an answer:

  1. Where is this new tool?
  2. Is it a standalone tool separate from NetBeans?
  3. Will it plugin to NetBeans or Eclipse?

If I'm not mistaken, at the end of that video, Nandini said that the tool would be available at the end of the year. At the end of the year? Wow. Why announce something now that's not done?

Do you remember two (three?) years ago when Sun made its first announcements about JavaFX itself and presented demos of it at JavaOne? When we all got home, we realized that JavaFX wasn't really ready and we couldn't really use it. That announcement was definitely premature, but this year's conference gives me confidence that finally JavaFX is a consideration for me in my real job. However, why continue the pattern of announcing things so early? Why announce a designer tool that is apparently not available for even a preview download? Why? This behavior really is frustrating to consumers...that's me, a developer that wants to use JavaFX and any decent tool I can find. I'm glad that something is in the plans...but it would also have been nice to know what exists TODAY for designing JavaFX applications.

Filter Blog

By date: