Archive for August, 2004

J15: an Eclipse plug-in to migrate to the JDK 1.5

I have been converting a lot of code to the new JDK 1.5 constructs recently
and I decided it was too tedious, so I wrote a quick Eclipse plug-in to assist
me.  It’s called J15 ("J One Five") and I am happy to announce its
first release.

Right now, J15 can convert for loops on arrays and collections but I have
quite a few other enhancements in mind which I will disclose as I implement
them.

In the meantime, please test it and let me know how it works for you, as I am
confident there are quite a few cases that I haven’t covered (manipulating a
Java Abstract Syntax Tree is fun but it produces very ugly code…).

By the way, you will need a recent Eclipse build to run it (since it needs to
support these new constructs).  I am currently running N20040806 which
passed all the Windows tests.

EJB 3 callbacks

We are currently trying to figure out how callbacks should be implemented
with EJB 3.  So far, we have identified five different techniques and I’d
like to get some feedback from readers about them.  Here is a quick
rundown, edited from messages sent by Marc Fleury and Craig Russell, along with
their respective pros and cons:

  1. Magic callbacks.  Method signature is the same as a container defined
    one. Eg public void ejbPassivate();
    +    Very lightweight, no template code, no base class, no interface
    dependency.
         Easily breakable (developers will mistype), doesn’t express container
    dependency.
     
  2. Interface. Current state in 2.x spec.
    +   Clear dependency expression, not breakable.
       
    Lot of template code (today’s code is cluttered with many lines of callback
    template code that does nothing).
     
  3. Base class. Provide template code in base class, have developers extend from
    it.
    +   No template code, not breakable.
        Single inheritance in java makes this base class a no-no.
     
  4. Annotations. Annotate any method as callback (as the example of "@remove"
    that Linda already showed)
    +
        No template code, not breakable (annotations can be supported in
    IDE/compile), any name.
        ?
     
  5. EntityManager callbacks as opposed to POJO callbacks. e.g.

    EntityManager.registerLifeCycleCallbackListener
      (LifeCycleListener listener,
    Class classOfInterest, long lifeCycleEventsOfInterest);

    +    No interference with POJO class.
    +    Exploits well-known event listener paradigm.
    +    Very lightweight, only called if specific class/life cycle event
    happens.
    +/-   "aspect oriented".
       
    Not object-oriented (code outside POJO affects POJO).
        How can we extend this to Session beans?

Can you think of other options?  Which one would you favor?

 

New TestNG, now with groups of groups!

I have just released TestNG 0.9.  Among the new features, the most
interesting one is "groups of groups".  I’ll quote the documentation
directly:

Groups can also include other groups.  For example, you might want to
define a group "all" that includes "checkintest" and "functest".  "functest"
itself will contain the groups "windows" and "linux" while "checkintest will
only contain "windows".  Here is how you would define this in your property
file:

testng.group.functest = windows linux
testng.group.checkintest = windows
testng.group.all = functest checkintest

testng.includedGroups = all

I have also added new Javadocs and more code excerpts to the documentation. 
For all the details, please refer to the
TestNG main page
.

Spam software review, part 1

I have tried several anti-spam clients for Outlook recently, here are a few
reviews.

I’ll start with SpamBayes,
the open-source Python add-in for Outlook.

First of all, I have to say I like the idea of an Outlook add-in written in
Python.  I am not a big fan of Python myself (here
is 
why), preferring
Groovy and Ruby, but this is a testament to the goodness of COM/.Net which gives
you a lot of flexibility on your language of choice.

My initial contact with SpamBayes was pretty good but unfortunately, the
honeymoon didn’t last long.  After a few weeks, I became annoyed by the
following shortcomings:

  • SpamBayes is slow.  I don’t know if it’s due to Python (or its
    executable compiler) or the code itself, but you can clearly see it
    processing a message.  While it’s usually not an issue for individual
    messages, you will feel your pain when you haven’t launched Outlook in
    several days and that SpamBayes suddenly finds itself in front of over one
    hundred messages to filter.
     
  • Even after a few weeks of training, a high number of emails (about
    twenty per day) still ended up in the "Junk suspects" folder while they are
    obviously spam that should have been detected by the Bayesian algorithm
    (meaning:  they are of reasonable size, in plain English text and
    contain quite a few keywords that should have made the filter take immediate
    notice).
     
  • But the number one reason that made me decide to give up is: 
    SpamBayes doesn’t have a white list.

First of all, I was quite put off by the attitude of the developers when I
asked for that feature.  The responses were typically along the lines "SpamBayes
doesn’t need a white list, it’s doing a great job already", "I’ve never needed
it" and "Why don’t you add the feature yourself?".

This is not the kind of response you get from commercial vendors typically,
but well, the software is free so there is not much I can do.

But the worst part of this shortage is that it shows that the Spambayes
authors don’t understand that a spam filter is simply useless without a white
list.

It took just a few days for me to realize that when I started exchanging
important emails with someone who tends to write very short, poorly-formatted
emails that the filter was absolutely incapable of training against. 
Despite all my efforts, this person’s emails regularly ended up in the "Junk
suspects" folder or, worse, in "Junk".

Another example a few days later: emails from a member of my family who are
tagged with several lines of self promotion / advertising at the bottom, which
the filter systematically interpreted as spam.

After a few weeks of use, I realized that I just didn’t trust my spam filter. 
I kept dreading that I would miss an important email and therefore, applied
extra caution when perusing my "Junk suspects" folder, which completely defeats
the purpose of such a tool.  Added to the fact that SpamBayes doesn’t offer
extra goodies such as statistics or challenge/response, it became clear to me it
was time to look for another option.

Next:  MailFrontier’s Matador (and after that, IHateSpam).

Are we winning the war against spam?

The latest spam that made it to my Inbox looks like this:

sielkundiges
xhdgkcuh`ezapatascratcht

u,_s^.a ph,a.-rm & next-d.~ay sh-‘ipp^’ing

nagstoel
etaicurcinch-pounds http://…

In order to get past my antispam software, the spammers now need to disfigure
their message to the point where it’s barely legible.  When I see this, I
start thinking that maybe we are slowly beginning to win this war…

Now if only we could find a way for these spams not to be sent in the first
place…