Java Application Logging Guidelines

Here are some guidelines or "best practices" for logging; they're hard-earned lessons from my own 17+ years' experience writing Java code as well as several other sources.

First and foremost: use slf4j​ exclusively as logging API, with logback ​as the underlying logging implementation.​ slf4j is a flexible API that can utilize any of the popular logging frameworks (logback, log4j, java.util.logging, etc) at runtime to provide the low-level logging implementation. As such, the only dependency in application components should be on the slf4j API; no class should reference any other logging interfaces.

Read your logs often to spot incorrectly formatted messages.​ 

This seems obvious, but I'm always surprised/appalled by how many developers blindly send stuff to log without ever looking at most of it in runtime. If you read nothing else in these guidelines, please please please at least heed this advice.

Am I the only person who catches himself trying to use Command+Space (Ctrl+Space in Windows) when I'm typing in software other than Eclipse?

Today is "strike" day to protest SOPA

Today is "strike against censorship" day to protest the SOPA and PIPA bills that are attempting to pass in the US Congress. Please educate yourself about the potential negative impacts of these laws and get involved.

http://sopastrike.com/strike

https://www.google.com/landing/takeaction/

http://americancensorship.org/

I've censored the following, in protest of a bill that gives any corporation and the US government the power to censor the internet--a bill that could pass THIS WEEK. To see the uncensored text, and to stop internet censorship, visit: http://americancensorship.org/posts/33408/uncensor

Silly password requirements

It's been a long while since I wrote an Eclipse-related post, but this just irks me enough to point it out:

What is this, 1995? Users should be allowed to use a passphrase instead of this archaic way of trying to make passwords stronger. This is silly.

My secret weapon for holding OmniPod pods in place

This question periodically comes up on the Tu Diabetes OmniPod users forum, so I thought I'd write a quick summary of my solution.
Wearing the pods on your arm, to me, is the most comfortable site, but many people seem to be prone to knocking them off or loose. My solution is to wrap a so-called self-adherent wrap around the pod and my arm. They're self-adhesive, don't stick to the skin, and have just the right amount of "grip" to keep from sliding off the pod with activity. They also seem to "breath" a little to prevent sweating under the wrap. And you can cut them to exactly the length you want to get it as tight as is comfortable for you.
Coban is the name brand (made by 3M), but to save a few $$$ I just buy the generic version from CVS or Walgreens. For example, here is CVS's product. Just make sure to get a 4-inch wide variety; the 3-inch ones are not wide enough to cover the entire pod and tend to slip off too easily.
In addition to holding pods tightly to the arms, I've also used longer lengths when I used to wear pods on my inner thighs.

UPDATE: Someone recently told me about http://www.bands4life.net/ - I like the idea; think I'll order one to try it out as an alternative to the coban-style wrap.

Setting up .java files to automatically open with Eclipse on Mac OS X

With the 3.6 (aka, Helios) release of Eclipse, there is now support for opening files from the operating system command line or file browser directly into Eclipse. This has been a long-standing feature request (one of the oldest requests to ever have been implemented, in fact) and many people are happy to have it. Here is a quick tutorial on utilizing this feature under Mac OS X to associate .java files so that they open in Eclipse upon double-click from Finder. Although this demonstrates using .java files, you can do the same for any other file type; as long as your installation of Eclipse has an editor to handle that file type, it should work just fine.

1. Just to re-iterate, you have to have Eclipse Helios (version 3.6 of the platform) in order to take advantage of this feature. If you don't already have it, go get it.
2. In Finder, locate a .java file that you'd like to open in Eclipse; right-click (or Control+click if that's the way you roll) and select Get Info
   
   
   
   
3. In the Info dialog, under the "Open with:" section, click the drop-down list and select Other...
   
   
   
   
4. Here comes the only tricky part about this process.
   In the resulting Finder dialog to select an application, navigate to where Eclipse is installed. You'll see Eclipse.app listed but chances are, it's disabled; you can't select it. You just have to enable it using the Enable: drop-down list at the bottom of the window, as shown here:
   
   Once you do that, you'll be able to select Eclipse.app.
   
   
5. Before clicking the Add button, decide if you want to select the "Always Open With" option (checkbox). Then click Add.
6. Back in the "Info" dialog, you can use the Change All... button to associate all .java files with Eclipse. Even if you don't do it now, you an always come back to this dialog and do it later.

That's it. Now when you double-click on .java files they will be opened in the Eclipse installation that you selected. If an instance of Eclipse is already running, that instance will open the file. Otherwise, a new instance will be started.

Tip of the hat to Oracle

As most Eclipse community members probably already know, a recent change by Oracle in the JDK/JRE for Windows caused serious problems for Eclipse. But in a sign that Oracle really does understand the importance of Eclipse in the Java community, as well as a nice gesture of cooperation and consideration, they've rolled back the change that caused the problems and released new builds.
I admire Oracle's willingness to respond quickly to this issue, in spite of the fact that Eclipse code was admittedly relying on non-documented and non-API data. Ian Skerret also deserves credit for directly engaging people at Oracle to make this happen.

Hats off to cooperation!

Launching Multiple Instances of Eclipse on Mac OS X

Doug Schaefer recently griped that Eclipse on Mac "gets no love." I don't really agree in general, but I don't have the time to debate that in detail. I do, however, have the time to provide a simple work-around to one of his gripes, the inability to launch multiple copies of Eclipse simultaneously. As Doug mentions, this is inherent behavior for OS X applications, not an Eclipse-specific problem. But, there's a simple way to launch additional instances if you're willing to perform a few mouse clicks.
The basics:

1. Right-click (Command+click) on the Eclipse Doc icon and choose Show in Finder.
2. Right-click on Eclipse.app and choose Show Packages Contents.
3. Navigate to Contents > MacOS directory.
4. Double-click the eclipse executable there to launch Eclipse. Make sure to select a different workspace than is already open.

Here's a short screencast demonstration (click the image to play):

The best $5 I Ever Spent on Technology

I recently discovered xGestures and someone had better tell my wife because I'm in love!
I've been a long-time user of mouse gestures in Firefox (the plugin I currently use is FireGestures, but there are others). I recently changed to a combination of Camino and Safari, but there aren't any really good gestures plugins available for them.
My search led me to xGestures, and it truly is the best $5 I've ever spent on a piece of technology. Not only does it make my browser more productive (or rather, almost as productive as Firefox on Windoze), but as an added bonus it applies mouse gestures to every application. It's an amazing productivity boost.
For those who aren't familiar with mouse gestures, they are an alternative input mechanism whereby you combine a mouse click with dragging motions in order to trigger a command or action. Basic drag-and-drop is, essentially, a mouse gesture (one that every personal computer user is familiar with); the iPhone and iPod Touch use gestures quite extensively. I've heard them described as "controlling your applications by drawing little mini-pictures with your mouse." Wikipedia introduces them like this:

In computing, a mouse gesture is a way of combining computer mouse movements and clicks which the software recognizes as a specific command. Mouse gestures can provide quick access to common functions of a program. They can also be useful for people who have difficulties typing on a keyboard. For example, in a web browser, the user could navigate to the previously viewed page by pressing the right mouse button, moving the mouse briefly to the left, then releasing the button.

[full article]

For those like me who make heavy use of the mouse, the productivity boost gained by not having to find menu items or awkward keyboard combinations is outstanding. If you've never used mouse gestures before, it's probably kind of hard to understand the value unless you try them out.
As I've said, I'm in love with xGestures on my MacBook, but there are also similar programs for Windows. I haven't tried any of them out, but some that look promising are:

• gMote
• StrokeIt
• MaZZicK

So, Planet Eclipse readers are probably asking why this is showing up there... Well, I haven't yet configured xGestures to do anything in Eclipse, but I'm thinking about it. Sometime today I'll set up some gestures for the things I do most frequently in Eclipse (like open the Find Type and Find Resource dialogs). But I'm curious if anyone else uses gestures in Eclipse and, if so, what gestures do you use frequently? I'm interested in exploring the power of combining the best IDE and this great "new" input method to make me even more productive. Eventually I'd like to explore the possibility of writing an Eclipse plugin that adds gesture support and contributing it for inclusion in the platform.

Also, if any Windows users have other gestures programs that you like, let us know.

Looking For an Easy Way To Contribute To Eclipse?

Are you an Eclipse user who is looking for an opportunity to get more involved, to contribute something back? Maybe you've considered reporting bugs (or even done so, but not consistently). Or maybe you've even thought about trying to implement a feature or fix a bug with a code patch, but were intimidated by the huge code base and/or ignorant of how to get started with that.
Well, if you happen to also be a Windows 64-bit user there is an excellent specific opportunity for you to get involved. The next major Eclipse release, code named Helios and based on version 3.6 of the platform, is considering offering 64-bit Windows versions of all the EPP packages*. But they need commitment from people who can test and report bugs with the Win64 builds; the team is small and given all the combinations of packages (there are now 9, maybe more by the time Helios is released) and supported platforms (there are currently 6, Win64 would be number 7), it's a daunting task to verify that each one is working correctly. But here is where you can help; if you are on 64-bit Windows you can offer to test the milestone builds of such a package and report bugs if you find them.
This is a low-barrier-to-entry way to contribute real value to Eclipse, by doing something (using Eclipse) that you already do. Plus, you'll get early access to all of the new features, enhancements, and bug fixes that the 3.6 release is bringing!
So, go ahead and comment on Bug 293969 and add your pledge to help test - I'm sure the EPP team would be thrilled to have the help.

* For those who don't know, the Eclipse Packaging Project (EPP) is responsible for producing the various useful packages of Eclipse projects that are the result of the yearly coordinated release train.

What's happening with Eclipse recently?

It seems that recent times have seen some disturbing (to me) trends in the Eclipse community, most notably the loss (or significant reduction of involvement) of several key individuals. I count myself in that group, since my 5+ month search for Eclipse-related development contracts came up dry and I ended up taking a local job that is totally unrelated to Eclipse. It seems that Eclipse has been bleeding valuable talent in the past year or so - or is it just me?

The most recent happening that concerns me is Bjorn's announcement yesterday that he has been locked out of involvement in producing EclipseCon 2010. While I'm sure the conference planning is in good hands, this seems like a strange decision given the past success; the cynic in me can't help but wonder if it has anything to do with Bjorn's recent outspokenness and willingness to voice controversial thoughts. Let's hope not...
Mike M. commented on Bjorn's blog posting with a most-politically-correct "thank you for your service," but that is a far cry from an open explanation. I think, given his contributions to and love for the community, that Bjorn deserves more of an explanation. I am certain that the community deserves a bit of explanation.

Mac OS X and Eclipse Debugger's "Drop To Frame"

After years of using it, I've become dependent on the debugger feature, Drop To Frame (described here, here, and here). Briefly, it allows you to select any level (frame) in the call stack during debugging and force the JVM to rollback to that point. It's a little difficult to explain briefly, but trust me when I say that once you've used it you quickly learn to depend on it.

So you can imagine my dismay when I recently started doing all of my Eclipse work on Mac OS X and discovered that Drop To Frame is disabled. It is a feature that not all JVMs support (specifically, those prior to Java 1.4), but I just can't believe that the modern Mac JVMs don't (I've tried running my apps in both Java 5 and Java 6 JVMs).
I asked about this on the Eclipse newsgroups/forums and on IRC, but no response so far. I'm hoping that the blogosphere might have some more insight...

Update: it seems that Drop to Frame is enabled sometimes, but only part-way down the stack, and sometimes not at all. The app I'm debugging has no native code in it, so that's not the culprit in this case. So I'm still looking for some insight into what enables/disables the feature.

My Experience with OmniPod

For those that don't know, I am an insulin-dependent diabetic. About a year and a half ago I changed from taking 3-5 injections a day, to using an insulin pump. But no ordinary, tubes-hanging-out-of-you, beeper-looking-thing-attached-to-your-hip, insulin pump - no, I chose the OmniPod tubeless pump system. I've had some requests for my overall impression, and below is something I wrote in response to one of those requests.

I've been a Type I diabetic for over 20 years and I can honestly say that OmniPod has changed my life. For me, not only is the technology an improvement over injections, but it has re-invigorated me and my interest in controlling my disease. In other words, using OmniPod somehow got me more interested in managing diabetes again, instead of being complacent.

Of course like most 'Podders, the big attraction for me was the lack of tubes. I had been turned off by traditional pumps for years because of the tubing, but OmniPod was intriguing because of the freedom from tubes that it offers.

As for cost, even with good insurance it is likely that using the OmniPod will cost you more than injections. My insurance coverage is pretty good, but I still have a deductible each year and then pay 20% after that (used to be 10% until this year). If cost is a big concern for you then you should definitely find out exactly what your policy covers. I think any kind of insulin pump is going to have higher cost. You local sales rep at Insulet can tell you exactly how much it will cost before you have to pay anything.
If you want specific examples... My deductible is $300 per year, which even before OmniPod I would easily use up for lab/blood work. After that, the pod cost is somewhere around $250-$300 per month, 20% of which I must pay under my insurance plan. So it's not dirt-cheap, but for me easily worth it.

I find the system to be very easy to use (but I am a tech geek and love all kinds of gadgets). Even for the average person I think they've spent a lot of effort to make it simple. The process of changing a pod has about 4-5 steps, but they are easy and the PDM (controller "computer") guides you through each one. I think after only 2 or 3 times the average person will be very comfortable with the process; and the training is very thorough. Honestly, think about testing your blood or taking an injection; think of how natural that is for you and how you don't really have to think about it while doing it. Using the OmniPod is the same; you do it so much that it quickly becomes second-nature.

I've only had one or two very minor issues, and with the help of the customer service and the local trainer I've been able to solve them. I've read of some people who have certain problems (like someone who says the pods don't stick well to their skin and try to fall off before the 3 days is up), but I really think those are the minority because thousands of people use it successfully. I've never had any kind of trouble like that, even though I am very active and play several different sports with the pods on (including wrestling with my 3-year-old son).

My control is much improved since I started using OmniPod. I was always turned off by insulin pumps because of the tubing; it was a big turn-off for me to be attached to a pump all the time. Now that I've been using OmniPod for over a year I can't imagine going back to injections. It is very discreet when I want it to be, but I've found it to be a great "conversation piece" too; everyone is fascinated to hear about it if I talk about it.

I love how it lets me be more free to do things like a normal person, instead of having to worry about carrying insulin bottles/pens, needles, and alcohol wipes everywhere. I am so much more free I can't even tell you!
Here's an example: this summer we took our son to Disney World for his birthday. We were at the park from 10am until 11pm. We ate at odd times, food that I was not certain of the ingredients or carbohydrate content, and several little snacks. Plus, we were doing lots of walking which tends to lower my blood-sugar quite a bit. That day would have been a nightmare if I was still using injections. I used to take Lantus as a basal, once per day, and then Novolog (pen) at meal times. I would have had to adjust my Lantus the night before to account for the exercise (walking) and then would have worried about keeping my Novolog pen cool throughout the hot day, taking several injections to cover the small "meals" and the unknown carbs I was getting. I would have almost certainly been too high or two low most of the day because of all the uncertainty and irregular schedule. But with the OmniPod, I was able to easily decrease my basal rate once we started walking, based on what my blood-sugar measured. And I was easily able to take a meal dose each time we ate something or I tested my blood-sugar and found it a little high. I was able to do all of this while standing in line for a ride or sitting on a bench watching my son play. No having to sneak off to the bathroom or some other private place to do an injection. I actually enjoyed the day with my family instead of worrying about my diabetes; I didn't really "think about" diabetes at all that day. For me, that is the big advantage of using OmniPod.

I guess I've written way too much, but hopefully this will help you understand why I love the OmniPod. If you have any more specific questions, don't hesitate to ask. In fact, I'd even be willing to talk on the phone if you'd like.

I am very enthusiastic, but I realize this is a big personal decision to make, and of course the OmniPod (or any insulin pump) is not the right thing for everyone; there are always some people who will be better off with injections. But I'd definitely encourage you to give it a try if you've been curious or considering it.

Updated Eclipse Community Forums plug-in

I've released a slightly updated version of the little Eclipse Community Forums plug-in I made last week. I added more of the standard web navigation buttons (back/forward/reload/stop/home) and eliminated the Login button/action (it was a real hack , didn't work 100% reliably, and I'm not sure anyone would really care about that feature anyway).
If you've already got 0.1 installed you should be able to update it from the About dialog, Installation Details, then select the Eclipse Community feature and click the Update button. If not, you can install it from scratch from the update site

• http://www.rizzoweb.com/Eclipse/updatesite

Still looking for feedback - even if it is "This isn't very useful, you should drop it."

Access the new Eclipse Community Forums from inside Eclipse itself

Thanks to Denis Roy, Eclipse now has a modern web user interface for its user/developer newsgroups. While I, personally, still prefer to use Thunderbird to access the newsgroups the "old fashioned" way, I'm sure many users will appreciate this big improvement over the old web interface.
The new forums site is still in a "beta" stage (please report any problems or suggestions to bug 284281), but I thought it would be nice to have easy access to it from right within Eclipse itself. So I've developed this little plug-in that adds an "Eclipse Community Forums" view to all perspectives. The View is basically an SWT Browser widget that is hard-coded to the forums site, along with some basic toolbar buttons for navigation.


A few notes on this "first draft" implementation:

• I've only tested it on OS X (Cocoa) so far; please let me know how (or if) it works on Windows XP, Vista, and Linux.
• The View is supposed to be automatically added as a Fast View to all perspectives (and it does correctly when I test it in a self-hosting environment), but when I installed it into an existing Eclipse instance I had to manually open the View via Window > Show View > Other...
  If anyone has some ideas why it isn't automatically added after installation, please let me know.
  
  
• The Login toolbar action currently only takes you to the Login page, but my plan is to have it (optionally) automatically submit your login credentials if you choose to store them. I need to get with Denis to help debug why my attempts at submitting a login via URL isn't working.
• The Shortcuts list is an extension point that any plug-in can contribute to. For now I've included just some of the more popular newsgroups forums; if I get this accepted as an official plug-in, the vision is that different Eclipse projects would contribute to the extension point to have their forum included.
• Notice the "Open in External Browser" button in the View toolbar (not the toolbar that is inside the view above the browser). I waffled back and forth on whether to put the Login and Shortcuts actions up there, too. If you have a UI design opinion about that, please let me know.
• My goal is to get feedback and improve this over the next week or two and eventually submit it for inclusion as a first-class citizen of the SDK and package builds. So please let me know what you think and help me make it better.

You can install the plug-in from this update site: http://www.rizzoweb.com/Eclipse/updatesite

Thoughts on Google's operating system announcement

The rumors have finally been confirmed, Google is working on an operating system.

My thoughts on this are simple and limited: I see a small niche market for such an OS, but I just don't see the majority of computer users willing to accept web-only applications across the board. Connectivity is just too inconsistent and unreliable at this point, and even trying to own "constant connectivity" access (3G-based mobile and/or wi-fi access point access) is still way too expensive. Do we really think the 3G carriers are going to spend billions to make 3G as reliable and fast as the broadband that we're all used to getting at home and work? I doubt it. Without that, the web-only user experience will suck, because it won't be consistent.
Not to mention that I, personally, consider most web-based apps that attempt to replace a desktop app to be inferior in key ways. There are exceptions, and things are improving, but not enough for me to see this being a broad appeal by next year.

Having said that, I'm not foolish enough to bet against Google, who have quite a track record of success when it comes to delivering on new ideas and technology.

Screencast: Creating an Eclipse download package "from scratch"

UPDATE: As of Service Release 1 (SR1) of Eclipse Galileo (aka, 3.5.1) the process described in this screencast is no longer necessary for 64-bit Mac OS X builds. 64-bit Cocoa builds of all the download packages are now available directly from the Eclipse downloads page.


If the cave you've been living in does not have Internet service, then perhaps it will come as news to you that Galileo was successfully released last week. It's a truly impressive feat to release so reliably so many projects year after year - you'd think that corporate internal and consumer software projects would take note and figure out what it is that enables the yearly release train to succeed when so many projects deliver late, over budget, or not at all. But, I digress...

Being a recent immigrant to the Nation of Mac, I was among the glad to see the Cocoa port graduate from incubation. However, all is not 100% happy in Eclipse+Mac land. The Eclipse Packaging Project (EPP), the small group that produces those easily consumable downloads, the themed packages of plug-ins built on top of the core platform, has limited resources. And with limited people, they can not produce the packages for every hardware/OS platform on which Eclipse is known to run. Of particular interest to me is the conspicuous absence of EPP package builds for 64-bit OS X. After some discussion, it appears we the community can't make a 64-bit build happen until the first "service release" of Galileo, sometime in the Fall. I'm disappointed, but I (mostly) understand the position that EPP is in.

So, what do we do if we want to make full use of all the 64-bit goodness of our operating system and Java 6 JVM? Well, it turns out that re-constructing the EPP packages from the "base platform" SDK is not all that difficult. Ekke Gentz has already blogged some text+picture instructions; my screencast below brings the process to life.

Note: the URL of the EPP update site used in the screencast is

http://download.eclipse.org/technology/epp/packages/galileo/

UPDATE: The package downloads page has been updated so that the Mac 64-bit SDK download is available directly, rather than having to go through the "Other Downloads" page. This makes the process a bit simpler than what is demonstrated in the screencast. If you're following this process for 64-bit Cocoa on OS X, you can get the Platform SDK directly in the Eclipse Classic section, as shown here (click to enlarge):

Looking for Work

About a month ago, the layoff wave finally caught up to me. Everyone at Skyway was gracious, saying repeatedly that they wish they had the money to keep me on board and that they'd really like to bring me back when the economy starts to turn around. But obviously I'm not holding my breath.

Here is my LinkedIn profile, including plenty of recommendations from colleagues and supervisors.

So if you know of or hear about any Eclipse-related positions, either contract or "perm" staff, please keep me in mind. For now I'd really like to try to stay in the Eclipse development world (designing/writing plug-ins and RCP-based applications, mentoring, training) but I'm open to just about anything to involves Java and Eclipse.

Eclipse: Talkin' To Users, Redux

This is a follow-up to Wayne's post about the Eclipse newsgroups. As I commented there, I understand that the barrier to entry into the newsgroups is higher than it should be, I really do get that. But, personally, I find web-based forums like phpBB to mostly suck. There are some things about them that I do wish we had on the Eclipse newsgroups, like:

• the ability to earn and give reputation points for good answers
• the ability to easily find threads that a given user has contributed to
• the ability to search across multiple groups easily.
  

It is true that, other than the points system, most of the other features of web-based forums can be done with newsgroups if you have a good client. But with so many people using web-based email these days, isn't it too much to ask them to install a separate piece of software just to participate in the newsgroups? I think so, much as I prefer newsgroups myself.
I've been trying to put my finger on why, exactly, I prefer newsgroups and I think it all boils down to flexibility. Because they are based on NNTP, an Internet standard, there are many clients that are capable of participating. That gives the user total control over his reading/posting experience. Contrast that with most phpBB-style forums, where the most control you usually have is the color scheme and whether or not you want a "flat" view or a threaded one.
The other big win, for me, that newsgroups have is the tight integration with my email; because I use Thunderbird all day to read multiple email accounts and RSS feeds, newsgroups fit right in like just another account. So, for me, it's flexibility and integration that win out.

In the comments to Wayne's post, someone mentioned FUDforum and it's newsgroups bridge. To me, this sounds like the best-of-both-worlds solution. It even has email list integration, so potentially we could offer total flexibility in how users participate: NNTP, web, or email, take your pick. To me that is an ideal solution.

So, are there any other options available? Either competitors to FUDforum that can bridge between web and NNTP, or some completely different technology? Remember, what I consider important is flexibility, giving choice and control of the client to the user, and integration with software I'm already using every day.