Jason Briggs' review of KBrowser (Vol. 6, issue 11) was interesting
and useful. Thanks for highlighting it.
One area he didn't cover was KBrowser's performance. I'd like
to know his impression of how it performed, not only for WAP content
but also for simple HTML content as well. I'm also interested in how
he thinks KBrowser will perform on J2ME-enabled wireless handsets,
now and in the future.
I didn't include performance, because I don't have a real
phone to run it on, unfortunately. Up until the last month or so
there haven't been any MIDP-capable phones in the UK except for
Nokia's PDA phone combination (which has a 55MHz processor and runs
PersonalJava out of the box - not really a useful benchmarking system
in this case).
Motorola has just released an MIDP phone here, but I've yet
to get my hands on it.
Performance on my laptop, however, was fine, but not really
an indicator of how it will actually run on a phone - your guess is
as good as mine. However, gut feeling (from running MIDP apps on a
Palm and on the aforementioned Nokia) says unless they're doing
something exceptionally illogical, not that likely I think, then
performance will be good enough so it will all finally depend on the
I couldn't run it on HTML content, because the evaluation
edition they sent me was WAP only.
Is New Technology
I agree with Alan Williamson's comments in his editorial, "Web Services & XML" (Vol. 6,
issue 11). For Web services, the battle is not defining how to create
and/or access Web services, which is where we're currently at. The
difficulty is in changing Web usage. Folks are just getting
comfortable with URLs, and while they benefit from not depending on a
provider for a service, it also gives them some stability. I think it
makes sense when architecting or building new services (which don't
have issues with stability or familiarity), but users are another
As far as XML usage, it seems that we tend to throw a new
technology at everything, mostly because we've learned something new
and want to make it useful. But it can degrade and impede a system's
Perhaps Web services will become more important if, as I
predict, more robust user interfaces are doing the interacting with
them, rather than users in a Web browser.
Enough Is Enough!
When are Bill Baloglu and Bill Palmieri (Career Opportunities column)
going to seek help for the bottled-up anger they have toward anyone
under the age of 50! Every article they write is essentially about
how dumb the rest of us are (the under-50 crowd) and how smart they
Why do they feel the need to write article after article
about how apparently no one is qualified to call themselves a Java
engineer unless they have 20 years of experience? I personally don't
consider myself a Java engineer, but I have worked with a few that I
would consider that level and none of them were older than 30. I've
also worked with developers with 15-20 years' experience who I could
code around the day I stepped out of college.
Am I saying that all employees over the age of 50 are over
their heads in the technology field? Absolutely not. But please admit
that there are some people in their thirties and even their twenties
who are intelligent and experienced and could do the job! If a person
can do the job, then he or she will get the assignment.
After a thorough search of all our articles, I couldn't find
a single reference to age.
Our January article (Vol. 6, issue 1) dealt with the "know"
engineer and the "understand" engineer - no mention of age there.
Our February article (Vol. 6, issue 2) talked about the B2B
marketplace - no mention of age there.
March (Vol. 6, issue 3) talked about money levels for senior,
mid-level, and junior engineers - no mention of age there.
May (Vol. 6, issue 5) discussed how to write an effective
résumé - no mention of age there.
I think you get the picture.
There is a reason why we use the term senior. It has to do
with the length of time of actual work experience as well as the
technological expertise an engineer brings to his or her job. The
senior engineers we work with are not over 50, or any specific age.
However, they do possess the skills and years of experience we talk
Until then, we wish you the best and keep sending us your e-mails.
I just read Charles Arehart's excellent article "The Many Sides of
J2EE Development" (Vol. 6, issue 11). I've learned a lot from this
article and his previous one, "Making the Move to J2EE" (Vol. 6,
issue 9). Mr. Arehart presents important issues in an excellent
manner. I'm beginning to see that servlets are a more important part
of the J2EE spec than I had previously imagined.
Don't Use Expensive EJBs!
It's was such a joy to read "J2EE Without EJBs?" by Vince Bonfanti
(Vol. 6, issue 11).
Many people believe that J2EE has to be implemented using
EJBs. Some clients spend millions just to have a J2EE application.
It's great to have Vince Bonfanti clear the confusion and wake up
companies so they can save millions on a J2EE application by simply
using Java, servlets, JSPs, and JDBC instead of expensive EJBs!
Leo F. Smith