Joshua Marinacci's Blog

The Power of the Desktop Java Stack

Big Brother, a screenshot client + webservice

The last year or so has seen a lot of growth for Java on the Desktop. The peformance, features, and deployment story is getting a lot better, but to what end? So we have a killer platform that lets you build cool desktop applications. So what? What can you do with it? More importantly, what can you do with it that you can't do (or can't do as easily) with another client solution like .Net, C++. What about webapps? What can we do with Java that we couldn't do easily with Perl, ASPs, PHP, Javascript and HTML? Well, this is sort of a trick question. I've asked: what can we do that is better than other client side or server side technologies allow. The answer is to be on both sides at once.

I've built an example application to show you what I mean. It's called Big Brother and it watches you. More specifically it takes captures of your screen, generates thumbnails, then uploads the images to a webservice that lets you link to the image from another webpage. It contains a webservice with a simple REST-y API (basically one POST and one GET) and a JNLP launched application to take the screenshots and do basic configuration. Here is a live view of my own desktop, updated every 10 seconds. When I'm not logged in then the thumbnail is still there (on the webserver), but won't be updated until I log in again.

A live view of my desktop

Easy for Developers

My goal was to make it as simple as possible for both programmers and end users. As a programmer you get a simple API that you could call from any language, not just Java. However I've provided a Java client that looks pretty good and will cover most needs. You can retrieve images using another GET call and submit then with a POST (with the image Base64 encoded). There are usernames but no passwords since I wanted to make this as open as possible. It's just a technology demonstration so it should be easy for new developers to get started. There's a great set of posts on O'Reilly, here and here about how to make APIs as open (and sucessful) as possible. I highly recommend you read them if you plan to make your own publically accessible web service.

Easy for End Users

For the end user, it's an auto-launched application that has as few options as possible. It tells you where your thumbnails will be stored, allowing you to embed the image in your own homepage with just a link. The user doesn't need to know about programming or how the webservice works. Just drop a link in your homepage and you're done. Couldn't be easier!

Easy to develop

The most amazing thing about the app isn't what it does, but how easy it was to build. BigBrother took me four hours to make. The vast majority of this time was figuring out how to safely get a binary file to a servlet using a post (I found a single class implementation of Base64 encoding that did the trick very nicely). I have since spent time tweaking the UI, adding features, finding graphics, and making a website; but the app itself was up and running very quickly.

With Swing, Java Web Start, and Java2D on the client, Servlets and JSPs on the server, and great network classes inbetween, we have a complete development stack. Everything you need to build a killer app is right there. You don't need to use another language, and almost any missing feature can be found in an easily integrated 3rd party jar. And because the Java stack has such great standards support you aren't restricted to just Java either. You can write the client or server portion in another language that supports the usual webstandards of XML, HTTP, HTML, etc. I could even embed a scripting language into my app, letting other developers hack on it.

Application Ideas

If rich clients are going to replace (or, more likely, enhance) existing web applications then they need to do things that webapps can't. I've been thinking along these lines for a while, looking for interesting applications I could build which would leverage the strenghts of Java on both sides of the NIC and make something new. Some sort of a hybrid application. Here are some idea's I've come up with. These are just play things, but get us thinking in the right direction.

• Control iTunes remotely from the web. We've got the hooks already.
• Deploy a pre-configured VNC client with an SSH tunnel to let me fix my mom's computer.
• make an iCal like app for ToDo lists. Publish the lists via FTP, WebDAV, etc. You can edit your lists using the rich client, and then share them using a web page or a rich client.

To find out more about Big Brother go to the home page. To Launch Big Brother right now using webstart (it's signed and needs system access to take the screen shots), then start it here.

The obligatory screenshots:

Comments

• "Deploy a pre-configured VNC client with an SSH tunnel to let me fix my mom's computer."

  
  Surely you mean a pre-configured VNC server. You would provide a JNLP link that your mother could click on. The link would install and launch a VNC server on her machine along with some mechanism of letting a VNC client on you machine access it. Right?

  "More importantly, what can you do with it that you can't do (or can't do as easily) with another client solution like .Net, C++?"

  
  End-to-end is a good answer for now. Portability and scalability are good answers, too. The goal for Java as a platform should be everything. There is no reason why Java can't be better documented, easier, more complete, less buggy, better, faster, stronger, and more fun at parties.

  Posted by: coxcu on May 17, 2005 at 10:39 AM

• Hi yoshi!

  First: very cool idea that BigBrother-App.
  But there's one point I noticed just after a few seconds:
  The web-link, where I can reach the uploaded thumbnail isn't markable.
  So I just cannot copy and paste it to my browser.. (on my xp box.)

  The ides for java's desktop future are right.
  Especially that "The answer is to be on both sides at once." is.. mmh.. cool ;-)

  greets, Toni
  

  Posted by: tonit on May 17, 2005 at 03:30 PM

• Joshua, that's neat little trick. But forgive me, it's artificial as well. In a business world what you showed here was not a proof of concept for a real problem, but a playful example for the high level of imagination you obviously possess. Don't get me wrong: It is a nice idea, however I fail to see your point. The ease of development has to be put into a context, which is the customer or user who should do something meaningful with the software we provide. How does this example convince me that developing secure, easily deployable and maintainable fat client application is easier done with Java than with another language/architechture? For me it simply doesn't. Right this morning I had another run-in with Java WebStart in a business setup. Little issues that can still drive me nuts. For me the crucial point of your post is this: You are a great programmer with a knack for cute solutions to non-existent problems. Maybe one day you'll invent a new market for monitoring apps, who knows, but this particular example leaves me personally with nothing. Sorry.

  Posted by: norb on May 18, 2005 at 04:20 AM

• Hey Josh,

  I recently encountered a situation where I needed to communicate information in the form of a binary file to a server which updated the file and returned it to the client which then updated the ASIC chip inside a hardware key.

  
  Before the java app, the process would be as follows:

  The customer calls tech support requesting an update. The tech support engineer would talk the customer through the following process.

  Locate the server computer that has the hardware key attached to the USB port

  Stop the license manager service on the

  Open control panel and select the hardware key control panel applet

  Click on a button and enter the name of the context file (A file which is a dump of the hardware key's memory)

  Send the context file to support as an email attachment

  The support engineer then runs a program that accepts the file sent by the customer as input and generates a new remote programming file that will be used to update the customer's licenses.

  The support engineer responds to the customers original email and includes the remote programming file as an attachment

  The customer then extracts the attachment and uses the control panel applet to update the ASIC chip on the hardware key.

  The customer restarts the license manager service.

  We now have a program in testing which will automate all of this.

  Now when a customer purchases more licenses they need only click on a jnlp link which launches a webstart agent that stops the license manager service, generates the update file, transmits the file to the server where an other app generates a remote programming file based upon customer purchases and returns the programming file to the client application which in turn updates the hardware key and restarts the license manager service.

  All of this happens while the end user sits by and just watches. The process used to take a half hour at best and now it takes 30 seconds.
  

  While the current process is Windows specific, it can be adapted to work with non-windows operating systems. This is one case where having java on the client and the server was very beneficial for us.
  

  Posted by: rabbe on May 18, 2005 at 08:54 AM

• Ha Ha

  So, someone hacked my screenshot to say It could show porn. Why yes, yes it could. But that's not the point. This is a development tool, not an end user application. Actually, it's not even that. It's just a technology demo to get people thinking. And apparently someone has. :)

  I think it's great. We should all spend some time thinking about crazy ideas and their implications. How else are we going to build great new software. I just wish the person who hacked the screenshot had also posted some interesting ideas of his own.

  Posted by: joshy on May 18, 2005 at 11:50 AM

• It was me! Actually, it wasn't hard.. and I'm sure you know why. I just didn't want someone to go getting you in trouble on java.net posting something lude or WORSE, something about .Net :-)

  As for my own interesting ideas? I have blogging software that runs in a Tomcat container that uses webservices exposed so that people can write their own interfaces to the blogging server, and also use Sun Microsystem's excellent Rome API for RSS generation and even audio blogging with the embed tag. I also use Apache's XML-RPC API to ping up to 50 servers on updating and even allow for the publishing of different RSS feeds for each source (i.e. JavaBlogs can only get your java.rss category feed if you wish). It also has category exclustion like Slashdot. It's on SourceForge.

  Posted by: bbjwerner on May 18, 2005 at 02:43 PM

• Oh, also the reason I didn't use Sun's XML-RPC is good info for people that want to ping aggrigators like Technorati or JavaBlogs using the ol' Weblogs.com ping interface, Sun's implementation (rightly) uses SOAP to send messages through RPC, whereas Apache's uses HTTP, which is necessary to talk to the Weblogs.com interfaces out there. So, for people writing pinging software, you have to use Apache's not Sun's.

  Posted by: bbjwerner on May 18, 2005 at 02:52 PM

This work is licensed under a Creative Commons License.