excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject The Excalibur Event Package
Date Mon, 14 Jun 2004 15:02:37 GMT
OK, as some of you may know by now, I have forked the Excalibur Event
package over to D-Haven.org so that I could be free to refactor it and
greatly improve the test suite.  In the process I have changed the
package (org.d_haven.event instead of the org.apache.Excalibur.event.**)
and simplified things a bit.  My version requires Java 1.4 or better
mainly to do away with the hack that I was forced to do for pre-1.4 JVMs
to determine the number of processors.  Since Java 1.4 introduced the
Runtime.getRuntime().getAvailableProcessors() method, I no longer need
that heavy hack.

The bottom line is that the event package in its purist form (just the
**.event and **.event.impl packages) does not have any JVM affinity,
and does not need it.  The MPool part of the package also does not need
it.  It was needed for one of the **.event.command package thread
managers.

I am in the process of improving the command package as I employ TDD
to refactor and finish it out to something much simpler to understand
and maintain.  Once I am done with that, I would be ready to release
it.

Now, the thing is that I have found that we can safely remove some of
the classes from the Event package, as well as provide a better test
suite (I think the previous one is non-existent).  Also there is a
simpler dependency structure.  My forked version only requires Doug
Lea's concurrency utilities.

The big question now is do we want to re-adopt the work that I have
done on the Event package into Excalibur proper as an Event 2.0 work?
There were some things I had to do in order to avoid future namespace
collisions with Java 1.5 such as changing the class name Queue to Pipe.
(Apparently there is a new java.util.Queue interface that conflicts
and Clover adds an import java.util.* to your source code when it is
instrumented).

I can continue to maintain the Event package over at D-Haven, and it
is arguably better in the sense that we can *prove* it works through
the test suite.  Or, I can bring the work back to Excalibur in an
appropriate place so that we can start to adopt it for Fortress, thus
improving Fortress' reliability as well.

The main drawback at this time is the fact that we loose pre-Java 1.4
compatibility with the Command package.  Of course the Command package
is starting to look a bit different than before.  The ThreadManager
stuff is almost completely revamped.

Of course, we can also adopt things in stages.  The core event stuff
can be separated into its own library, and the Command stuff can be
separated out by itself.

What would everyone's take be on this?

-- 

"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the Universe trying to 
produce bigger and better idiots. So far, the Universe is winning."
                 - Rich Cook


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Mime
View raw message