This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: Friday's Austin Lonestar Software Symposium
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
There's quite a few folks going to this year's symposium: a crap-load of BMC folks from another team and some folks I know from Cobalt: Gregg and (thought I didn't speak with her, just saw here) Asha. Gregg works at Hoover's now and has a wicked big beard. From Matt Ray, I know Asha works at 360 Commerce. And the BMC folks, of course, work at BMC.
I went to 3 sessions: Introduction to Reflection, Metaprogramming, and Lucene. The first two were presented by Stuart "Stu" Halloway, while the last was done by Erik Hatcher.
Intro to Reflection
As it says, this was an intro class, but, what the hell, reflection's cool, and after that chapter in Hardcore Java, my interest has picked up again. The last 15 or 20 minutes were the most interesting because they were a quick overview of some aspect-y stuff.
Having written a marshalling framework from scratch at Coral, I've gone through all the reflection hoops -- like calling setAccessible(true), but it was good to get a refresher on everything. And, this slight foyer into the J2SE's policy file driven security framework -- in regards to reflection -- was interesting.
He asked a question early on that he never got around to giving the answer to: what are the thing you can't access reflectively? The little list I came up with in my head was: comments and JavaDoc, the actual code, anything the compiler optimizes away or reformats, imports, whitespace.
Metaprogramming
Here, there were more applications of proxies, AOP, some Objective C (which looks pretty interesting), and lots of talk about the whole duck- and loose-typing school of thought re: Java no-a-days. The thrust behind a lot of these things was that it's too complex to do things in a J2EE world, so there's a search on for simpler ways.
Someone in the front row started an interesting mini-debate along the lines of: we finally have all this J2EE stuff automated and figured out, so why change? Which, distilled down is a valid question that the Better, Faster, Lighter Java crowd (which this conference is pretty much made up of) has to spend a lot of their time addressing. I'm sold on the whole concept because the idea of having to use something that "spits out code," configuration, or any other type of auto-generated stuff (e.g., all those XML config files, EJB classes, etc.) seems silly to me: the framework shouldn't require all that.
More importantly, this light-weight stuff enabled easier testing. Often, objects or services you create have strong dependencies on the context they exist in -- that is, you need your container (JBoss, WebLogic, etc.) running and fully configured with all it's various J2EE things just to call a simple method.
For example, if you're going full hog with the DB DataSourcing, transaction
management, etc., you might need JNDI running, some JTA stuff, and all the piping and config'ing that goes along with running your app server.
But, to do your simple testing, you don't want to sort out all those things: you just want to go into the Run menu in Eclipse and click "As JUnit..."
That's where all of this better, faster, lighter stuff comes into play.
After seeing both of Stu's talks (and his one on Classloading on Saturday), I'm definitely going to read his book, Component Development for the Java Platform next. I flipped through it at a co-workers desk the other day, and it looked good. I think it's even buried in my wish list somewhere. I'll have to borrow that AspectJ book Chip has too: I can definitely tell that we should be using it at least in our tests.
As I've never read up on Lucene, this one was very interesting for me. There's not really much to go over except to say that it seems like a damn good choice for implementing search. Also, I'm going to have to take a look at Nutch and see if I can make it a skunk-works web crawler for work: I'm hoping it'd be useful.
Previous Topic
