Skip to main content

Following the thread

Posted by daniel on October 20, 2004 at 10:58 AM EDT

Resolving traffic in two directions

Graham Hamilton responds to a request in the java.net Mustang forum on multithreading in Swing with Multithreaded toolkits: A failed dream?". Among other things, Hamilton writes:

The problem of input event processing is that it tends to run in the opposite direction to most GUI activity. In general, GUI operations start at the top of a stack of library abstractions and go "down". I am operating on an abstract idea in my application that is expressed by some GUI objects, so I start off in my application and call into high-level GUI abstractions, that call into lower level GUI abstractions, that call into the ugly guts of the toolkit, and thence into the OS. In contrast, input events start of at the OS layer and are progressively dispatched "up" the abstraction layers, until they arrive in my application code.

He explains that "at some point you have to step back and observe that there is a fundamental conflict here between a thread wanting to go 'up' and other threads wanting to go 'down', and while you can fix individual point bugs, you can't fix the overall situation." Add your thoughts to the talkback for his blog entry.

Also in today's Weblogs Tom Ball suggests that annotations are The New Golden Hammer . He cautions "that folks are forgetting (or ignoring) the problem annotations are trying to address: that much of the specification for a class is done outside of its source code in other files, or is done in repetitive boilerplate code that has little to do with the class's problem domain. Information about a class is called metadata, and annotations allow developers to define metadata without external files (other than new annotation type declarations), special naming patterns or other error-prone hacks."

Craig Castelaz shows you how to Help maximize screen space with a small UI trick. He shows a drop down list that doesn't reveal itself until someone clicks on the field. The feedback is divided between insisting that the nature of the field should be revealed before it is clicked on and the feeling that it is clearly an input box and the nature of the input method need not be clear ahead of time.

In Also in Java Today , there are many instances where not spending money is not the same as saving money. Mike Clark explains how spending under $2000 can lead to saving much more money for teams that are practicing continuous integration in Dear Manager, They Need a Build Machine. He ends by urging you to "Consider that on average your ten-person development team costs, conservatively, $500 per hour. (It's probably more like $1000 per hour when you consider all the care and feeding expenses.) If your team spends a total of two hours over the life of the project debugging integration problems (start counting whenever you hear a developer cry "But it works on my machine!"), then you've already paid for a respectable build machine. Then when you consider that those debugging sessions are delaying your product going to market, you really can't afford not to have a dedicated build machine."

Scheduling tasks to occur at specific times or on specific intervals is a crucial element of many enterprise systems. J2SE has had a straightforward Timer since version 1.3, but it's taken until J2EE 1.4 to get an enterprise equivalent, one that offers transaction support and survives crashes. Debu Panda's Using Timers in J2EE Applications shows you how to get started with J2EE timer services and offers best practices for getting the most from them.

In Projects and Communities , the JELC community is now the GELC. The community homepage explains "we changed our name from Java to Global Education and Learning Community. The reason for this is better general acceptance and name recognition."

The Communications community highlights a JDJ article JAIN/SLEE Opening the telecommunications world for Java and says JAIN has "the potential to radically change the existing service architecture for communications service providers."

"A language change may be needed to implement general, simple, straightforward things that you have to write over and over again." In today's Forums, Paul Rivers continues "Like the enhanced-for loop. Or generics - you're always casting, over and over again. Also, a language change may make these general, simple, straightforward things simpler (which also makes your intention clear). My favorite pet peeve in java is that whole get/set thing. I wish you could just declare properties. (This may be basically the same as your "make your intention more clear" item)."

Afreije offers a "Syntactic sugar proposal: Type t = T.type instead of Class cls = str.getClassParameter("T"); Access to the runtime type of a type parameter will require that the type parameters are passed into the constructor/method with each invocation of a generic constructor/method.

Tim12s has a long list of suggestions partially summarizing suggestions that have appeared on the list already. "#1 - Language Enhancements - NON REQUEST - I would ignore language enhancements. While possible language enhancements are 'nice', they will make support for them in tools and IDEs more difficult/complex. Granted that there may be some language enhancements as worthwhile as generics and annotations but I'm sure that JDK5 is enough for now. AspectJ, multiple return statements, Destructors, whats the point. If it survives a JCP then great..."

In today's java.net News Headlines :

Registered users can submit news items for the java.net News Page using our news submission form. All submissions go through an editorial review before being posted to the site. You can also subscribe to thejava.net News RSS feed.

Current and upcoming Java Events :

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.

Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.

Resolving traffic in two directions
Blog Links >>