You Better Get It
Can you code without your favorite tools?
Kathy Sierra has a set of scenarios that might strike you as familiar:
It's lunchtime at the cafe and you give the cashier a $20 bill for an $8 purchase. She gives you $32.78 in change. You mention the mistake. She says, "But that's what the cash register says I owe you." She can't cope with the cognitive dissonance between reality and What The Machine Said. Later that day you get a frantic call from a co-worker--a recent addition to the programming team. "I keep getting this error message that it can't find the classes I'm using!" You ask, "By 'it' do you mean the compiler?" He answers "I don't know. I'm using an IDE." That night, you're helping your 12-year old son with his math homework when you realize--in horror--that while he's quite good with the calculator, he couldn't multiply two three-digit numbers using only paper and pencil if his Wii depended on it. These tools were designed to make us more efficient, so that we can focus on something more important than the tedious task of, say, giving change, organizing source code, and doing calculations. But are they helpful timesavers, or are we dumbing ourselves--and our users--down?
Kathy makes a call for tranparency, for tools to not hide what they're doing but rather make it more manageable. An IDE, for example, could offer an "understanding mode", which would allow the user to ask the tool what it's doing and why. She also calls on teachers to make students do things "the old-fashioned way" before introducing complexity-hiding tools, such as making developers write their first few apps with simple text editors and compiling on the command line instead of using IDE's.
GreggÂ Sporar picks up this idea in relation to NetBeans in his blog Tools That Do Too Much?
I don't deny for a moment the idea that if you get hooked on just using a particular tool and ignore the fundamentals then you can eventually end up in dire straits. But there are several ways to avoid this problem - the first being one mentioned in that blog entry: start doing your learning without a tool. And in fact that is the technique used in Sun's Java courses - the IDE is only used in the labs. The classroom instruction is where the technology is taught. Properly used, a good IDE is a productivity tool, not a crutch.
He also makes the case that NetBeans has a high degree of transparency, for example, using Ant for its build system, offering tutorials not just on the tool but the technology, etc.
And what do you think? Do the popular IDE's make for less knowledgable developers? Does it matter as long as they're productive?
Also in today's Weblogs.
FelipeÂ Gaucho'sNetbeans sabotage asks
"Does your company use Netbeans as the default IDE? If you definitely dislike the idea of adopting Netbeans, or if you believe Eclipse closed the discussion about IDEs, you must read this."
Finally, JoshuaÂ Marinacci has a SwingX update on
Tricked out maps and a new tile provider:
"In previous blogs I introduced the JXMapViewer and JXMapKit, all part of the SwingX-WS project. We're still working on improving these classes and have more good stuff coming. I recently added support for non-rectangular maps, which makes the 1:2 Blue Marble map tile properly"
In Java Today,
Version 1.0.1 of SJSXP, the Sun Java Streaming XML Parser, has been released. This is the first release of GlassFish's underlying XML parser since April 2006. According to commentary by Santiago Pericas-Geertsen, a new buffering allocation strategy nearly doubles the throughput for small (2K or less) documents.
It's time again to elect a new NetBeans Governance Board. Submit your nominations for the community members you wish to be considered for the board before the deadline on Wednesday, March 7th. The polling period will begin on March 8 and continue for two weeks, with the new board announced to the community on March 22.
Bill Venners, Artima's founder and president, was interviewed by Ted Neward at the 2006 JavaPolis conference. The video of the interview was recently made available online. In the interview, Venners focuses on a range of topics related to Java's evolution, including the question of how to evolve the language without adding more clutter to it.
In today's Forums,
Phil Race offers a heads-up on the potential removal of classes you shouldn't be using anyways, in
[JAI-IMAGEIO] Retiring the package com.sun.image.codec.jpeg:
"The package com.sun.image.codec.jpeg was added in JDK 1.2 (Dec 1998) as a non-standard way of controlling the loading and saving of JPEG format image files. It has never been part of the platform specification and is not part of any compatibility test suite and so compatible Java implementations are not required to include it. The documentation for it has always been buried under a separate 'other API' heading, clearly distinct from the Java platform API specification. The intention was to replace it with a standard API. [...] However we are aware that applications do still use it, typically because they were written to run on JDK versions prior to 1.4. There are several options, not all exclusive ..."
mthorntonhas a question about
Graphics cards and Performance:
"What level of graphics card is being targetted for Java2D acceleration improvements? E.g. if I buy a new Dell Optiplex, for many models the default graphics card is an ATI Radeon 1300 Pro 256MB. Will this miss out on some of the improvements in JRE6 or expected in JRE7? My interest is two fold: (a) what my clients experience is likely to be, and (b) what I should get for my next development machine."
Finally, Ken Warner has a feature request for doing
Sub pixel sampling of Raster or DataBuffer in BufferedImage.
"I'm writing an applet to show slightly distorted images. The applet it to apply small corrective mapping to straighten out the image for better viewing. The problem is that the corrections on a small image can be less than a pixel. It would be real handy if I could do sub-pixel averaging to interpolate an average pixel in between the four nearest neighbors. Pretty typical bi-linear interpolation. I can do this when I draw the image using RenderHints. But I want to do it as I access the source image. I lose too much information doing the interpolation at render time. What would be insanely great is if I could do a getPixel() using doubles or floats as the pixel address -- like getPixel(4.321, 5.749)..."
Current and upcoming Java
- February 21-23 - 2007 Nonprofit Software Development Summit
- March 2-4 - Greater Wisconsin Software Symposium 2007
- March 6-9 - Java Posse Roundup 2007
- March 8-9 - Desktop Matters 2007
- March 9-11 - New England Software Symposium 2007: Spring Edition
- March 16-18 - Gateway Software Symposium 2007
- MarchÂ 21-23 - TheServerSide Java Symposium 2007
- MarchÂ 23-25 - Greater Nebraska Software Symposium 2007
- May 8-11 - JavaOne 2007
- June 24-28 - Jazoon'07
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
Archives and Subscriptions: This blog is delivered weekdays as
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.
Can you code without your favorite tools?