How to Debug a Remote Java Application?

A Little Story

<skippable-story>

Recently I was working with a Java application that was bugging me when it was running in another country (USA) but it works fine when I run it on my desktop here in India. Of course, there is no connection with the geography except that the connection is slower. Every time I had a problem which is time consuming to reproduce on my desktop, I would login to that computer remotely through VNC client, reproduce the problem, get the logs, diagnose, and test it again there. You may ask, "Why don't you create a similar setup of that remote machine next to your desktop?" Trust me, there's a reason why I can't do it and I won't have a setup anytime sooner. Don't let that distract you about what I am trying to say, just forget it and assume I have to test it on a remote machine that resides in the same Intranet.

I was a having a conversation with one of my coworkers on phone about a particular problem and he said, "It will be slow but why don't you debug and see it?" My face turned red and I felt a little ashamed, I knew what he was talking about. He is a smart guy, I knew for sure he was not asking me to switch my whole development environment to some remote machine sitting on the other side of the globe. I hung up the phone, I walked to his desk and asked him. "Did you say debug?" He generously showed me how to do it. In fact, he thought that I don't know what is debugging and he explained me everything -- all that Step-Into, Step-Over, Step-Out stuff with its shortcuts.

It was easy for me to jump and say, "Dude! I know how to debug" but that would have been a wrong thing to do at that time. I know many people who come for help to me do this. So I quietly listened to him and gently said, "Yep, I'm familiar with that."

In case you have never done this before --here is how you do it. I will show how to do this using the Eclipse IDE, and I am very sure you are smart enough to figure out for your development setup.

</skippable-story>

Let's say you have your application compiled into a jar called myapp.jar and this will be running remotely on a machine called myremote.mycompany.com (or some IP). Your development machine is mydevel.mycompany.com. Now to debug the myapp.jar that is running remotely from your desktop machine, there are two steps you have to follow:

1. Start the application and tell the JVM that it will be debugged remotely
2. Configure your IDE on your desktop to be able to debug that remote application

Starting the Application with Remote Debugging Enabled

java -Xdebug -Xrunjdwp:transport=dt_socket,address=8998,server=y -jar myapp.jar

The above command says: start myapp.jar + start a server socket at port 8998 and publish the debugging messages using the Java Debug Wire Protocol (jdwp) there.

Other than address, server, and transport there are other sub options available for -Xrunjdwp option -- for example: suspend. I will leave that for you. Let's move on to step 2, that is configuring Eclipse.

Configuring Eclipse to Debug a Remotely Running Application

I will just show the screenshots without writing much, it's just intuitive that way.

1. Start Eclipse
2. Go to Run -> Debug Configurations



3. Create a new Remote Java Application configuration



4. Configure the remote application's details




5. If you would like to have this launch configuration in your favorites menu



6. Don't forget to click Apply

That it. Happy remote debugging!

What Is Your TO-LEARN List for This Year?

Face ISN'T the Index of Mind

I love reading interesting blogs. One of my very favorite blogs is BetterExplained by Kalid Azad. I was reading one of his posts which was about "Building a site you (and your readers) will love" and in that blog post he recommends a famous blog which I knew from a very long time but never read because they were monstrous (too long). It's none other than Steve Yegge's blog. I admire Kalid's writing and a recommendation coming from him is highly regarded by me. So, I went ahead and read a few blogs of Steve Yegge. Before reading his blog, I had a prejudice about Stevey and I thought he was just a guy who rants about things endlessly and the articles are boring and controversial (like VI vs EMACS). I never completed the first paragraph of any of his posts cause I was too scared and too tired to read due to the scroll bar's length. But this time around, I scheduled some time and read some of his writings.

I loved his blog. I missed them all these days, but that's OK. Yes, he writes BIG articles, but they are worth reading for a programmer. In one of Stevey's posts, he talks about Practicing Programming (isn't that my blog's name?) and he gives a few drills for us. That made me think about "What do I want to learn this year?" I will list them here now. This will make you aware or motivate you in learning the things you have planned but never did. That's what you can take from reading this post. You can also give me suggestions if you think I am wrong somewhere with my choice. The following is the list that I made to answer that question. All the suggestions are highly appreciated.

(X)HTML + CSS

I learned HTML & CSS just by looking at the source of a few sites, and to customize my blog just to a point where I will be done with what I wanted. I know "what" makes it work but I don't know "how" it works. And XHTML being the language spoken by the web server to the web browser, it is my necessity to learn it well. In my honest opinion, every developer must know XHTML in today's world. (Don't you want to have your own site?)

Book: Head First HTML & CSS

Shell Scripting

Don't I know? Yes, I do. Again, it is exactly like how I know about HTML & CSS. I want to learn stuffs thoroughly. I love Unix, I like to work on the command line. It makes me feel like I'm a rocket scientist doing complicated stuffs :). But that's not the point. Unix is tougher to use than MS Windows and both their philosophies are completely different. Learning Unix and Shell Scripting should be one of the top priorities for a developer who doesn't work on MS technologies. And we all the know the benefits of scripting.

Books: Any recommendations?

Regular Expressions

This should be fun. Regex is very powerful and great. But with great power comes greater responsibility. So, I should really be knowing what I am doing with it. I have written a few regexes, but I am just an ordinary user. I want to elevate to the power user category in regular expressions.

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. --Jamie Zawinski

Book: Mastering Regular Expressions by Jeffrey E. F. Friedl (O'Reilly)

Python

My favorite scripting language. I love the syntax though I seriously hope that it's source code documentation gets improved (the one that we get with the help() function). Again, I know, I can write scripts, I can figure out things. But I would like to learn more here. Probably, I need to spend more time or write an Open Source module that is missing. This will surely be a good exercise to learn more.

Book: Python in a Nutshell by Alex Martelli (O'Reilly)
Online: Tech talks about Python on Google Videos by Google's employees (Alex has one too)

C

I'm ashamed to say that I not proficient with the mother of modern programming languages. Yeah, I know what you are saying, I learned in school. I also learned rocket science in school, does it count at NASA?

Books: Any recommendations here?

J2EE

I will be working on real J2EE applications now, not the ones we try out for learning it. I learned a lot of Servlets, JSP, EJB and so on. But never implemented them or got a chance to do these things at work so far. But now, I have to. I will learn all the buzzwords like JMS, WAS, Web Services, EJB, etc. that you "cool J2EE" dudes talk about. (Am I sounding like Stevey now? Whatever!)

Books: No idea, just Google.

VI/VIM

Now this will be really hard. I use Eclipse for everything and working on something tougher than notepad should be real fun. I know how to use it, I am not a complete stranger to VIM. I even know how to enable syntax highlighting, and stuff. But I want more than that. I would like to do find/replace without searching vim.org for tips (regex again). I would like to find out the total number of lines/words/characters while I am in the editor (not using grep on shell). I would like to do copy pasting very freely. I want all this to be done and more without my conscious mind getting disturbed while it's doing some other task. VIM should become the extension of my hand.

Books: Any suggestions?

Subversion (SVN)

I love Subversion (do you know Linus Torvalds hates it?). I love Subversion because it is free, easy to use, has excellent support for IDEs and has a huge community. I have used Subversion before at my workplace, I use it currently for my Open Source project hosted at Google Code. But I want to learn more about it. I want to know how to setup an SVN server that supports http and https connections. I want to know how the authentication and authorization need to be configured. I want to know how to work with SVN just by using the command line interface (for fun). I want to collect the useful commands, tips, and best practices.

Book: Version Control with Subversion (O'Reilly)

Release Version 1.0 of Clipboard PingPong

That's the first open source software that I created which can be used to transfer clipboard contents across computers. It's at version "0.0.2" at present. I want to bring it to the general audience. Learning some of the things mentioned above will help me bring it in a better shape. It's really exciting, though it's very very small (I would like to keep it that way). Hopefully I will learn a lot from this experience and I can start contributing to other bigger and useful Open Source projects in future.

Blogging

Of course. This doesn't belong in "TO-LEARN" category but it's more of a TODO. Well, blogging about blogging is generally hated. So I won't go any further, it's boring too. But I would like to quote one thing from Stevey's blog post:

Even if nobody reads them, you should write them. It's become pretty clear to me that blogging is a source of both innovation and clarity. I have many of my best ideas and insights while blogging. Struggling to express things that you're thinking or feeling helps you understand them better.

The last line is so true.

What If I Don't Complete Everything I Mentioned?

I will be very disappointed. If I don't finish the mentioned things with *satisfaction*, I will push it to next year. But life is so short and knowing these things are necessary for anyone who wants to become a good software developer. Just knowing Java, using Eclipse and developing on Windows totally sucks! Life is much bigger and better than that. I will be working very hard and pushing a lot to complete these things. But quality matters more than quantity. I would rather learn half the things mentioned here thoroughly than just skimming through everything. In fact, I know most of the things mentioned here. I just want to know them better than an average developer in the streets. My quest is understanding better than just knowing them.

Next Year

It's too early but I left out a lot of things that were there in my head. These are the things I plan to do next year:

• Algorithms & Data Structures
• Algorithms & Data Structures (yes, I would like to do it twice)
• SQL in detail
  
• Unix Operating System in detail
• EMACS
  
• Ruby (could be replaced by Scala)
  
• JDK 7 new features (with a fresh mind after learning the other things)

That's all. (If you have read this far, you are really great!)

References

• BetterExplained
• Practicing Programming by Steve Yegge
• Python Tech Talks on Google Video
• You Should Write Blogs by Steve Yegge
  

The Anatomy of a Command Line

Command Line

Command line needs no introduction among the computer folks. We all know what it is. Yet, many of the developers are really scared to work on the terminal; they rather prefer GUIs. Command line somehow makes them uncomfortable. They think it is tough. In fact, when they design their own application's command line interface, they forget some of the simple and basic things they should have taken care. It will be one of my agendas in this post.

You may read this post even if you are not a developer, this isn't a developer specific post.

Misconceptions/Preconceptions

There are two kinds of people who don't prefer command line:

1. The ones who've used and quit because it looked tough at the beginning
2. The ones who've never tried (I call it the startup-syndrome)

I went through both the phases until the bulb glowed over my head. It shouldn't be tough, computers are easy to use. After all, command line is not programming. It is aimed at the end user. The Operating System designers must have came up with some pattern before implementing these commands. Yes, the keyword is pattern.

The Basic Syntax

A command consists of three main parts:

1. What to do?
2. How to do?
3. Other Inputs
   

Can You Show Me an Example?

Yes My Lord! Sure. Let's take an example. We will see the command line interface of the tail Unix utility. Here are the first few lines from the man page and I quote (please read it thoroughly once):

NAME
tail -- display the last part of a file

SYNOPSIS
tail [-F | -f | -r] [-q] [-b number | -c number | -n number] [file ...]

DESCRIPTION
The tail utility displays the contents of file or, by default, its stan-
dard input, to the standard output.

The part that is found difficult and that I would like to explain here is the SYNOPSIS. Remember the three main parts? The what? The how? And the other inputs? Let us see these three parts for this tail command.

The How part can be a little tricky for the newbies. You may even wander what is -f? -n? number? the "|" sign? Actually, that is what makes the command line interface friendly. This little table should help you understand about the syntax.

Anything inside []          = Optional
...                         = Can occur more than once
-something (or --something) = The How
option1 | option2           = Either option1 or option2 can appear

The "how" part can consist of two kinds of options. 1) Self descriptive options 2) Options that need more input.

tail -v -n 25 logs.txt

The "How" in the above command tells the tail command to print the last 25 lines of the file logs.txt and print the output in verbose mode. The below figure explains better.

The Design Difference

In a well designed graphical user interface, everything is presented to you. You need not remember or search for anything (like the -n option). GUIs follow the "push" model. Everything is pushed to you and you get to choose. You learn and discover things quickly. Whereas, in a command line interface, you need to tell what you want to do. You need to search and "pull" the options from the manual and tell the command "how" you want to execute it.

How *NOT* to Design a Command Line Interface

Have you ever used a command line that was like:

doSomething 49595 39504 "/usr/local/file" "/home/srikanths/dir/file"

You got the point. The "how" and the "other inputs" parts are totally messed up. You don't know the meaning of the numbers you are passing and even if you have a manual about this command, you need to refer it every time you use and you have to double check to make sure you pass the arguments correctly. A command line nightmare! Now, see the same command's better version:

doSomething\
-port 49595\
-fallbackPort 39504\
-configFile "/usr/local/file"\
-fallbackConfigFile "/home/srikanths/dir/file"

So, when you design a command line interface, make it more user friendly and follow the common pattern that is already there for decades now. There are many modules available either out of the box or as frameworks that can parse the command line arguments for you. Just search which ones are the most popular CLI frameworks for your language and choose one from that. Hope this post helped you!

Bottom Line

"The next time you tell someone RTFM, tell them how to RTFM."

References

• http://jopt-simple.sourceforge.net. A simple command line parser for Java.
• http://jargs.sourceforge.net. Another CLI tool for Java. The problem is choice :)
• http://docs.python.org/lib/module-getopt.html. The out of the box module for Python
• http://en.wikipedia.org/wiki/Command_line_interface
  

Other posts

• Cool Firefox Tips
• Calculate size of a MySQL Schema