HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

KBrowser's Performance?
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.

Ron Stein
[email protected]

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 network speed. I couldn't run it on HTML content, because the evaluation edition they sent me was WAP only.

Jason Briggs
[email protected]

Is New Technology Always Good?
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 ball game.

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 internal communication.

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.

Vince Marco
[email protected]

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 are.

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.

Richard Dean
[email protected]

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 about.

Until then, we wish you the best and keep sending us your e-mails.

Billy Palmieri
[email protected]

Important Issues
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.

Frank Staheli

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
[email protected]

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.