Blog

April Fools Day is Here!

J# retired and I just now caught this! That's wonderful news!

The major leap forward seems to be project lifecycle management, and collaboration suites. It doesn't seem like too long ago that we had a compiler, an editor, and some sticky notes.

I just deployed a new version of the Tapestry 4.1 archetype. It's the same parameters as the archetype discussed previously. Essentially, the new version provides a few new features:

Gmail is down, and I’ve not been able to access it with any sort of consistency for hours. What am I missing? What’s wrong? This has happened to me before, but never for this duration

I love working with Tapestry 4, but I figure that it's because it's already configured to do the cool tricks I want to do with it. It's not easy getting off the ground on a blank new project. (Nor is it easy getting off the ground in a Ruby On Rails project without using the project generator!). Maven offers a solution, but, seemingly, no good archetype for it exists. I want something that'll let me type mvn jetty6:run and pull up a page immediately after I've run the familiar "mvn archetype:create" incantation. I tried the (admittedly preliminary, at this stage in the game) Appfuse archetype, and the one from Webtide. However, I wanted something that I could demo with really quickly. I imagine: 1.) I have the archetype. 2.) I mvn clean install it, and voilà, instant "hello world" application that could be aggressively/quickly modified. I took Howard Lewis Ship's Tapestry 5 Simple-Project archetype and expanded it/retrofitted it with a lot of Tapestry 4 scenarios. I also wanted something that eased some real-world concerns or, at least, hid them. Something that already had a working example of most common things (setting up an ASO, using Spring. Perhaps I'll add SEO friendly URLs configured by default (well, for the common ones, with the less-obvious options commented and explained.). Anyway, thanks again to Howard and the Tapestry for such a wonderful product. I'll evolve this version and clean it up. If there are any suggestions, I'd definitely appreciate it. It's deployed to my repostory. Run the following command, and you'll have the archetype installed and a project created. Then, merely cd into the wordking directory and run mvn idea:idea, or mvn eclipse:eclipse, and then run mvn jetty6:run to get started. This will get your application running on port 8080. Simply bring up http://127.0.0.1:8080/ and you'll get a listing of all the contexts. You can modify the various configuration fles (save, of course, for web.xml), and HTML ad-infinitum without restarting. The second you compile a fresh class, Jetty will reload the context automatically. mvn archetype:create -DarchetypeGroupId=com.codecafe.archetypes -DarchetypeArtifactId=tapestry-simple -DremoteRepositories=http://codecafe.dev-hda.com/repository -DarchetypeVersion=4.1.2-SNAPSHOT -DgroupId=c.b -DartifactId=view

I just started playing with JSR 296 as I've recently started building an application that's Swing based (albeit, as an applet, which I'd like to make Java Webstart-able). It's phenomenal! As it stands right now, you can easily databind, internationalize, easily layout GUIs, and build on a useful Action abstraction if you're willing (and able! And what rocket scientist isn't?? Oh, you're not a rocket scientist… well…. I see… Go sit in the corner.) to coordinate the tapestry of solutions out there. JSR 296 seeks to bring a lot of that flexibility to the developer right off the bat. With it you get internationalization, an action model, application lifecycle, persistence, etc. Pretty cool. Still missing is databinding and IOC and a layout mechanism. Fortunately, SpringRich, and JGoodies help alleviate those pain points, so I'm pretty stoked about the possibilities. Maybe one day we'll have a framework for the desktop user and it'll endeavor to bring "web-style programming" to the desktop. Which reminds me: all those frameworks endeavoring to bring Swing-style programming to the web (Wicket, JSF, Tapestry, Echo, whatever else I missed: this means you!) should change their attitude a little. It's telling that all of the things this framework brings to the table have been de rigueur in web frameworks for half a decade. Check out the Swing Application Framework for more. I wonder what this will mean for so much of the way an application is built currently. Will I have to become very good at securing SOAP services again? Will an easy, useful desktop programming paradigm reverse the transition from Web Services to JSON? I deployed a custom XML-based (not XML-RPC, or SOAP, but my own protocol) service specifically to be able to achieve modest portability/thoroughput on a prototype J2ME application I built a year or so ago. This was so because the XML parsers are sketchy enough. SOAP stacks (while available, even as a standard) weren't prevalent enough. I can see Spring earning it's keep here, again. Imagine what could be done with a useful databingn mechanism and a convenient way of exposing services (à la Spring). Desktop applications could become the rich client king again. Maybe. Meanwhile Bruce Eckel seems to think rich clients are where it's at, as well. Of course, he's pitching Flash, and not Swing. Can't wait to see what's next. Windows Vista (Aero, WPF) is poised to make the rich client desktop commonplace. Maybe it'll heat up the landscape enough to drive a resurgence for the desktop developer. Any one use any of these tools? Anything I should know?

I'm about to upgrade to JDK6 on my Windows XP machine. I'm running IntelliJ 6, which I understand works well on the new JDK. Confusing is the lackluster availability of the JRE. I expect Java.com to yeld a JRE 6 build, but instead it's still pushing the old JRE 5, which is also still being bundled with various PC vendors by default. Why is this? At what point does Sun certify a release as being "good enough" for the developers AND the rest of the world? The consensus seems to be that Java SE 6.0 offers the best out-of-the-box performance boost yet, by far. After a bit of searching, I finally got to this thread which has the whole process spelled out for you. I went with the second choice enumerated on the page (deleting the jre, and replacing it with JDK1.6's JRE as I didn't want to have to use idea.bat. Using idea.bat causes the DOS console to stay open while you're in IntelliJ. I created a second .bat file whose job it was to load the first one (idea.bat) like so: start idea.bat, however, the trouble is that didn't seem to work. I didn't want to give it much more thought and simply pursued the second option. I wholely recommend the upgrade it's very quick. Loading IntellIJ would be one kind of speed increase, but loading a very big project quite another, and they both dramatically improved, to the point that IntelliJ no longer shows me "Tip Of The Day" when I'm doing these actions because it doesn't have to keep me entertained. Completely worth it!

Aside from all the new APIs supported (and there are a LOT – some only previously available through extensions. Notable among them: Java APIs for Bluetooth ( JSR 82), Wireless Messaging API (WMA, JSR 226), and J2ME Web Services Specification (JSR 172), and of course we can’t forget.. argh... just check out Sun's page for the full scoop), the coolest thing for me has to be the standard support for the Location API’s. These APIs, of course have helped propel J2ME into orbit via Google’s "Google Mobile Maps" application (and the plethora of other maps / GPS applications out there helped, too, I suppose :-) ) This is an impressive release and long-awaited. One gripe: where’s my Linux SDK? I’ll have to use the windows version for now, I suppose. I should count my blessings: there doesn’t seem to be any mention of a Mac version!

I just noticed Salesforce.com’s latest step towards platform domination: Apex. I like the name. Cool. Sounds like Apress, and Ajax. Half buzz, half hard-hitting tech done cheap, with just a twist of that je ne sais quoi, that “this could be a Windows codename” quality. Yeah! I like the possibilities. The market for middle ware integration is astonishing. The application that’s readily customized is the application that more readily adapts, and is adapted. This should go a long way towards removing all the edge cases defying Salesforce.com’s proliferation. Apparently, they have a little less than 30,000 customers. I don’t know if that’s individual users or entities, or what. It’s not nothing. Interesting: the inclusion of LINQ-style sql objects: Account acc = [select Id from account where name = 'xxx']; Account[] accs = new Account[]{acc}; System.assert(accs[acc.id] != null); It’s a typed SQL query, embedded inline with your java. Not like those opaque String queries I keep hearing about… I got the hint on all of this from eWeek magazine, in a small blurb about Apex of the January 22 issue. To my chagrin I get to the salesforce.com site, and start looking around right there, not too deeply linked, is Peter Coffee, formerly a columnist of 18 years at eWeek. He’s just switched jobs! Good luck, Peter!

Before Spring/Hibernate/that whole wave came along, I don’t remember being particularly inspired to have persistence and business logic attached to the entities on which that logic acted… In fact, I rather disliked EJB’s entity beans pattern specifically because everything was on the bean itself. Often times it’d be on a SessionBean, and that’s good. But even there, entity beans have basic persistence, removal and lifecycle operations built into it. A Car doesn’t car how it’s persisted, does it? Then along came Rails (the most infamous example of this pattern) and suddenly everything is built into the object itself. And, honestly, I like the pattern there. Everything is static if its an operation that would be done by a DAO in Java. It’s a property if its to be persisted. Simple. You know where you stand. I also like the DAO/domain objects mechanism in modern day Java. That said, I’m astonished at how ugly having the DAO functionality built into the domain object can get in Java. I ran across some code that has factory methods for returning the entity! Then, as you modify the properties in the entity (mutator by mutator), it writes them to the database! Ugh! Modify 10 properties on the object, and lo 10 update statements fly by your console. Furthermore, I’ve gotten used to the idea that you can have an interface defining a contract and then an implementation of that DAO’s interface. You can hide that implementation (especially with Spring) behind its contract through any number of remoting technologies, simple base casts and more in a local call, and more. You don’t have to include the accessor / mutators in the interface, too. That’s pretty remarkable.