It wasn’t until earlier this year when I started learning Scala that I had to venture into how a class was loaded in Java. It wasn’t that Scala required you to know it, it was simply that they made reference to the Java class path loading basics. I think it was to demonstrate that if you wanted to use Java class, where it would be pulled from and when.
Previously, at best the only thing I’d had to worry about the order that classes were instantiated and by whom, mainly when sorting out issues of Hibernate either having Lazy cglib instantiations when they were meant to be real classes and vice versa. A completely different problem but the only time I’ve had to worry about the way objects and classes come to being.
Yesterday while flipping through Head First Design Patterns, I also came across the discussion about Class Loaders when talking about Singletons and having two threads instantiate a Singleton class each and how to avert the problem.
Today, one of the senior developers was summarising an issue we had at work and mentioned that our custom ClassLoaders used by our webstartable app may have been the cause of the problem.
The universe is asking me to learn about classloaders, hehe….
So, in short, there are three class loaders in the JVM.
- Bootstrap class loader – loads all the classes/jars in the JAVA_HOME/lib directory
- Extensions class loader – loads classes/jars in the JAVA_HOME/lib/ext/ (Something reminds me here of the libraries Quicktime would install, and if not, those hooks that Mercury Quicktest Pro would use to get into your java app to automate it)
- System class loader – looks at your CLASSPATH variable
So you can make your own classloaders in addition to these. Wikipedia’s article sights reasons of encryption, rmi, basically any time you need some dynamic class loading :).
A google search was rich with resources:
JBoss wiki contains a tutorial on ClassLoading
The basics of Java class loaders
OnJava’s article: Internals of Class Loading
Fit is a framework that helps the business get involved in specifying the requirements that end up being the testing. When the business can use Word and Excel to generate their own test cases, connected to a simple fixture and can be run by developers, customers and managers on demand, the potential for something great arises.
Encouraging the business to get involved at an early stage means that the business refine their requirements further.
Fit Tests can tell us useful things. Where a FIT test fails, its an indicator that we need more code to cover business requirements.
Fit complements xUnit, the fixtures are similar but the test data, state and structure is all defined in the business supplied doco’s. The fixtures are simply glue from these documents to the tests.
Automating Business Value with FIT and Fitnesse from InfoQ
Fit: Framework for Integrated Test
And when regular XP wont do, get Industrial XP. Nothing to do with FIT, just a site mentioned in the first link.
In this presentation about FIT, the presenter, David, takes a look at the meaning of the term ‘the build is broken’. What it is now compared to 10 years ago. He states that as technologists we should be proud that we’ve evolved the meaning from the literal code broke, won’t compile, to now a meaning saying that the tests are broken.
Given that in Eclipse, I’m told in almost realtime where compilation errors occur as I write them, and how this acheives high build success rate, I wonder if Eclipse can precompile and debug JUnit tests so that as we are changing code that is used in a test class, the test runs and the results are fed back in almost realtime, allowing us to pickup on even more potential hazards.
Lots of pitfalls for the cynical but its so crazy it just may work.
The busy Java developer’s guide to Scala: Of traits and behaviors
The busy Java developer’s guide to Scala (Ted Neward, developerWorks, 2008): Read the complete series.
“A Tour of Scala: Mixin Class Composition” (Scala language documentation): Learn more about inheritance in Scala and mix-in class composition.