Matt Ingenthron's Stream of Consciousness

Thursday July 01, 2004

JavaOne's SWT and Swing debates Now I see how we got to where we are in the debate titled above.

I already knew that IBM's old tools were smalltalk based, but I didn't know the group that had built those IDEs was also the one that had originated SWT.

Now that I know that, how SWT came to be makes sense. Basically you have a company that had an interesting (elegant?) solution for the lack of anything even close to portability standards for UI toolkits. In building their next generation of tools, they were faced with the same problem in using Java to develop their IDEs. They used a solution they already knew well.

I personally (not that my opinion matters much) have only two quarrels withthis:
- When buying into Java, there are times to conform and help push something everyone benefits from forward, and there are times to mutate in multiple directions until the harsh realities of the 'real world' show the best choice. Was this even considered when spending a substantial amount of effort on SWT? Probably not, and IBM (if you could personify a company) should have thought about it a bit more.
- Why did IBM latch on to it big time and use it as a way to market themselves and fragment the community? Specifically by building the whole thing and then plopping it on the world, calling it Eclipse (come on guys!) and then flinging the open source term about, as if Sun wouldn't take help from a licensee in improving Java's Swing for all.

Anyway, the deed, be it damage or not is done. We now have two toolkits. It sounds like it's IBM and the eclipse org who will keep SWT moving forward (and constantly chasing the platform changes), and it's the rest of the world, including Sun (remember, all of the other major IDEs are swing based) will be keeping Swing going. Plus the latter group will be getting better and simplifying with stuff like JDNC, JDIC and Project Looking Glass.

Disagree with me? Please, post me a comment.

Trivia for the day: Where did the name Swing come from? Same place as Duke! The Jazz theme of course.

Updated wirelessly from my Treo... ( Jul 01 2004, 05:38:55 PM PDT ) Permalink Comments [1]

More on Hibernate

For those who may have read my earlier post on JBoss and Hibernate (anyone out there?), I just attended a session that included hibernate. I have a couple of thoughts based on what was presented.

- Hibernate has explicit calls for controlling the object cache; seems like this is the opposite of what you want in the container model. Shouldn't this be someone else's problem? Won't it lead to people doing things similar to calling system.gc? Maybe I need to look at it more closely.
- It uses native sequence generators if avail, otherwise it emulates. pretty cool way to help people develp code easily and remove even more plumbing. - It appears to be pretty flexible on db schemas. But it does submit you to some XML mapping that doesn't look too bad. From what I've seen, annotations in J2SE 5.0 will clean that up for EJB 3.0.

I wish I had the time to play with it, but I don't really these days. So much to do and so little time. Anyone else ever feel like that? ;-)

Updated wirelessly from my Treo... ( Jul 01 2004, 04:58:22 PM PDT ) Permalink

Tuesday June 29, 2004

Day Two Well, day two started off with a headache. It's gotten better, but I still feel pretty tired. Had a great (and expensive) dinner at Roy's. I've been eating too well here- I'll have to back off when I get back home.

I've not gotten to too many sessions, but:
- Groovy is, well, groovy
- SVG has come a long way
- Creator is pretty darned cool

No fancy dinner tonight- I'm going to go check out the "Tiger's Children" BOF, among others. I hope to find something a bit healthy, yet quick.

More later. . .
Updated wirelessly from my Treo... ( Jun 29 2004, 06:01:07 PM PDT ) Permalink

Wednesday June 09, 2004

What's old is new again...

First of all, a big thanks to Marc Fleury and Gavin King for coming to our LA JUG meeting last night. I'm sure they tune into my blog all the time. :)

Hopefully the slides will be posted soon off of the LA JUG website. To quickly summarize though, Gavin is the founder of the Hibernate project. He's also participating quite a bit in JSR-220 which will probably be EJB 3.0.

The reason for the title of this entry is that years and years ago, I remember looking at a draft of the JSP 0.92 specification. Way back then the idea whomever wrote that spec had was to use Java Beans (not EJBs) for the component model. Then the developer would progammatically control transactionality and such within the code they develop. Then things like the EJB spec including CMP (or the idea for it anyway) and things changes significantly going into JSP 1.2.

Marc's theme was to treat all of these components that reside behind the JSP/Servlet tier as POJOs (Plain Old Java Objects). Then through the use of annotations/metadata in Java 1.5, ascribe different aspects (think AOP) to these POJOs you've described. For instance, if you need something to be an entity, you can 'inject' an entityManager into a POJO using the @inject annotation. What this does is takes the developer out of the daily routine of coding to the current EJB specifications with all of it's home/remote interfaces and different facades for encapsulating how things are done. Instead it's replaced with a simple to read, easy to understand way for developers to declare what they want to happen. There are some other neat things like removing the need to write DTOs (Data Transfer Objects-- a TLA [three letter acronym] that describes all of those mountains of code that we write for moving data back and forth between Servlet/JSPs and the EJB containers). EJB 3.0 should also be picking up some of Hibernate's other great features, like very much simplifying O/R mappings and addressing common challenges in implementing such code. It also should give EJBs some more OO concepts that were lost with the component approach, like polymorphism.

Now that I reread that, I've kind of summarized in the reverse order of the presentations last night (Gavin went first and really described the moving from EJB 1 to EJB2 to EJB3, very coherently describing the problem), but it seems to help to take Marc's description of the problem and then translate that back into what EJB 3.0 will do.

Marc picked up where Gavin had left off, translating what EJB 3.0 will do into the POJO theme and describing how the EG is focused on simplifying J2EE development for the next release. He then made mention of how JBoss's 4.0 architecture implements this kind of thing.

Finally, he closed with a discussion of JBoss the company, and their thoughts around open source software. It was definitely food for thought-- I'm sure it's well described on their website.

Both Marc and Gavin are great guys and the LA JUG guys had an opportunity to share a beer or two with the JBoss folk at the local eclectic watering hole. Both are good guys-- if you're in the Silicon Valley region, I think they're on tonight at the SV JUG. I'd imagine they'll be at JavaOne too, so you can likely catch them there. It was clear to me that they're focused on how the applications work and how developers interact with these systems when building apps. Gavin in particular would at times get quite cerebreal; for example on how transactions are somewhat broken, in that there isn't a concept of an 'application transaction'.

It'll be interesting to see how this all works out. The only reason I want to reserve judgement is that to me, EJB 2.0 gave developers a framework to code to that would make transaction management and scaling things with lots of multithreaded access someone elses problem. EJB 3.0 seems to put this back in the hands of the developer with annotations. That, of course, means the developer needs to think about where the transaction is occuring and where to begin and end things. I don't know that this is a bad thing, but history with other languages has shown us that making the developer responsible for certain aspects of programming just tends to introduce errors. Still, EJB 3.0 looks to be much more accessable, and it doesn't matter how well/not well EJB 2.1 did things if it was limited to those who spent a significant amount of time understanding how it worked and coding to it's particularities in moving things about between containers.

In the end, Marc said, and I'd agree, that while the future looks bright, EJB 2.1 is where it's at today and you can still get plenty accomplished with that. 6 months from now we should all get to play with this stuff a bit more, and hopefully we'll find not too many more changes are needed to make it useful :).