Skip to main content

Following the thread

Posted by daniel on October 20, 2004 at 7:58 AM PDT

Resolving traffic in two directions

Graham Hamilton responds to a request in the java.net Mustang forum
on multithreading in Swing with href="http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html">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 href="http://weblogs.java.net/blog/tball/archive/2004/10/the_new_golden.html">
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 href="http://weblogs.java.net/blog/castelaz/archive/2004/10/ui_trick.html">
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 href="http://www.clarkware.com/cgi/blosxom/2004/10/19#TheyNeedABuildMachine">
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 href="http://www.onjava.com/pub/a/onjava/2004/10/13/j2ee-timers.html">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 href="http://community.java.net/edu-gelc/">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 href="http://community.java.net/communications/">Communications
community highlights a JDJ article href="http://sys-con.com/story/?storyid=46230&DE=1"> 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 href="http://forums.java.net/jive/thread.jspa?messageID=3187&tstart=0#3187">
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 " href="http://forums.java.net/jive/thread.jspa?messageID=3197&tstart=0#3197">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 href="http://forums.java.net/jive/thread.jspa?messageID=3325&tstart=0#3325">
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
:

  • Cluster31JES
  • href="http://today.java.net/pub/n/ObjectWebCon05Registration">ObjectWebCon
    '05 Registation Open
  • href="http://today.java.net/pub/n/JavaRSScomFaster">JavaRSS.com 15x
    faster
  • Is
    the software license dead?

Registered users can submit news items for the href="http://today.java.net/today/news/">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
the href="http://today.java.net/pub/q/news_rss?x-ver=1.0">java.net
News RSS feed.


Current and upcoming
Java Events
:

  • October 19-22, 2004 href="http://www.educause.edu/conference/annual/2004/"> Educause
    2004

Registered users can submit event listings for the href="http://www.java.net/events">java.net Events Page using our href="http://today.java.net/cs/user/create/e"> 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 href="http://today.java.net/today/archive/">java.net Archive.

Resolving traffic in two directions