Sun's attempt to create a community – java.net – includes
some weblogs.

I'm a little cynical about how useful this site will end up. Most Sun-run website seem to
end up with millions of questions like “I must create an Enterprise Java Website. Should I
use Strings or StringBuffers” (okay, I made that up) or more seriously, things like
this question picked on entirly at random:

hi,

I have faced folloing error while trying to deploy in deployment tool.. I got without failed message in verifier. plz help me,why this problem caused..

Even giving him credit for including the stack trace, it's the kind of thing that a (very) quick
search on google finds the solution to (look here for the solution, btw)

Am I being too harsh? Maybe creating a community from the top down will work – GotDotNet
is fairly successful.

(Re-reading this, it seems very badly reasoned – the java forums suck, therefore this new site
will suck isn't a logical argument at all. None the less I do have doubts about how succesful
Sun can make it.)

If you are using Mozilla/Opera/Safari/Konqueror and you like what you see (move your mouse over this text, dummy!),
I stole the idea from http://www.uoguelph.ca/~stuartr/articles/missinglink.shtml.

The rest of you IE users (which I am most of the time) will have to miss out…

If you have ever run into problems with proxies requiring NTLM authentication and a lack
of application support, you may be interested in the
NTLM Authorization Proxy Server – a python proxy
that proxies your apps requests to the NTLM proxy. I haven't tried it, but there have been
times in the past I wish I knew about it…

Werner Vogels has
a very interesting comparison of the performance of the IBM
1.3 Java VM and some .NET VMs (Java IBM 1.3.1, .NET CLR 1.1, Mono 0.23 &
SSCLI 1.0 to be precise) for some micro-benchmarks. It seems to validate the
conclusions in a comparison some months back (I can't remember where I read it, unfortunately).

If you want the 2 second executive summary: .NET 1.1 & IBM JVM 1.3 are
roughly comparable, Mono slower (but improving rapidly) and SSCLI trailing
in all benchmarks.

I'm not a numeric computing expert, but the gaps between any of them
don't look too significant in the floating point tests. The integer arithmetic
tests, seem to have Java & .NET 1.1 way ahead of the other two.

He doesn't say why the Sun 1.4 VMs weren't used. The evidence I've seen
around the place seems to indicate that the 1.3 IBM VM is as fast or faster
than the Sun VMs for numerical calculations anyway.

I would like to see a similar test run on the Sun 1.4.2 Server VM
(which has support for the SSE instruction
set on IA32 platforms) as well as some other low level performance optimizations.

BTW, one of the performance enhancements that I hadn't noticed in the 1.4.2 VM is
Faster NullPointerException handling.
That could easily double the performance of some of my apps!

For Classifier4J I use regular expressions. In the past I've used the Apache Regexp and ORO libraries, and been happy with them. However, for a first cut of the Classifier4J code I've used the JDK1.4 regular expression functionality and I quite like it. I wonder if using 1.4 only APIs is acceptable yet?

At work we are about to migrate to 1.4.1 (or 1.4.2) for development (we already deploy on 1.4 VMs), and with 1.5 to be released next year I wonder how much backwards compatibiliy is required?

Ever heard the phrase Release Early, Release Often? Have you ever
considered that the most important word in that sentence (from a Bayesian
point of view as well as my own ;-)) is Release?

As noted in by Morgan
Delagrange, Maven makes it very easy to add dependencies to weird
versions of other projects.

In particular, I see an increasing number of open source Java projects
that rely on CVS version (i.e. unreleased) of the code from other
projects.

I think it is really important not to do this. Ignoring the fact that
unreleased code is – well – unreleased – it also dramatically increases
the likely hood of dependency conflicts.

Unfortunately a lot of the jars in the Maven repository do not follow this
practice, and there does not seem to be significant social pressure to stop
people uploading and using random jar versions. For example at the time of
writing Maven itself has 24 dependencies – 6 of which are obviously CVS
builds. A further 8 are marked “dev” or “beta” which probably means they are
actual releases, so I don't necessarily have an issue with those ones (See
http://maven.apache.org/dep
endencies.html).

Perhaps a contributing factor to this problem is the fact that some
projects make very infrequent public releases. That makes it difficult for
other projects to pick up critical bug fixes or new features without using a
CVS version. I've seen projects that had an active development community,
had plenty of other projects using their libraries and yet didn't release a
new version of their library for over a year. I'm pretty sure I saw a tool
that measured how much code had changed between a local copy of some code
and a CVS label – something that is useful to keep an eye on for each of
your dependencies.

See http://jakarta.apac
he.org/commons/versioning.html for a decent guide to how versioning
should be done.

I guess I shouldn't be too critical of Maven. Build management is a topic
which is very easy to have an opinion about, but incredibly hard to
actually do right. To the best of my knowledge Maven is the most successful
and most widely deployed build management tool around, and I think it is a
very impressive piece of work.

After quite a bit of interest (which surprised me, but is flattering), a
pre-0.1 version of Classifier4J is available.

This includes the source and demo training and analyzing programs. No sample data is supplied, nor is any usage
documentation at all. However, reasonably good JavaDoc is available.

The IClassifier interface and
BayesianClassifier class
are probably of the most interest.

As noted on the website, this is a pre release. Don't expect it to be very useful if you aren't a programmer!

I'm interested in all feedback – contact me on the mailing list, or via nick at nicklothian dot com

Reading Mike comments on companies being responsive because of competing with
Open Source prompted me to send a few links into the blogsphere. Now I don't run a company
or anything, so this is theory only, but hey – it's the Internet – everyone's an expert.

Joel (of Joel on Software fame) wrote an
interesting piece a while ago called
Fire And Motion:

When I was an Israeli paratrooper a general stopped by to give us a
little speech about strategy. In infantry battles, he told us, there is only
one strategy: Fire and Motion. You move towards the enemy while firing your
weapon. The firing forces him to keep his head down so he can't fire at you.
(That's what the soldiers mean when they shout “cover me.” It means,
“fire at our enemy so he has to duck and can't fire at me while I run
across this street, here.” It works.) The motion allows you to conquer
territory and get closer to your enemy, where your shots are much more likely to
hit their target. If you're not moving, the enemy gets to decide what happens,
which is not a good thing. If you're not firing, the enemy will fire at you,
pinning you down.

If you haven't read it, you should.

I was alway impressed by the thinking in that article, and when I found Paul Graham's
Beating the Averages article, I though the
bit

Sometimes, in desperation, competitors would try to introduce features
that we didn't have. But with Lisp our development cycle was so fast that we could
sometimes duplicate a new feature within a day or two of a competitor
announcing it in a press release. By the time journalists covering the press
release got round to calling us, we would have the new feature too.

was another interesting datapoint in the whole agile-business strategy thing.

Very recently, I read an
article about John R. Boyd, who invented a concept called the OODA loop
(OODA stands for Observation, Orientation, Decision, Action). If you can execute the
correct action before your opponent then you are inside their OODA loop, and you win.

From the software point of view, this is instinctivly true. Remember the browser wars?
Microsoft got inside Netscape's OODA loop, and pushed new browser versions out too quickly for
Netscape to compete with.

I believe that open source projects can have very tight OODA loops, and it can be difficult
for a company to gets its loop tight enough to compete with them. However, if a company can
get its OODA loop smaller than a competing open source project, it can probably sustain it
longer – most open source project rely too much on volenteers to sustain a really tight OODA
loop for a long period of time.

If your company finds itself up against an open source competitor then I believe this is the key strategy in winning.
Just make sure the competition is not something like Linux, where the workers can actually
get paid – You won't be able
to compete in that market forever, unless you have very deep pockets
indeed. If it isn't a critical market for you, it might
be better to join them.