JSR #277: Stanley Ho explains versioning... Sounds like a bad idea to me...
Helpful pointers to many resources: BlueJ, NetBeans IDE Blue J Edition, Greenfoot.
You'd think this sort of problem would be resolved by now, but it's not. It's still almost impossible to quickly and easily migrate an application from the too common default Latin-1 to UTF-8 character set encoding.
Iterative Development is by far the best way to implement your Managed Business Process... unless your definition of "Iterative Development" is different from mine ;-)
Post article reports on the elimination of underenrolled Advanced
Placement (AP) courses in American high schools. The subjects affected are:
Italian, Latin Literature, French Literature and, hold on to your hats,
Computer Science AB. This blog tells you what that all means and why it is deplorable.
In his Disturbing Thoughts from a Developing Mind blog, fellow kiwi Mark Derricutt discusses a situation where new for loops don't provide enough power for a particular case. (And yes this blog has been sitting drafted but unpublished for ages :( )
The case in point is building a String from the concatenation of a List of Strings with some separator between them, in this case a semi-colon...
I am enthusiastic about Beans Binding, but a coworker threw a wet towel on me.
It is with pleasure that I announce the availability of a prototype for "No Closures".
I appreciate the effort put forth in both the BGGA and FCM proposals to add closures to the Java language but I have a concern regarding the apparent disregard for a syntax that is within the spirit of the language.
I want to refute the FUD that function types are nameless and have no javadoc.
Big applications have a tendency to accumulate enormous
classpaths. Looking at such a classpath, you might be hard put to
know whether any given jar is really needed. Perhaps it was
needed at the time it was added, but that need has long since
evaporated. How can you tell? Kyrill Alyoshin has an elegant
In this tip I want to share a small program to read office files (Microsoft and OpenOffice) such as .doc, xls, .sxw, .odt, etc, with OpenOffice Java API. In particular this program reads its properties.
Do programming languages have a shelf life, beyond which they cannot survive? Does adding complexity to a language shorten its life? When is it time to stop evolving, and start re-designing?
Swash already had part of its code split to a seperate project, one with a pretty infamous name: preciseInternalDate.
Swash will see an other split: splines!
A good thing at the moment... but is it really?
Beware casual use of JScience.org if your model is to become persistent. You might be walking into a snake pit.
"A procedure always operates in the environment in which it was created." Check out how you can mimic the (lambda) functionality of LISP with Java using anonymous inner classes.
Trying to bring together a disordered array of thoughts on the subject of evolving Java as a language.
That didn't take too long. Neal Gafter has posted the first closures puzzler.
When interviewing candidates (only 3-4 interviews) I would ask them the following question:
What kind of programming work do you like best?
They always gave then same basic answer: Creating new software.
Since that isn't the answer that I would give I asked my co-workers and between 4 of us we had 3 different answers: Creating something new, Debugging problems, and Improving (adding features, improving performance, etc).
Would you give one of those answers? Do you have a different answer?