You Become What You Disrupt
SpringSource Launches New Application Server without Java EE.
It looks like the Spring guys want to get into the proprietary Java App Server business, exactly what they tried so hard to discredit a mere four years ago.
SWT Detractors, Rejoice...
... for it doesn't work with the newly updated Java SE 6 On The Mac:
Chris Adamson: I think you have that backwards. Apple's JVM has been Cocoa-based for a while now (since 1.4). SWT is Carbon-based. And even that wasn't a deal-breaker before. The real problem seems to be that:
- The new JVM is 64-bit Intel-only
- You can't mix 64-bit and 32-bit code in an OSX process
- Carbon is 32-bit only and apparently will remain that way
- SWT is Carbon-based
For what it's worth, QuickTime for Java won't work on the Mac's Java 6 for exactly the same reason. Carbon is de facto (but not de jure) deprecated, and therefore any Java libraries that use Carbon are in big trouble.
Jess Holle:
Nigel wrote:
> wow, the thread http://www.eclipsezone.com/eclipse/forums/t97750.html
> has been locked down because they didn't like people telling them that
> SWT was a bad idea....For most use cases and development, SWT seems to be one of those ideas whose time has come and gone...
I'm sure porting SWT from 32-bit Carbon to 64-bit Cocoa is something that is doable but will require some time and effort. The question is: "Is it being done?"
It seems it's time for Eclipse users to be patient, as Swing users were patient in the last ten years.
What Test Driven Won't Get Me
Thanks to Eric and Brian and other champions of test first development, I've been profitably writing unit tests and functional tests in various projects for more than seven years.
Nowadays I wouldn't dare delivering anything without having thoroughly tested it. For me, the tests serves three purposes:
- To ensure that the functionalities are implemented correctly
- To discover corner cases that you just couldn't think of during on-paper design
- To provide a safety net that is needed to confidently refactor the code base to improve design
However, my own experience with the concept of test driven design has been mixed. And here are some of the limitations of the approach, as I see it:
- Your test driven design won't be that much better than your non-test driven design. If you know nothing about designing a compiler, no amount of testing will make you come up with a design for a compiler
- Your tests will drive you to designs that are more complicated than necessary, with an abundance of entities and interactions. You will be doing a lot of "create class", "create method", "create field" from the IDEs refactor menu, but rarely do "consolidate classes" or "consolidate methods" because no such refactoring exists
- Your test driven design may drive you towards a design that's less amendable for future changes. Without forethought, you may be too focused on delivering functionality that satisfy only the current requirements, thinking "I can always refactor later to accommodate future requirements"
In other words, if you don't know how to design, no amount of testing will make you a good designer.
In other news, Donald Knuth professes that "With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me."
Finding Your Lost Youth Through XQuery
This is going to be a weirdly convoluted post. But you can skip all the details and go directly to the money link: http://markmail.org/. Here's a screenshot:
Now, my story.
A long time (1575 days) ago, I wrote an article about XQuery for the JNB. I joined the xquery-talk mailing list that was started by Jason Hunter and others a few months earlier to solicit (and received) feedback from the experts. I kept myself subscribed to the mailing list. And yesterday, I replied to a post by Daniela Florescu about XQuery and Web 2.0:
Daniela Florescu: I just came back from Web 2.0 Expo in SF. I listened through lots of interesting presentations of various technologies for building mashups.
Needless to say, *nobody* mentioned the name XQuery.
Why !?
with a message full of sarcasm:
Me: The Web 2.0 crowd loves gimmicks. And XQuery is the quintessential straight-faced academic + proprietary/big vendor specification.
Here's something to try:
1. The Web 2.0 crowd loves a catchy acronym. They have LAMP, where the P originally referred to PHP, but can be substituted by Python, Perl, etc. Why not rename XQuery PXQuery and claim a piece of the LAMP pie?
2. The Web 2.0 crowd loves open source. Everything they talk about is open source. Why not make all XQuery implementations open source, at least free as in free beer?
3. The Web 2.0 crowd loves a language that's deep and weird. Nobody likes prototype based objects, yet JavaScript wins the day. What does XQuery has that mystifies people? FLOWR expressions just doesn't cut it. Add something novel to XQuery, like Map-Reduce, or mandate tail call optimization. Better yet, add REST support. Ruby on Rails can add REST support, so can XQuery.
4. The Web 2.0 crowd loves everything Google/Amazon/Yahoo! does. Paul Graham wrote an online store with Lisp and made millions, and has been milking that fact ever since. Have him, or someone like him, write a CMS or something in XQuery, and then *sell it to Google* to make millions of dollors. And then say things like "Google used XQuery to write their CMS."
5. This one should be obvious: There is no way that the Web 2.0 crowd will love XQuery *1.0*. 1.0 is so 1990's. Call the next update XQuery 2.0!
Now, try these slogans out:
BOSTON, APRIL 1, 2009---The W3C released XQuery 2.0 today. This refresh of the venerable XQuery 1.0, three years in the making, brings major new functionality into the specification, chief among them the full support for REST, highly parallel and concurrent programming with Map-Reduce, and the spec mandated full tail-call optimization that will guarantee scalability and performance. Microsoft, IBM, Oracle, and fifteen XQuery engine vendors today also announced the Open Sourcing of their products. Tim O'Reilly, the father of the phrase "Web 2.0" welcomed the W3C's move today: "With this release, XQuery is fully Web 2.0 buzzword compliant."
This lead to a post from John D. Mitchell:
John D. Mitchell: [...]
> I think what your saying is that XQuery needs a killer app - and I agree with that.
I'm way biased but check out http://markmail.org/. Pure XQuery backend with the latest Ajax hotness for a UI.
That lead me to the MarkMail site mentioned above. MarkMail was covered by the O'Reilly Radar. It imports archives of mailing lists and offers a good UI for searching and browsing the contents of the mailing lists. What is rarely mentioned is the fact that its backend is pure XQuery.
In the screenshot, I searched for my posts to the ant mailing lists. The results are shown in a Flash chart on the top left corner. Here's a silent screencast (in Ogg Theora format, you might want to download the VLC Media Player) that shows how you can interact with it.
It's sooooo much better than all the other mailing list archives that I had no problem finding this thread from 2706 days ago, which showed how the ${ant.project.name} property was added to Ant in the span of 8 hours, starting with Mark Volkmann asking the question to the final commit of the patch.
That's how I spent my time back then. And thanks to MarkMail (and XQuery), I get to relive my youthful moments.
MarkMail is a killer-app of XQuery indeed!
Earthquake
An earthquake woke me up. The house shook for about ten to fifteen seconds. Light fixtures rattled.
KMOX is reporting an 5.4 earthquake at 4:36 CDT, centered 140 miles east of St. Louis.
[Update]: Aftershock felt around 10:15 CDT.
Try Out The Java Platform Detection Code
David Herron: Recently we made Java SE 6 update 10 available for beta testing. Beta testing is a period in product release cycles where testing is taken to people outside the product team, and those "external" testers bang on it with their applications and let the product team know what's wrong (or not).
I find the following snippet Java platform detection code interesting:
<script src="http://java.com/js/deployJava.js"></script>
<script language="JavaScript">function detectJRE() {
var list = deployJava.getJREs();
var result = "";
if (list.length == 0) {
alert ('No Detectable Java Platforms are Installed');
} else {
result = list[0];
for (var i=1; i < list.length; i++) {
result += ", " + list[i];
}
alert("You have the following Java Platform(s) installed: \n" + result);
}
}</script>
And you can try it out here:
Unfortunately, here's what I get on my home computer:
This is on a Debian GNU/Linux amd64 4.0 platform. We haven't had the Java plugin or Java Web Start for quite some time now. It looks like we'll get the plugin in early 2009, according to Bug ID: 4802695.
[Update] The comment by Anonymous made me curious. So I tried out the code on my Mac OS X 10.3 machine. Here are the results for Safari:
and for Firefox
The result from Safari is correct as the highest version of Java available for Panther is 1.4.2.
Just for completeness here are the results on the XP laptop, for IE7
for Firefox 3 Beta 5
and for Safari
Here, both IE7 and Firefox 3 Beta 5 detected the installed JREs accurately. The script did not detect any JREs from Safari even though my Safari "Installed Plug-ins" page showed both the "Java(TM) Platform SE 6 U10" and the "Apple Java Plug-In" as installed plugins.
Such is the wonderful world of JavaScript.
Why Do We Have Hype Cycles
Ted Neward calls out DSL and functional programming as being the hypes du-jour:
Interoperability Happens: Domain-specific languages are the new phrase of the moment, and its emotional context is being built as we speak. Functional languages will be there sometime next year or the year after. For both, the euphoria is growing, and for each, in some period of n (three, maybe four) years will be crashing just as hard as they were built up, just as Ruby's and Visual Basic's and COM's and EJB's and WS-*'s and other technologies have done before it. It's as predictable as the flow of alcohol at an MVP Summit, or the consumption of either caffeine at an all-night code frenzy.
Ted also points out that similar things happen in the health field in the form of new diets, but electrical engineering and construction are less vulnerable.
I think I know why? Take a look at a typical house construction project: a team of less than ten people working for less than six months can build a house that will in general last, satisfactorily for the occupants, for a hundred years.
Now take a look at software projects: the last time I worked on a five people/six months project was, umm, never. Even the fifty people/five year projects that was delivered are not expected to last for more than five years before a new version will be needed.
The effort/reward ratio is too low. And we, or the stake owners of our projects, are always on the look out for the next new thing that will make our life easier.
However, our mind is build in such a way that we feel the pain of the tools that we are currently using a lot more than the benefits of the tools. For example, we statically typed language users tend to remember that one instance when we wanted to do something but the type system just won't allow us to do. But we generally don't even think about what the type system does for us day in and day out during the ECTD (edit-compile-test-debug) cycle, or constantly inside of our IDEs.
And sometimes we gravitate to the shiny new thing that will make our pain go away, be they a new language, a new framework, or a new methodology. But so far, every new thing that I've tried also brings with it a new set of pains in other areas.
But for too many times, we end up being disappointed. And we become bitter and cling to our C++ and static types.
cd is from mars, ls is from venus
Enough people has posted their latest history meme results. It's time to draw some obvious conclusions:
- The top two spot in the listings usually belong to cd and ls
- The world is divided into two camps: The "cd" camp includes those who has more "cd"s than "ls"s in their history; and the "ls" camp
- I'm in the "ls" camp. The camp of over cautious developers who always issue a "ls" command after "cd"-ing into a different directory
Which camp are you in?
How can you "cd" camp people explain yourselves? :)
Breaking Version Inertia: Ant: import and macrodef
I've been using Ant since the very early days. ("Tomcat is built with Ant. What is Ant?" Remember those days?) Since my use of ant does not usually involve anything esoteric, I have fallen victim to version inertia. Ant 1.4, 1.5, 1.6, 1.7 came out over the years, and I didn't much glance at the release notes.
Meanwhile, some of my build.xml files has grown organically. Since the code is modularized with a nice "B depends on A, C depends on B, etc..." structure, the build.xml reflects that with targets like "compile-A", "compile-A-test", "run-A-test", "compile-B", "compile-B-test", "run-B-test", ..., each with their own classpath definition.
And as we added modules, we copy and pasted big chunks of Ant code, bloating the build file.
This become unbearable recently. And I looked for ways to make the build file manageable again. That's when I found the two new features of Ant: import and macrodef. Both are available in the latest Ant 1.7.0 release.
I won't bore you with the details of how these two tasks work. But it did allow me to break my build file into a
template-build.xmlwhich contains a set of macro definitions, and a bunch of
A-build.xml B-build.xml ...files each importing template-build.xml and instantiate the set of targets for a module. The build.xml then imports all the A-build.xml, ... files and use all the targets in a systematical way.
If you are using Ant, import and macrodef are your friends, just like if you are using C, #import and #define are your friends.
[DISCUSS] Open appropriate GUI from terminal?
This may be something that a casual GNOME user doesn't know.
A Sluug-discuss Thread (login is discuss/freely): On 06:56 Mon 14 Apr, Weiqi Gao wrote:
> Nathan Neff wrote:
> > I'm running GNOME/Ubuntu.
> >
> > Let's say I'm in a terminal, and want to open a PDF document, but don't
> > know the name of the PDF reading program.
> >
> > I can run "nautilus ." (don't forget the dot) and nautilus will start,
> > pointing at the current working directory in the terminal. You can then
> > just double-click the file you want to open.
> >
> > However, I'd like to avoid jumping to nautilus.
> >
> > Is there a command that I can issue that will find the type of the file,
> > and open it using the appropriate program?
> >
> > In Windows, you can use the 'start' command, and I think in OSX you can
> > use the 'open' command.
>
> In GNOME, you can use the 'gnome-open' command from the command line.
> It does the same thing that Nautilus does when you double click the file.
Cool! Is there an equivalent command for KDE?
-Jeff
I'd appreciate it if you can let me know what the corresponding command in KDE is.
(As I mentioned 609 days ago, in Cygwin the command is cygstart.)
What's In Your History
Warning: internet meme
yclog: Learned from KageSenshi that, there is a meme happening at the Fedora Planet, that is to execute this command:history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
WARNING: COPYING/PASTING AND EXECUTING A COMMAND LINE FROM THE INTERNET MAY BE HAZARDOUS TO YOUR HEALTH AND CAREER.
With that said, here goes my result:
[weiqi@gao] $ history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
132 ls
113 cd
23 vi
22 stty
14 pwd
13 ssh
11 less
11 java
10 ant
9 svn
(And you all know why I ran stty 22 times in the past 1000 command lines.)
Question: Concurrent Programming On Dual-Core Machines
I just have a simple question for all you dual-core machine owners: Has owning and developing on a dual-core machine helped with your concurrent programming?
Let me be specific: What would you miss the most, as a programmer who has to deal with concurrent programming issues, if, through some magic, I took away one of your cores and double the speed of your remaining core?
I know the theoretical answer to the question. But since I don't have a dual-core machine yet, I don't know how everything translates in practice.
Your jirb, groovysh and clj Commands Doesn't Work In Cygwin
This is another one of those making things work in Cygwin posts. You can safely skip this post if you are not married to Cygwin, or have not followed my Ten Steps To Higher Cygwin Productivity.
The issue this time is with a little library called JLine, which is a BSD licensed library that brings GNU readline style command line editing to Java. I first learned about it through the Clojure programming language (a LISP with immutable variables and software transactional memory (STM)).
And of course, it doesn't work in my Cygwin xterm window. A little Googling landed me at JLine issue-1822900. A little looking around in the JLine source and some experiments later, I had a partial workaround, which I added as a comment to the issue.
While doing the Google search, I also noticed that both Groovy and JRuby use JLine to some extend (in jirb and groovysh). Sure enough, the same issue showed up in the Groovy JIRA as GROOVY-2584, to which I added the workaround.
A fresh download of the just released JRuby 1.1 showed the same symptom. The JLine workaround can be applied directly to the jruby script, which, thankfully, does contain infrastructure for Cygwin support.
There are other issues with JLine on a Cygwin xterm. But the workaround at least makes the repls workable.
The part that makes me uncomfortable is that I don't see how this workaround can be incorporated into a patch for JLine. In that regard, I concede Cygwin is a somewhat hacky platform. (Jonathan and Adam, if you are still reading...)
Your Java Is Being End-Of-Life'd
cas: Hey, Weiqi, You see this yet? ...Java 5...End of Life...
Me: Do you have a link?
cas: http://java.sun.com/javase/downloads/index_jdk5.jsp.
Me: I downloaded the latest Java 5 and Java 4 on April 3, 2008. And I didn't see the pink warnings boxes. This must be some Sun evil scheme to get everybody transitioned to Java 6.
If you are on Sun Java 1.3, 1.4, or 5, you need to read the EOSL statements on the Sun Java download pages.
Sun: Java SE 5.0 is in its Java Technology End of Life (EOL) transition period. The EOL transition period began April 8th, 2007 and will complete October 8th, 2009, when Java SE 5.0 will have reached its End of Service Life (EOSL). Customers interested in learning more about Sun's Java Technology Support and EOL policy »Read MoreCustomers interested in continuing to receive critical fixes, are encouraged to consider the following options:
During this EOL transition period, the products will continue to be supported per existing customer support agreements.
For developer needs, all products that have completed the EOL transition period will be moved to the Archive area.
Friday C Quiz: Know Your Closures
You know what? This closure thing has gotten into my head. I know it's pointless and useless to think and talk about it all the time, but I can't help it.
Well, my loss is your gain. And today's Friday quiz will take you all the way back to C. Yes, old trusty C! Although ANSI C does not support closures, some C compilers provide nested function extensions that provide a limited subset of closure functionalities such as accessing variables in the outer function.
Q: Will the following C program compile and run under your C compiler? If so, what will it print?
#include <stdio.h>
int main() {
int (*pFib)(int);
int fib(int n) {
return n == 0 ? 0 :
n == 1 ? 1 :
pFib(n - 1) + pFib(n - 2);
}
pFib = fib;
printf("%d\n", pFib(6));
return 0;
}
J...J...JJava
Is there a way out of the Java jail? You bet!
CodeToJoy: An open-source project surprised industry insiders today by announcing an implementation of the Java programming language on the JVM.
The language, dubbed jJava, reflects the current trend for using the JVM as a systems platform for various languages.
Bruce Eckel: Would it make sense to create a "Java 3K" (playing off of Python 3000, the name given by Guido Van Rossum to the once far-off, backwards-incompatible, fixed-up version of Python which is now going to appear sometime later this year)? A new version of Java that still runs on the JVM and has syntactic similarity with old Java, but is not hobbled with any kind of backward compatibility issues, so it can have real generics, closures, get rid of primitives, etc. If a company didn't want to move to Java 3K -- the same company that probably hasn't upgraded to Java 5 -- then it continues working with what it already has. But programmers who are being held back by the old issues and old bad decisions made in old Java can easily move forward into Java 3K, with only a small learning curve and virtually no productivity shortfall.
Java.com: This page won't be displayed properly without the Adobe Flex 3.0 plugin, would you like to install Adobe Flex 3.0?