RoboGeek

Java, and dtrace dtrace is this amazingly cool new feature in Solaris 10 (hence, part of Open Solaris).  It is a solaris-only feature (by the way).

I've had in the back of my mind a nagging idea that dtrace could be used by my team (we are the SQE for Java SE, hence we're the ones who test Sun's Java before it ships out the door) in our work of testing Java.  But unfortunately I've not had much time to try dtrace.

One of the Java ONE sessions today was specifically about using dtrace with Java.  Having seen it earlier today, all I can say is WOW ... dtrace is one amazingly cool piece of technology.  However, it may have limited use in software testing (that remains to be seen).

First - the purpose of dtrace is around observability.  With it you can hook into probes all through a Solaris system and see what's happening.  The types of probes are many, and the variations you can bring to bear are so large as to make for an immensly huge set of options.  In the talk they showed how an idle Solaris 10 box (their laptop) started with 35,000 probe points, and after an hour of demoing jaw dropping features the system had built up to over 100,000 probe points.

What can you observe?  Anything for which probe points are available.  Out of the box that's a tremendous variety - for example you can track all system calls, and view several related parameters to the system calls.  e.g. consider tracing all "write" system calls along with argument 2 (the number of bytes written).  Related information is the process that did the write, the destination of the write, or even the stack trace in the application that did the write.  You can view the writes as they happen, or you can collect some data over time and present a summary-graph "later".

The probe points in Java are few, but powerful.  Out of the box you have a jstack() operator that returns the call stack of the JVM.  The jstack() operator is added onto another expression, so the java stack is captured in the context of a thread that made something happen.  For example it lets you see the stack trace's leading to your program causing a particular event to happen.

I said earlier it's not clear whether this will be uisefil in testing.  Here's my thinking ...

In writing a test case we a) set up a condition to be tested, b) write some Java code to instantiate the condition, c) have other code that tests and verifies the behavior, etc.  Verifying the condition is, e.g. if you click on a JButton does the ActionEventListener get fired (and/or propertie changes fire).  The probe facility doesn't seem to be organized in quite the way that would be useful for writing test cases like how we do them today.

On the other hand, dtrace would clearly be useful in many other situations.  e.g. diagnosing test failures when they happen, because dtrace can give an detailed tracing of program execution.  In fact, the tracing facility offers a very interesting capability - we can see a stack trace all the way from Java code, to the native code implementing Java, to the kernel code.  One of the dtrace scripts they showed follows program execution as it goes back and forth between these three levels.

UPDATE: It appears the author of the dtrace talk (who's also one of the original dtrace designers) commented on this posting.  From this I can capture several useful links:

DTrace Presentation at JavaOne His blog entry contains the presentation they gave.  However the most interesting part of the presentation was the demonstration of dtrace in action, including the follow.d script.

Solaris Dynamic Tracing Guide: Isn't that the most boring name for a document?  In any case, this is the book for learning dtrace for real.

DTrace forum on opensolaris.org: a BB on which dtrace is discussed.


(2005-06-30 16:03:24.0) Permalink Comments [1]

Unlocking the power of annotations Okay, I work in the J2SE team and I oughta know what's going into Java, right?  Well, not every new feature interests me enough to actually learn much about it, and, honestly, annotations are one of those features.

Okay, so you can say "@foobar" and attach it to classes, methods or inside method blocks.  What's the big deal?

One thing that's been nagging in the back of my mind is a claim that annotations would help reduce the complexity of writing EJB's.  That with annotations you could automagically write some of the EJB code.  But when I looked a little at the annotation feature, I went "huh"?  There didn't seem to be any code writing feature.

Last night I attended a BOF on the annotation processing tool (apt).  It's apt that does all the code writing magic.

In fact, the BOF author spent quite awhile comparing between apt and XDoclet2, showing how they do much the same thing, have much the same features.  The main advantage apt has is it's part of Sun's implementation making it available in the platform (NOTE: apt isn't part of the Java standard, it's just this extra nifty gizmo we add in).

The bottom line is:  With apt wired up correctly you can do the code writing things that I understood annotations were meant to perform.
(2005-06-29 17:41:23.0) Permalink Comments [0]

Container managed Swing I've written about this before (A server-side appframework to assist Swing app development?) and just came out of a Java ONE talk focusing on the same topic.  I think this is something "we" (the Swing Developer community) should get our heads around.

The talk was given by Ben Galbraith who wrote this java.net blog entry:  Microsoft Technical Summit, Threads, and Swing

In his talk today he went over and over how many of the problems Swing developers face are rooted in threading problems.  Hey everybody, when your listener method is called, it's supposed to return quickly.  This isn't just a Swing issue, as it applies to most GUI toolkits I've looked at.  If your listener takes awhile to return, then Swing/AWT can't do any repainting, handling further events, etc.

Galbraith, in the blog entry, quotes the C# designer saying that "Concurrency is hard .. there aren't enough Ph.D.'s in the world".  Meaning, for Swing, that it's really stretching to expect Swing developers to get threading issues right all the time.  As app complexity grows, the use of SwingUtilities.invokeLaterAndWait gets more and more complicated, and other tools like Foxtrot and Swing Worker get developed to patch around the complications.

Galbraith looks at the situation - and he sees how the J2EE "Container" concept greatly simplifies server side application development.  Using the simple Servlet model, a single Servlet can build a huge website, and the programmer doesn't have to bend any hairs out of place worrying about threading.  The container takes care of all the threading.

It's not just Servlets (nor JSP nor other things you can put in those containers), you have Doclets, aptlets, APPLETS, collablets, and more.  Yes, I did say APPLET, because if you think about it, the Applet class hides a lot of the complexity of interfacing with the web browser.  An Applet writer has 5 or so methods that get called to notify of important lifecycle events, but if you consider what has to happen under the covers if, for example, there are multiple Applet's on a page, sharing screen real estate between two applications, memory models, threading models, container security between multiple Applet's on a page, and more, there's a lot of complexity that's abstracted away by the Applet class.

There could be a large gain - to have a way to simplify creation of complex Swing applications.  If done well it could drastically simplify the life of Swing programmers everywhere.  Think of how easy it is to write a JSP.  What if you could build a Swing app out of managed components that have a simple model like JSP's and where the container abstracts away all the complexity?

Okay, I can think of a couple problems - e.g. Once you start providing a framework, then you're telling people how to write their programs.  Or are you?  Does the servlet/JSP model get in the way of writing server side applications?  No.  That tells one that if you take a lot of care in designing the framework, it actively helps applications developers.

There's a lot of smart people in the Swing community.  Surely we can get together and design a framework that's widely useful in the way I've just described?
(2005-06-29 17:16:35.0) Permalink Comments [1]

Ultra-thin swing client app's A lot of my blogging on this site recently has been about different ways to deliver a "rich client" experience ... and specifically the tradeoff between Java and the AJAX concept.

AJAX (for those who don't know) is a technique of using the Dynamic HTML and JavaScript features in web browsers to build what looks like a rich client, but it's in a web page and requires no more than the web browser.  The story is going to get more interesting in a year or so as SVG support becomes standard in web browsers.  Obviously AJAX is trying to fill the same space that Java APPLET's have been trying to fill for a long time.

I'm at Java ONE, and came across an interesting product that approaches this from a different angle.

InsiTech's product is XTT.  Disclaimer, I haven't tried the product yet, and only talked with the company COO.  However it's features are impressive and interesting.

If you want to build a fancy client in todays environment, there's a wide range of protocols, database engines, object/relation mapping technologies, etc.  If you built a Java desktop application for that, you'd be downloading a huge pile of JARS into each desktop system, and having issues with updating each of the desktop systems, and dealing with the long download times of getting all those JARS into each desktop.  Of course Java Web Start helps with deploying the applications, and PACK200 helps with the download size, but if you could minimize all that you'd be ahead of the game in the first place.  Further, if the application size were minimized, the memory size on the client system would be minimized.

That's the effect of the XTT product.  Basically they're providing an IDE plugin to provide a VB-like experience in building a Swing app.  Their idea is to push all the complexity to the server, keeping the client as thin as possible.  They provide an XTT-specific protocol that lets the client app talk to a server, and the server does all the complexity, including talking to the variety of SOAP/XMLRPC/etc protocols and databases and so forth.

As I see it, the advantage is to provide a richer client experience than the AJAX approach can do, while keeping the overhead small.

(2005-06-28 18:18:12.0) Permalink Comments [1]

Universal binaries There's been a long standing dream in the computer industry.  That you could take a piece of software and run it on your computer.  That you can choose the computer based on your perceived needs, and that you could take any software and run it on that computer.

What gets in the way?  Different CPU's and operating systems.  It's a trap, really.  The OS vendor tries to trap you to their operating system, and makes a deal with the chip vendor(s) so that the OS has the chip support it needs.  And the trap goes even further, to the application vendors that trap your data within proprietary file formats.

A few weeks ago Apple announced "Universal Binaries" as part of their switcheroo from the Power PC chips to x86 chips from Intel.  Somehow they're working some magic so that applications figure out which CPU they're on, and switch the binaries for the current CPU.  Hmmm...  Neat trick, but you're still trapped to a specific OS (Mac OS X).

The "universal binary" concept has been around a long time.  The earliest form I know was the "UCSD Pascal" system, or the FORTH language.  Back in the early 90's the "Open Software Foundation" concocted a method where applications would be shipped in a compiled-intermediate-code format, and on installation it would be compiled to the hardware instructions of the local system.  There's also been BASIC interpreters and various other interpreted languages, like TCL, Perl, Ruby, Python, etc.

And, of course, we have Java with 10+ years of supporting the universal binary idea. 

It works pretty well, really.  For example I remember the Moneydance (http://moneydance.com/) author talking about his Mac OS X portation work being to simply copy the JAR files to a Mac and run them.  But of course it isn't as simple as that, which is exemplified by the people who complain about how Swing doesn't match the native look & feel.  But, really, anybody who's spent time in the cross-platform-GUI-toolkit business ought to know just how hard it is to do this.

I wonder if there's ever going to be a real solution to the universal binary problem - and one that doesn't give one company an outrageous control over the computer industry.

That is - one solution to the "universal binary" problem in todays market is to say "Okay, Microsoft, you own the OS that everybody runs".  Whatever Microsoft wants to supply in the operating system, then that's what we the computing public would get.  That would certainly solve the initial problem wouldn't it?  If all computers ran the same kind of chip and the same OS, then we'd all be able to pick between our choice of computers and run our software on any of them.

But what would we lose by having only one OS vendor?  A trap is a trap is a trap, isn't it?
(2005-06-28 15:09:34.0) Permalink Comments [0]

No need to apologize for being a Swing developer At lunch today (here at Java ONE) I was talking with the guy next to me - I introduced myself as a Sun employee working on "testing Java", and the first words out of his mouth was "oh, you don't want to talk with me then".

He explained that he develops a suite of distance learning applications, using Swing for the UI's and RMI to connect to the server.  I suppose he expected me to be J2EE centric and only want to hear about EE applications.  But, that couldn't be further from the truth, since I'm much more interested in the desktop client side of Java, and in general see the desktop client part of Java as being much better than the typical perception in the public.

So, I just wanna say to you Swing developers - there's no reason to apologize for using Swing.  Swing is cool.

(2005-06-27 13:33:41.0) Permalink Comments [6]

At Java ONE Well, I'm here.  Today I'm pretty tied up with the "Hands On Lab" this afternoon.  The HOL is a cool thing, where basically we've made a number of tutorials available for you to try out different technologies and get your feet wet with using them.  For example one is "How to compile Mustang" which takes you through the Java source code and shows you a few things about compiling parts.  If you want to try your hand at fixing Java bugs, you're gonna need to know how to build Java.

(2005-06-27 13:29:27.0) Permalink Comments [3]

Rich user interface (Swing) seminars, at Be JUG web site BeJUG Rich User Interface Seminar Slides Online

BeJUG Rich User Interface Seminar

They had a full day of presentations, talking about "thinlet", "Open Lazlo", "XUI", "Spring-RCP" and other projects.  On the page are pointers to many other related projects that didn't have presentations on the day of the seminar.


(2005-06-22 16:29:24.0) Permalink Comments [0]

Java ONE is coming up Yes, it's that time of year again for all the Javanauts to brave the cold of summers in San Francisco.

As a member of the Java Quality team, my viewpoint of Java ONE is different than most.  I spend my time looking at YOU (the people who use Java) to see what you think of the product we're building.

Why?  It's simple, really.  The more we know about direct customer requirements and needs, the better we can make Java.  As I go through the year from one Java ONE show to another, I remember the things "you" have told me at the show.

This year I'll be working in the Hands-on-Lab area as a proctor, as well as attending talks and generally hanging out.
(2005-06-21 15:02:37.0) Permalink Comments [0]

Re: "What SWT Can't do" Matthew Linde has interesting food for thought in:  What Eclipse’s SWT Can’t Do.  It's also referenced here with a few more thoughts.

Basically - to build a largeish application, you're doing more than writing the GUI code.  I learned this the hard way with the first large GUI application I build 15 yrs ago.  There was a spaghetti like maze of interdependencies between the UI and the real code, and from that I learned a lesson the hard way. 

When you design a GUI application it's best to architect it into modules ... the UI is best to be a simple thin layer over the modules that implement the real logic of the application.


(2005-06-20 13:35:31.0) Permalink Comments [2]

New GUI builder for netbeans, targeted to v4.2 I don't know what the problem with the netbeans GUI builder is.  I've tried several GUI builder applications in the past, and always been stumped about how to use them to develop a GUI application.  With the netbeans GUI builder it made so much sense.  Plus, the generated code didn't suck.

Well, okay, it made sense until I tried something complicated with the layout manager.

Yesterday I saw Scott Violet give a demo of the improved GUI builder that's targeted to netbeans 4.2.  I see from New GUI Builder Demo is Live that it's safe to talk (a little) about the demo I saw, so here goes.

It was pretty exciting, the features that Scott showed.  Mainly, the focus is to have the GUI builder help the App Developer work within the platform guidelines.  Scott explained that the GUI builder depended on a new layout manager, which will be available somewhere as an open source project, and then (probably) later integrated with Swing or AWT.  The new layout manager is doing some of the magic of querying the platform for layout guidelines, and then managing the details for the programmer. 

What the programmer sees is that when they drag components to the work area, various visual feedback indicators show up to guide the placement of the component.  Plus, if you're laying out labels with associated components, the builder automatically readjusts the label positioning to vertical alignment with the associated component.

More info is here:  Project Matisse is coming! (2005-06-03 15:50:43.0) Permalink Comments [0]

Re: The Java performance debate Re: The Java performance debate

This is a very interesting article that goes over the major myths of Java performance.  The author tries to address the "Java is slow" and "Java is a memory hog" issues.

For example, under "Java is slow" people are probably remembering the old days when the JVM only interpreted the byte codes.  Today the JVM includes a compiler that turns byte codes into real native code, and once the byte codes are compiled to native the execution happens at native code speeds.  Unfortunately that compilation doesn't happen immediately, instead it happens only for code that's being executed regularly.  The VM developers don't want to waste CPU time compiling code that's going to be executed once or twice, instead they know the greatest bang is to compile the code that's executed a zillion times.

Towards the middle of the article he gets into territory I've thought about quite a bit.  I think a lot of the "Java is slow" perception comes from Swing applications.  This isn't necessarily because of Swing itself, but instead because of poorly written applications.  As Andy Roberts says, you can write a slow GUI application in any language.

In GUI applications "slow" always means that the application has poor responsiveness.  Responsiveness is the time between when a user requests an action, and the action is perceived to be finished.  CHI researchers have for a couple decades known that when a user says "this application is 'slow'" they were referring to response time.

It's easy to write an application with poor response time.  GUI applications center around what in Java we call the event listener's, and if you write an event listener that takes a long long long time to compute something, then the GUI will not repaint during that computation.  That's because the event dispatcher is waiting for the event listener to finish.

I know that it's possible to write a Swing app that deals with a large amount of data and is also fast.  How?  I did one.  A couple years ago I wrote a Swing app for internal use in my team, that read in a number of large XML files and image files and did major manipulations on them.  The XML files were read to a JTreeModel, that behaved very well.  The image files often had major image processing computation done, which happened so fast that I never bothered to work out a way to cache results, but instead recalculated them all the time.

At the same time I've seen several Swing apps that were pretty slow.  For example Netbeans prior to v3.5, while todays Netbeans is very responsive and slick.  The difference largely was optimization done by the Netbeans team rather than any change at the Swing level.

In fact this part of the article just reminds me of the posting I made last week.  Apparently I misunderstood the reason for using Spring in a Swing application.  However, I made an observation that Servlet containers hide a lot of threading complexity that Swing programmers have to face.

Threading and avoiding deadlock is obviously a hard problem.  Server-side programmers don't have to worry about threading, because the servlet container takes care of that for them.  On the other hand Swing programmers have to learn about threading, or else they'll make their app slow and unresponsive by doing long-running tasks on the event dispatch thread.  Further if they're niaive about moving long-running tasks off the event dispatch thread, they might end up doing GUI calls from a different thread and then running into problems with Swing.


(2005-06-01 14:45:39.0) Permalink Comments [4]

"Swing redraw issue" Re: Oracle's ODM tool has a Swing re-draw issue?

The author, Vik David, is describing using the Oracle Directory Manager (ODM) to manage an LDAP server.  ODM is a Java application.  He describes logging into the application but not getting the expected tree full of LDAP entries.  "Oh", he goes:

I have news for Mr. David.  This behavior isn't unique to Java applications.  I've used that trick for many years, and long before Java ever came to the scene.  Namely, doing a small resizing of the window, to cause GUI applications to repaint.  By doing the small resize it causes a PAINT event to arrive in the application, and the application responds appropriately.

The need to use this trick always indicates incorrect coding by either the application or toolkit developer.

(2005-06-01 14:04:38.0) Permalink Comments [1]

A server-side appframework to assist Swing app development? While browsing the blogs yesterday I came across an oddball proposition.

Namely, they're using Spring, a serverlet app-framework, to make it easier to write Swing applications.  With such a head-twisting idea, one wonders WHY???

In "Remedial Spring Rich Pt 1, Seting up" we see why.

The basic idea is this: developers are often complaining about the complexity of the Swing API… doing simple things is easy, but building real applications involves a very steep learning curve, and is likely to require a lot of application plumbing code (think data binding, wizard effects, registries to store common GUI actions and global references to disparate GUI components). This work is tedious and isn’t the reason you set out to develop a rich client.

Swing app frameworks and containers could solve many of these problems by providing a more high-level API for developing Swing clients, and leaving the tedium (and maybe even multi-threading) to the container or framework. Commonly needed functionality could be more easily plugged into your application. The topic is very sexy at the moment.

Okay, there's a limited number of really brilliant developers, and a larger number of average developers.  To reach the average developers with Swing, the argument goes that Swing needs to have a simpler model.  The difference is probably mostly to do with the threading.

Swing is not thread-safe, because 2D and AWT are not thread-safe.  Hence to make changes to the GUI, the code making the change has to call Swing/2D/AWT methods from the event dispatch thread.  But at the same time long running tasks fired by an event listener are supposed to happen on their own thread, so that the GUI doesn't get blocked while the long running task is running.  For a small scale application this isn't a big deal, but once the application gets big enough the thread issues get pretty large.

The problems of avoiding deadlock are among the toughest in computer science.  The argument I see in the proposals is to simplify certain issues, especially threading, through the use of an appframework.

Comparatively on the server/servlet side of the world, the application developers aren't exposed to grunty thread issues.  The servlet container takes care of all the threading issues, and the servlet developer simply gets called during certain moments in the lifecycle of the application.  This lets the more average programmers write servlets, and apparently the average GUI programmers get stumped by Swing and apparently stomp off in the other direction.

I haven't looked at Spring .. however I've written a few JSP's.  It's clear that servlets probably cannot directly translate directly to a GUI application, and it's just as clear that the general concept ought to be applicable to GUI applications.

The general concept of a servlet is that you write a blob of code that exports a given Interface.  The methods on that interface are called at given moments in the lifecycle of the application.  There is also output from the methods, and that output is automagically gathered up to return it to the caller.  The APPLET model is similar, and is a similar simplification because if the APPLET programmer had to deal with all the idiosyncracies of the various browsers they'd have run off screaming in the other direction long ago.

Just thinking off the top of my head - one could define an interface that allowed binding an Action to an event, and tells the Action one or more GUI elements it is to deal with.  The Action's methods would be called on a worker thread, and the interfacing would take care of exporting calls to change the GUI elements to occur on the event dispatch thread.

(2005-05-20 14:55:27.0) Permalink Comments [4]

A "JTable" clone in javascript

OS3Grid - Grid for Web Sites

I saw this announced on freshmeat and found it interesting.  It's written in pure javascript and runs across browsers.  And, it causes me to write again about the rich client experience.

The look is similar to the JTable, but the functionality is nowhere the same.  For example, while you can click on column titles to sort the table by the column, you can't drag column titles to rearrange the table, nor can you resize rows or columns by dragging.  Still, it looks to be a pretty convenient way to put a table in a web page and have a little more interaction than the HTML TABLE element allows.

For example, on twiki sites if you build a table, clicking on a column header lets you sort the table by that column.  But to do so means a round-trip between the browser and the wiki software so the wiki software can reformat the whole page with the table sorted a different way.  THis is very wasteful because it makes the user wait.

The rich client story is to do that sorting in the client.  A rich client knows a little more about what the data is, and can act directly on the data in a rich way.  For example a Swing rich client knows it has a JTable, it has a TableModel full of data, and it has some nice interactions it can offer the user depending on how the JTable is configured.  Similarly the OS3Grid thingy has a data model and can offer some nice interactions.

But with the current incarnation this OS3Grid thingy is less capable than the Swing JTable.

The question, I suppose, is whether JTable's extra capability makes a difference.  A developer wanting to display a fancy table that has a good user experience, could write a simple APPLET and use the JTable.  But is the extra capability in JTable important to the end user?  Or is the OS3Grid thingy good enough?  And can it improve over time to take on more and more capabilities?  How close can it get to JTable?



(2005-04-25 09:01:06.0) Permalink Comments [0]