I've been using log4j and log4net as my logging facility for some time now, and haven't thought a lot about it.  I did today though...  I had a junit test with some mock objects that were getting used only if debug logging was enabled.  Do I know the developer running the test has debug logging enabled?  The answer is, the unit test shouldn't care, but how do I get around this in my unit test?

The real issue I was having was that in my class under test I was doing things like log.isDebugEnabled() to avoid a bunch of string concatentation in my logging.  Apparenlty there's a better way to avoid the string concatentation penality and also provides cleaner syntax IMO.

As of log4j version 1.3, there exists a significantly more convenient alternative based on message patterns. Assuming entry is an object, you can write:

l.debug("The new entry is {}.", entry);

After evaluting whether to log or not, and only if the decision is positive, will the logger instace format the message and replace the '{}' pair with the string value of entry. In other words, the paramerized form does not incur the cost of parameter construction in case the log statement is disabled.

Thus, the following two lines will yield the exact same output. However, the second form will perform at least 30 (thirty) times faster in case of a disabled logging statement.

l.debug("The new entry is "+entry+".");
l.debug("The new entry is {}.", entry);

A two argument variant is also availalble. For example, you can write:

l.debug("The new entry is {}. It replaces {}.", entry, oldEntry);

I finally found out there's a name to a design pattern I've used previously.  The open closed principle: a class should be open for extension, but closed for modification. 

A co-worker was working a fairly complex presenter class that was originally difficult to test, had way to many responsibilities, and would need to be modified each time a new area of the application was completed.  After extensive refactoring it now is testable and passes the open closed principle.  Basically the presenter class was broken down into 6 other classes which implemented a strategy pattern.  Much more maintainable and easier to understand!

A Hibernate session is a "unit of work."  Useful resource for understanding unit of work and transactions within Hibernate: http://www.hibernate.org/42.html

Checked exceptions in Java suck.  The more I use Java, the more respect I have for Anders Hejlsberg.

http://www-128.ibm.com/developerworks/java/library/j-jtp05254.html

"Bruce Eckel, author of Thinking in Java (see Resources), says that after years of using the Java language, he has come to the conclusion that checked exceptions were a mistake -- an experiment that should be declared a failure. Eckel advocates making all exceptions unchecked, and offers the class in Listing 2 as a means for turning checked exceptions into unchecked ones while preserving the ability to catch specific types of exceptions as they are propagated up the stack (see his article in the Resources section for an explanation of how it can be used)."

See comments...

/**
* Iterates through all mapped Hibernate classes and attempts to select
* all for that table/class pair. If this test does not fail then this
* indicates that the hibernate mappings at the very minimum match the
* database schema.
*/
@Test
public void allHibernateMappingsWork()
{
    Configuration configuration = new Configuration();
    configuration.setProperty(Environment.SHOW_SQL, "true");
    
    SessionFactory sessionFactory = configuration.configure().buildSessionFactory();
    Session session = sessionFactory.openSession();
    
    Map metaData = sessionFactory.getAllClassMetadata();
    for (Iterator i = metaData.values().iterator(); i.hasNext();)
    {
        EntityPersister persister = (EntityPersister) i.next();
        String className = persister.getClassMetadata().getEntityName();
        String qry = "from " + className + " c";
        List result = session.createQuery(qry).list();
        assertTrue("No results for " + className, result.size() > 0);
    }
    
    session.close();
}

To turn on the touch screen feature of an emulator, go into C:\WTK25\wtklib\devices\[device]\ and open up the [device].properties file.  Set: touch_screen=true.

JXPath looks pretty useful.  It provides XPath syntax to query your POJOs - very similar to LINQ.

I'm in the middle of researching platforms to put together a speaking assitance program for my daughter who can only vocalize a handful of words.  It must be programmable (C++, C#, or Java), have a touch screen, and have audio capabilities.

Possible platforms:

1. Nintendo DS
2. Windows Mobile w/NET compact framework
3. Java ME (formerly J2ME)

Currently I'm leaning towards Java ME since I now work with Java at work and that seems to have the greatest market penetration.  It looks like the Palm Z22 may work, it seems to have a J2ME implementation and is cheap ($99).

Mentions IBM's J2ME for the Z22 http://blog.tmcnet.com/blog/tom-keating/technology-and-science/palm-tx-and-palm-z22-handhelds.asp\

Palm Z22 specs: http://www.palm.com/us/products/handhelds/z22/specs.epl

Intro to J2ME with a Palm device: http://www.devx.com/wireless/Article/31092

Java ME home: http://java.sun.com/javame/index.jsp

Looks like I'll need this installed on the Palm device: IBM WebSphere Everyplace Micro Environment for Palm OS Garnet (WEME) provides a MIDP2.0/CLDC 1.1 compliant run-time: http://www-306.ibm.com/software/wireless/weme/

I just installed P4Report, which basically gives you ODBC access to your Perforce depot - pretty cool.  I can now whip out a status report for the week:

select user, description, date from changes where user in ('joe', 'dave') and timestampdiff(4, date, curtime()) < 7 and P4OPTIONS='longdesc' order by user, date;

I don't hate Java, it's certainly leaps and bounds over Visual Basic and in a lot of ways C++, but after working in C# 2.0 for the past year...  Eck!

Things I wish Java had:

• Better generic support - no erasure (screw backwards compatibility, do it right)
• Operator overloading
• Properties
• Partial classes
  

There would much more to hate if I wasn't using Java 5.0.  Apparently autoboxing, something I take for granted in .NET, just got added to Java in the last release.