Apple, Linux welcomes you to 1998!

A lot of people are buzzing about Apple's Mac App Store, but I'm nonplussed. I've had the same features on Linux since the late 90's.
Granted, I'm being a little snarky — but only a little. Apple's App Store for the iPhone was a big deal because, before Apple, the application landscape for mobile phones was not that rosy. Apple simplified getting applications on the phone without having to deal directly with the carriers — so some credit is due there. They've also raised the bar in terms of what developers are shooting for for mobile devices, so kudos to Apple for that.
But the buzz over the Apple Mac App Store? Meh. Look at the features that Apple touts:

• Install any app with ease
• Keep your apps up to date
• The app you need. When you need it
• Buy, download, and even redownload

Linux folks, sound familiar? We've had all of this, modulo "buy", for a decade at least. The Advanced Package Tool, a.k.a. "APT" for Debian-based systems (that includes Ubuntu), has made all of this possible for years and years. Granted, this has primarily focused on free and open source software, but paid apps are possible too. The Ubuntu folks have had a paid software store since Ubuntu 10.10. (It is, I admit, sparsely populated when it comes to proprietary/paid software.)
But the installation, updating, and such? All very possible with APT — or Yum or Zypper, if you happen to be using an RPM-based distro. (Or APT for RPM, if that's still being maintained.)
Apple brags about having more than 1,000 apps available at launch... Ubuntu users can find 32,000-plus packages in the software repository for Ubuntu 10.10. Now, a bunch of those packages are not end-user applications — this includes things like libraries, system utilities, fonts, and so forth. But you could easily find 5,000 end user apps, many of which are competitive with the proprietary stuff being offered through the Apple Mac App Store. Oh, and free. Free as in cost, and all open source. (Not all Free by definition of the Free Software Foundation, though, but that's another topic entirely.)
Of course, what Apple has done that's unique shows Linux folks what we need to be better at doing: marketing, developer and ISV relations, and standardization. Lest you think I'm only hear to praise Linux or kick Apple, I'm not. Linux has had the raw tools to do this for a decade, but the communities and companies behind Linux have yet to gain enough momentum to pull this off on the desktop. Or the will to chuck tribal differences between desktops, toolkits, etc. and unify on one damn stack to attract the kind of developers that are filling up Apple's App Store. Canonical, bless their hearts, are trying — but it's unclear as of yet whether Canonical has enough pull to rally enough developers and inspire enough ISVs to drive even 100 paid desktop apps to Linux, much less 1,000.
The Linux community should get some credit here, though. What has been hard for the users of arguably the easiest operating system to use, has been easy for Linux users for years. A quick "apt-get update" and my entire system is updated, apps and all. A quick "apt-get install" and I can have everything from the Banshee media player to the latest Chrome release. Typing is not required, of course. Each distribution has GUI tools that make it very easy to install and manage applications.
And, it's important to add — I can do all this without the blessing of any single company. You see, while Apple controls everything that goes into the App store, nobody controls what users add to their APT, Yum, or Zypper repos.
So Linux users have had the tools and freedom, just a severe lack of marketing and developer relations smarts. That includes failing to have a single dominant toolchain (GUI toolkit, etc.) for companies to target. Seems that Nokia (with Qt) might be on to something here, though. It's pretty clear what the overall Linux community and vendors need to address, just a question if they do and if it's not too little and too late for any mainstream traction.
I do hope others in the tech press will at least, in passing, note that Apple has not invented something new with its App Store — merely taken an old idea and run with it better than the competition. Which, come to think of it, seems to be the company's specialty.

To subscribe to the "Guy WhoSteals" feed, click here.
You can add yourself to the GuyWhoSteals fanpage on Facebook or follow GuyWhoSteals on Twitter.

Understanding how Java Debug works

I found it surprising that many people that works with Java everyday doesn’t know that there are debugging options that go beyond clicking the “debug” button in your IDE.

You can just attach your IDE to a running application (which has been runned for debug as we’ll see later), or you can even debug it from command line. And the application you debug can even be be in a different machine.

The magic lies in where the debug information actually resides. Apparently people normally think that is the IDE that knows how to debug your programs, but the truth is that is the program who knows how to debug itself, and makes that information available to whoever wants to use it.

The way it works is basically the following. When you compile a program, the .class files get debug information within them, like line numbers or local variables that are made accessible to others who want to access this information. You can then run the program in debug mode passing the following options to your java program execution(you can of course run any java program like this, including mvn goals, appllication servers, etc)

-Xdebug -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=y

(you can also use -agentlib:jdwp instead of -Xrunjdwp in latest Java versions)

This line basically says: Run this program in debug mode, use the jdwp protocol, with a socket that listens to port 4000 and waits for connections to continue.

The jdwp protocol is a communication protocol used by the Java application to receive and issue commands and reply to them.

For example, you can connect to this port when the application is running an issue commands like “print variablex” to know the value of a variable, “stop at x” to set a breakpoint, etc. The application issues notification commands like “breakpoint reached”.
The truth is that the protocol is a little more complex than this, but this is enough to know to illustriate the point.

With the previous said, we can see that it would be even possible to debug an application with the use of Telnet! (we'll see later)

Well, enough theory. Let’s see an example Any simple example will do. We’ll make a simple program that takes two parameters from command line and prints the sum. The program won’t be well designed (In the sense that will include some useless temp variables, no validations, etc) but will do to illustrate the example.

class Sum{     public static void main(String[] args){         int sum1 = Integer.parseInt(args[0]);         int sum2 = Integer.parseInt(args[1]);         int suma= sum1+sum2;         System.out.println("La suma es "+suma);     } }

So we compile it: javac -g Sum.java (the g option adds extra debug info to the class. Like local variable names)
And we run it in debug mode: 

java -Xdebug -agentlib:jdwp=transport=dt_socket,address=4000,server=y,suspend=y Sum 3 4

Now we have the application listening on port 4000 waiting for connections

We will use the jdb command line debugger that comes with java. But first let’s try this. Run the following (you must run the second line fast after the telnet session starts)

telnet localhost 4000
JDWP-Handshake

That is the handshake to initiate the communication. You now have a debugging session with Telnet !

Ok, that was only to show, you (or i) would have to know the details of the jdwp protocol to use it. Let’s use instead jdb to debug our application. execute the following:

jdb -attach 4000

you’ll get some output like
Initializing jdb ...
>
VM Started: No frames on the current call stack

main[1]

That’s it, you have a debug session started. Now the interesting. Execute the following in your jdb session:

stop at Sum:6 You now have a breakpoint on line 6. execute run on the session, and the program will run until that breakpoint. you’ll get the output

Breakpoint hit: "thread=main", Sum.main(), line=6 bci=18
6 System.out.println("La suma es "+suma);


Now let’s see the value of our variables: run the following commands (one at a time) on the jdb session and see the results.

print sum1
print sum2
print suma
locals
set suma = 10
locals
cont

This is pretty cool stuff. You can debug your program from command line.

Of course if you have the opportunity to use an IDE like Eclipse you should take the advantage of it and still applying what you’ve learnt. So let’s do this.

You need to have the source code of the running application open in your eclipse as a eclipse project for this
Go to the step when you ran the program in debug mode. and run it.

Now go to your eclipse, go to the menu and select RUN -> DEBUG CONFIGURATIONS

In the left panel go to Java Remote Applications, and click new there.

Then select your project, write 4000 in the Port field, and click debug:

That’s it. you have attached your eclipse to the debugging program, now you can put breakpoints, do variable watches, and evaluate expressions from Eclipse.

That’s it. i hope this small article has helped you to understand a little better how the debugging of an application works and how you can debug and application that runs somewhere else.

For more Java Core information you can consult the good official book.

To subscribe to the "Guy WhoSteals" feed, click here.
You can add yourself to the GuyWhoSteals fanpage on Facebook or follow GuyWhoSteals on Twitter.