Skip to main content

Anyway, Anyhow, Anywhere

Posted by editor on July 5, 2006 at 7:35 AM PDT


Compatibility when convenient?

Despite Java's mission to knock down unneccessary borders, doesn't the official effort seem a little unambitious sometimes?

Case in point: the Java Bug Parade. Right now, I've got USB on the brain because I'm editing an upcoming article on the topic (it may appear tomorrow - it depends how the morning goes). I decided to go refresh my bug/RFE votes for the first time in a few years and cast them for getting a real JSR-80 implementation added to the JRE spec.

Thing is, an RFE like this is something the bug parade is remarkably ill-suited to handle. First, after getting lectured for a page or two that the bug reporting system is not a support tool (no duh), you can start filing an RFE or bug report. Problem is, it makes you pick a category/subcategory combination that puts you in a fairly small box. For example, if you choose "JDK/JRE" as your category, all the subcategories are existing JRE technologies, ill-suited to adding a new one. One wonders how you would file a JRE like "please include Java DB with JDK", but I digress. The focus on existing technologies may bias the RFE's away from valuable new capabilities and steer users into refining existing libraries, which might explain why the top RFE is to implement Ogg codecs for JMF, which would have the pracical effect of taking JMF's collection of outdated, little-used codecs and adding a modern, little-used codec (deal with it, Slashdot types, you know the iPod/DVD/PlayStation mass market doesn't know or care what Ogg is). And that's setting aside the issue of whether JMF is even alive at this point. But I'm off-topic. My goal is really to show how the bug reporting tool biases the kinds of reports that get filed. Add to this that you can't even file a bug or RFE unless you're on Windows, Linux, or Solaris, or at least claim to be, even if your issue has to do with documentation or API design. java.io.File has sucked for 10 years, regardless of what platform you're on -- why shouldn't I, as a Mac user, be able to tell Sun as much?

I have a phone that runs Java ME. I would like to write apps for this phone. Sun curiously decided to put native dependencies in the ME dev kit (why?!) and then not do a Mac version, but that's OK, I can use MPower Player. No, the killer is that I can't get the midlet over the cable from my Mac to my phone, because Motorola's dev tools are Windows only too.

Surely, this irony is not getting lost on the audience here... to work with a language and a VM whose raison d'être is device independence, I have to use native tools that are not available for my platform. What is the developer supposed to think of Java's viability when even Sun won't use it for simple tasks like data transfer or ME development (remember, SE's javac is written in Java, and surely simple handheld devices could be easily emulated in pure Java on modern desktops).

Part of the problem is the matrix of API's and platforms. Every time you add some new feature that requires native support, you multiply the amount of new code that must be written and maintained, and decrease the chances of it being ubiquitous or successful. The device transfer problem could be solved by moving JSR-80 to the core, but I'll have more on that when Jeff's USB article appears.


Special thanks to Daniel Steinberg for handling daily blog duties yesterday while I was traveling...


In Java Today,
the eighty-fifth issue of the Java Tools Community Newsletter features the new projects that joined the community, a tip on writing articles for java.net to draw attention to your project, and the latest graduation from the community incubator, NBPlayer, an MP3 player for NetBeans.

The NetBeans C/C++ Pack brings C/C++ support to the NetBeans Platform. C/C++ developers can now use the NetBeans IDE, in conjunction with their specified set of compilers and tools, to build native applications for supported platforms, including Microsoft Windows, Linux, and Solaris Operating Systems. A sophisticated language-aware editor, project templates, dynamic class browser, and makefile support are some of the features included to provide a complete edit-compile-debug integrated development environment.

Just seeing a sprawling code block from a distance gives some developers the willies -- and it should! Loquacious code is often the hallmark of complexity, which results in code that is hard to test and maintain. In Tame the Chatterbox, quality expert Andrew Glover starts out with tips for eyeballing code excess, then shows you how to use tools like PMD and JavaNCSS for more precision when you need it.


Jayson Falkner shows off Blarg #25: A JSP that shows Request Headers in today's Weblogs.
"This code as been shown many times before, including in my book. This is exactly what the title says: a JSP that will display the request headers sent by your browser. It is also a good example of how to use the JSP EL and the JSTL core tags to make an incredibly simple JSP.

Mobile Media author and expert Vikram Goyal checks in with the update
MMAPI 1.2 released:
"JCP has quietly released the 1.2 API specification for MMAPI (JSR 135). This is only a maintenance release and contains mainly documentation changes in the API."

Richard Bair shows off more networked Swing goodness by whippping up a
Simple Yahoo! News Reader:
"My last few blogs have been on using web services in Swing. This time I've created a simple Yahoo! News RSS reader JavaBean you can use in your own apps. And yes, this time I went all the way and wrote a JNLP."


In today's Forums,
i30817 seems to be doing something like a page layout ap in
Trying to make text in a jtextcomponent flow to another.
Hi. I've already subclassed stylededitorkit to return a viewfactory, that i'm using in conjunction with a observer and a custom paragraphview to know the length of painted text (and offsets). Now i'm wondering if someone knows a way for the text to flow from a component to another ie : where the text of one ends, get the other textcomponent to draw the text from there. I'd like this to be resistent to resize, and efficient. Since the two components are going to be always the same size, i think i might reuse the view tree of the first one. Any thoughts?

zambizzi talks about JBoss' incomplete Java EE 5 support in
Re: why are tags necessary in web.xml?
Yes, I was using JNDI lookups w/ JBoss because they don't yet support the @EJB annotation at all - they're still not up to spec. [...] I would *love* to use the @EJB annot. to get access to my beans but as I understand it - it's only really supported in Servlets right now, is that correct?


In today's java.net
News Headlines
:

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
:

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.

Compatibility when convenient?