Maybe this session sounds like old hat, but I’m looking for more ammo to add to the list of reasons we should jump to Java 5 from either 1.3 or 1.4, and sooner rather than later. Already on the list is that we’d like to get to Tomcat 5, and introduce Hibernate. In introducing Hibernate, I’d prefer to go straight to H3 with annotations rather than do a double effort of implementing Hibernate with typical mappings or XDoclet, and then moving to annotations. Venkat Subramaniam is presenting.

I’m going to go about this session a bit different and actually post the entry now, and update it as the session progresses.

• Autoboxing – the nice syntax cleanup that turns a bunch of casting from primitives to objects (int to Integer and back). I know that it’s just Java doing all the casting behind the scenes, but I like the way it takes some of the ugly and tedious code out of Java source. The gotcha I wasn’t aware of is that if you write “int myInt = myArray[0];” on an Integer[], and the element in the array has a null value, you get a NullPointerException. Ouch.
• Happier for loops – for(int i=0; i
• enums – nice to finally see a sane way of expressing enums in the Java language. Once again, it’s little more than magic hand-waving behind the scenes, but it’s a real improvement to readability, and short-circuits the constants-as-static-final-variables-in-an-interface anti-pattern, with type-safety as a bonus. Some folks have a real beef with Java shoe-horning these features into the language, I give them a ton of credit for accomplishing their magic in the compiler rather than mangling the runtime with all of these features. I also haven’t seen this magic of adding a method to an enum – very interesting. EnumSet and EnumMap are also news to me.
• varargs – I hadn’t even heard of this until today. More nifty syntax sugar that allows you to supply a variable number of arguments to a method, with type safety. Declare your method public static void doStuff(String…), and you can call it with doStuff(“one”), doStuff(“one”, “2”, “three”) – Java will, behind the scenes, make your method accept a Sttring[], and bundle up your method call parameters into a String[]. Very cool.
• Annotations – one of my favorite new features in Java 5, based on the headache it relieves in creating Hibernate mappings. Defining an interface is quite wacky, but I think far more people will be using annotations than defining them.
• Static Import – Venkat isn’t a fan of this feature, and neither am I. Static import lets you import all of another class’ static methods and call them without even naming the class they belong to. The methods are called just as if they were defined inside the class. This looks like it has major confusion potential, with a minimal value-add.

Mike Cohn’s 12 things you MUST do in transitioning to agile:

1. Pick the right project – find the project with the proper intersection of duration (2-4 months), size (1-5 teams), with a business sponsor, and importance (high – keeps you on task).
2. Pick the right iteration length – XP now says 1 week, Scrum says 30 days – just pick what works and be consistent.
   • Will you allow change during an iteration? (Refinement of requirements is not change)
   • He recommends no – pick an iteration length equal to how long the organization can go without changing its mind.
3. Get everyone on board – make sure all key players surrounding the project buy into Agile
   • Objection – it only works with talented people. No, but you need at least one developer who can fluidly move between different development techniques. (But you pretty much need someone like this for any project to succeed)
   • Objection – it only works on trivial projects. This is disproven by the number and breadth of complex projects that use agile (Yahoo, Joint Strike Fighter).
   • Objection – it’s not appropriate for all projects. This may or may not be true, but just use common sense, use it when it makes sense
4. Have a “customer” – an actual customer or product owner, and keep them consistently involved.
5. Start with a beachhead team – for larger organizations, start with a smaller, focused group and help them fight through the infrastructure and process issues until they’re succeeding. Ensure that this team is fully cross-functional.
6. Deliver – makes sense. Don’t allow the team to miss any deadline, large or small. Missing a small deadline trains the team to miss parge ones.
   • Stress quality, not speed. You want code you’re PROUD of, that you would hang on your mom’s refrigerator.
7. Automate – automate unit tests, acceptance tests, regression tests, builds, deployment
   • Test automation tools – JUnit, FIT, FitNesse, HttpUnit, HTMLUnit, Canoo WebTest
   • Continuous integration – Automated nightly build at least, if not continuous – Cruise Control, AntHill
8. Follow a guide – you need someone who’s been there before, either an employee or an outside mentor or coach.
9. Track and communicate progress – many approaches, from a task board to formal reports
10. Meet Daily – use a daily standup meeting to coordinate, communicate, and make committments to one another
11. Reflect – at the end of an iteration, reflect and discuss what we’d like to start doing, stop doing, and continue doing
12. Don’t try it all at once – start with the practices that seem most valuable, prioritize the ones you want to adopt later in a backlog.

His preferred order of implementing things – Requirements as user stories (light requirements), estimate and create a release plan, nightly or continuous build with tests.

I enjoyed the talk, though much of it seemed focused on how to sway the momentum of a large organization toward agile. He called a company a “small shop” when it had 100 developers. Our entire company is around 50 people, including operations, support, sales, etc. So our challenge is more about the proces to adopt rather than the politics of adopting it. Some later sessions may help shed some light on this decision.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium. I was using the [GAJSS] heading before, but thought NFJS Atlanta might be more clear, and better signal the relevance of the entires to the Atlanta community better.

Neal Ford is keynoting on using dynamic languages to build domain-specific languages. It’s a stark contrast to Dave Thomas’ keynote from 2 years ago. Dave was very philosophical on the ways we think about doing development. Neal is right down there in the code – source is getting more screen time than powerpoint at this point. He contends that Java is already commonly using domain specific languages in the form of XML configuration files for our frameworks. [As an aside, the wireless access here in the main session room/dining room is actually reliable. JRoller still continues its attempts to eat my drafts as I save them.] Thus far, I honestly think he (along with half the developer community) has gone a bit far off the deep end in terms of the pain of developing in Java. Perhaps I’m numb from being knee deep in Java for more than 5 years, but the repeated dismissive references to “curly brace languages” are a bit overstated, I think.

He’s mentioning Language Workbenches, but at this point it looks like the current set of language workbenches are all proprietary, vendor-based offerings. In my opinion, until there are multiple, freely available language workbenches, perhaps an Eclipse variant or plugin to handle it, this technology will face serious challenges to wide adoption.

So the general idea is that you use this language workbench thing to create a meta-language, that defines a language that is very similar to the problem domain. The problem I see with this is that each individual problem at each individual company is defined with its own domain specific language. One of the reasons community acceptance is such an important selection criteria in choosing which Java framework to use for a particular problem type is the knowledge that the more known the framework, the easier it will be to hire someone who immediately understands at least that framework, even if they don’t understand the company’s software yet. For lower level concerns, I can almost understand a use for this – in replacing the Java frameworks. At a higher level, in terms of a business’ actual problems, such as CRM, manufacturing, etc, I see a potential problem where you now end up hiring developers who understand neither your language nor your problem domain.

This is my gut-shot reaction. I’m going to have to chew on it a bit more and reach more long-term conclusions. Time to head home, starting back at 9 AM tomorrow.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.

More Stuart Halloway, now talking about Java Security (slides here. [Incidentally, Roller definitely needs a draft autosave feature. On a spotty network, this is KILLING me that any given draft save can kill my entry. Resorting to a copy of my entry before saving a draft is a cheap workaround.]

We start off with a look at the typical java platform security stuff, the java.policy file and such. I’ve never had much use for this in my work, so the move along to JAAS is a welcome one.
A good explanation is that a Subject in JAAS is a container, and a Principal is a set of roles, identities, and whatever else associated with that Subject. This is helpful for me, since I’ve always found those words unintuitive and confusing. The Principal class is nothing short of useless. The fact that Java continues to pump out specifications that are so dependent on vendor extensions to do anything useful is insulting and counter-productive to everyone but the vendors who depend on it as an obstruction to portability. [Just survived ANOTHER JRoller choke thanks to cut and paste.]

He also points out a nice permissions sniffer for making the trial-and-error process of figuring out which permissions your authenticated user (Subject) is requesting that it doesn’t have, and adding them to java.policy.

It’s been interesting, but perhaps hits java at a lower level of abstraction than I’m used to. I do mostly web apps, so my perspective is largely on the level of users and roles that are exposed in a webapp, and the permissions that are exposed in that relationship. The closest I get to worrying about JAAS implementation details is selecting which login module I want the app server to use. I don’t deal in permissions very often. This beef is probably more about my selection of this session than Stuart’s presentation of it.

I had a good bit on this talk, but JRoller’s habit of eating a post when you “Save as Draft” but the session has expired killed it. Stuart Halloway gave a fairly good overview of key cryptography concepts. Not enough to write your own algorithm, just enough to be dangerous, and probably enough to effectively use existing alogrithms in your application, which is really all most of us need anyhow. He alleges, based on the advice of several colleagues, that the JKS Java keystore implementation is NOT secure, and should not be used. Another nugget is that when generating random numbers for security-sensitive purposes, use SecureRandom, not the basic math package Random implementation. Past that, it’s mostly been an overview of key crypto concepts, keys, symmetric and asymmetric encryption, hashes, stuff like that.

Probably the most compelling point is that when evaluating the security of a crypto algorithm, the standard metrics that are spewed – key length, block size, etc. aren’t really relevant. What IS relevant is that number of steps required to break the crypto. And let me reiterate what should be obvious – unless you are an encryption expert, you are best off using the known, time-tested algorithms without known exploits, rather than attempting to write your own.

Ramnivas Laddad has obviously tinkered with a broad variety of performance monitoring techniques for J2EE. While he’s mentioning commercial projects, he also has plenty of practical free or built-in approaches for monitoring performance.

He’s pointed out Sun’s JVMPI, which is the built-in Sun approach to instrumenting an app for pre-1.4 JVMs, but the app has to be started in a special way, and runs dirt slow. I’ve used plenty of commercial products that use this API, and it’s brutal. If you do go down this path, the Eclipsecolorer plugin looks like a nice complementary tool to analyze the output. Using a modified 1.4 JVM or Java 5.0+, JVMTI becomes available as a part of the JVM, and it appears to be quite useful – one more feature to add to the list of useful reasons to upgrade our product to Java 5.0. JFluid in NetBeans gets a mention.

For database analysis, he recommends P6Spy (free) or JDBInsight (not free), and showed a nice example of decorating the JDBC connection to log timing information on all queries without intruding on the persistence code. A similar timing approach can be applied to servlets using a servlet filter.

We get a look at AOP monitoring approaches, not surprising given Ramnivas’ expertise in AOP (he’s presenting 3 other sessions, all on AOP). Some nice example code of an abstract service monitor aspect, along with an implementation. A decent idea, but the question remains of whether to add AspectJ to the massive framework stack already in place in most of my apps.

Finally, we get a look at load generation tools. The usual suspects are here – JMeter (normal web apps), TestMaker (for web services), Grinder (mentioned from the peanut gallery), and LoadRunner (if you’re rich).

The wireless network connectivity in this room is miserable. Unfortunately, a majority of the Agile sessions are in here. There’s a wall jack for ethernet, but who knows if it works – I don’t know when the last time was I used a hard line with my laptop.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.

Tomorrow, the No Fluff Just Stuff road show comes to town for the Greater Atlanta Software Symposium. I’ll be heading there along with a couple of other developers from our team here. Wifi and power outlets permitting, I’ll endeavor to blog the sessions as I go.

I look forward to this event each year – it is one of the most pragmatically useful and economical Java conferences out there. If you have the weekend and cash available, I think they still have some spots open. It’s as good a collection of Java and software development experts as you’re likely to get at a non-vendor-sponsored conference.

With my job responsibilities drifting more and more into development management, I’ll be spending a good bit of time in the Agile development sessions, but also get some good time spent in more concrete, learning, development sessions. I hope to see you there!

I’ve got some side projects I’ve been helping out on that are near launch, but by and large, my development has been fairly boilerplate using my standard technology stack. The day job is cool tech, but mostly hacking about on real engineering problems that don’t make for interesting blog material (unless you care to read about removing single points of failure and various linux hacking). The mechanics of managing monthly release schedules and processes isn’t exactly a “page turner” either.

I’m hoping to push some of these projects into new territory in the future, but for now, I’m doing stuff that doesn’t make for an exciting blog. Time to start gathering some Deep Thoughts.

If you’re in Java, and in Atlanta, tonight is AJUG, and you should drop in if you get the chance. The topic will be Service Oriented Architecture, and the presenter looks qualified enough, though there’s a definite risk of degeneration into a vendor-specific presentation (though AJUG has done a good job of reigning this in recently). Details are here.

Though many could rightly criticize SOA as a mere repackaging of SOAP and Web Services, I’ll be going for the broader understanding of usage patterns and best practices – not as much for the nuts and bolts of how to implement SOA (alternately stands for Same Old Architecture). An interesting wrinkle in SOA in the modern web development era is the idea that you could use the same web service to feed B2B applications AND as a source of data for an AJAX component (Amazon.com could easily do this).

June’s Atlanta Java Users’ Group covered AJAX – while not purely a Java topic, I firmly believe that it will become one of the “must have” skills for J2EE development in the near future, at least for apps with a user interface. Some folks from a local software company, ClearNova, showed up to present. The topic expanded a bit further to encompass Rich Internet Applications.

The usual XMLHTTPRequest approach was mentioned, but the less frequently mentioned hidden IFRAME strategy was also mentioned (though not technically XML). IFRAME has an advantage in that it can point to any server. XMLHTTPRequest must point to the same server and port that the page was loaded from, but is apparently faster than the IFRAME approach. Hidden IFRAME loading may also cause the user to see status bar changes our hear “click” noises.

Overall, AJAX makes good demo-ware. They showed several different examples of pulling data from the server. The real challenge with AJAX seems to be manageability. There are few patterns out there for just how AJAX functionality should be arranged for maximum maintainability and following good design principles. It seems like right now, it is easy to put into an app, but perhaps hard to do so in a clean fashion. Maybe part of that is just my impression of javascript development – a pain, and difficult to debug.

Suggested resources:

• AJAX Patterns web site
• Java-specific Frameworks: Echo2, DWR, ThinkCAP (our presenters’ product).
• ajaxpatterns.org
• ajaxpatterns.com
• Prototype – OO javascript library for XMLHTTPRequest, includes various nifty effects, and is the basis for Ruby On Rails’ AJAX support
• Sarissa – XML library for XSLT, PHP specific

ThinkCAP did show the typical J2EE “Store” implemented using their product. They floated the typical Gartner stats pushed by the “simple IDE” vendors, touting a continued linear growth of “hands on the code” developers couple with exponential growth in “point and click” developers. If anything, I’ve personally seen the demands of business applications become more complex, driving higher demand for highly technical developers, but maybe the vendors will get there someday. Their product may be right for some companies and projects, but I don’t think I’ve ever been on a project that would have benefitted from them.

The meeting was definitely worthwhile – I’d encourage you to check out the video of the presentation once they post it on the AJUG web site.