Eben Moglen went over how the LGPL intent is that you can take out the LGPL portion of an application, upgrade and modify it. So conceivably you could unjar your application, replace the LGPL library and rejar it up. As long as your users can do this, you're conforming to the LGPL.
Sat in a great talk on debugging and improving the quality of code. The speaker was an author, I forget who. He recommended some tools to help with debugging and making sure your code is clean.
FindBugs is similar to PMD, there is overlap but both of them find some stuff the other doesn't.
Java Path Finder, no specific Ant or Maven support but you can just invoke the Java code from Ant. Don't forget to include JPF in your classpath along with your classes and set fork=true if you're using it under Ant. The project came out of NASA and according to their site has actually found problems in real spacecraft software. JPF verifies your code, how that differs from PMD and FindBugs I'm not sure.
For diagnosing and profiling a running application he recommends Glassbox and jManage.
He noted that JMX (or a combination of AOP and JMX) can be a great tool for monitoring a live application. Keep counters or otherwise keep track of the internal state.
Some other things worthy of mention were Lint, Verify Design and Jikes (just because it gives better error messages).
Rod Johnson gave a talk on Spring. It was mostly boiler-plate Spring stuff. He did mention that Spring can dynamically create MBeans for objects if Spring is aware of them. That's kinda neat.
There was a talk on creating manageable systems with JMX, Spring, AOP and Groovy. There were lots of buzz words but little content. He did bring home the point that running your application without JMX is like running a car without a speedometer. He also mentioned using Spring to easily make your objects viewable by JMX.
In hallway conversations I learned about a few tools.
OpenSTA isn't Java specific but it's for heavy HTTP load testing.
Chris Richardson (author of POJOs in Action) gave a talk on minimalist testing techniques. He mostly went through a bunch of best practices.
You need fast unit tests, otherwise they won't get run.
Continuous Integration should handle functional tests (instead of developers having to do them all the time).
Persistence tier can mock ORM layer, ormunit, use an in-memory database like HSQLDB.
Business tier testing can mock the persistence layer.
Web testing should leverage cargo for managing containers. Jetty is more developer friendly and faster to start. Junit 4.0 and TestNG both have handles for doing something (starting a web container) before all tests are run. So your tests could efficiently start up a container and deploy an application before all the tests run.
Top 10 ways to botch enterprise Java Scalability and Reliability was an entertaining talk. It was odd because for each thing that he mentioned he also advocated the converse of his assertion. His point was that you can take any concept too far and none of these points are absolute. None of the points were very surprising.
Avoid proprietary frameworks and APIs. The point is that depending on what you're using you'll get vendor lock-in but sometimes those proprietary frameworks may integrate and perform better in your environment.
Assume the network works. This is a reference to the Deutsch 8 Fallacies of Distributed Computing. I interpret this one as, don't forget you are on a network and there is latency.
Use big JVM heap size. I think he meant that if you have to tune the heap size there may be something else you should be looking at.
Use one size fits all architecture.
Assume disaster recovery can be added when necessary. I disagree with this one. I think starting out an application with disaster recovery in mind is a mistake. Handle all that in the infrastructure; the domain of application server and database gurus.
Abuse abstractions. Engineers can always use another layer of abstraction, sometimes this means a performance penalty.
Introduce single points of bottle-neck or failure. This makes sense, you have a clustered highly tweaked database but you're running your web-tier on an anemic box.
Abuse the database. Realize that not all data needs to be persisted. Is it not important or temporary.
Assume you are smarter than the infrastructure. Often times when you start turning knobs in the name of performance you undermine the capabilities of the infrastructure to do performance improvements.
Realize that performance doesn't mean scalability. Scalability is handling many users, performance is speed.
I think I would add that maintaining heavy state can be harmful to the ability of your application to scale. When you try to cluster a heavy state enterprise application the lights dim as all that data is shuffled around to various servers.
blog comments powered by Disqus