techno.blog("Dion")

Sam Pullara has some interesting ideas on changes he would like to see to Java.

Auto-casting

To reduce redundancy in the code I will introduce Auto-casting. What this does is that if an object could be cast in place to satisfy a constraint then the compiler would do that. It will fail if the auto cast is ambiguous or if it would fail if the programmer put the cast in explicitly.

Map p = new HashMap();
p.put(”test”, “test”);
String s = p.get(”test”);

I would like to dynamically do this stuff though. As in:

p = new HashMap();

I also think that having native syntax for common structures fits my liking. Everything in Java is via libraries. For this reason I like the native support for lists and maps in Groovy ([1, 2], and [name: value, name: value]), as well as the enhanced GStrings. We use strings ALL THE DAMN TIME. Let’s make them easier to work with!

Using a factory like new method instead of an operator.

StringBuffer sb = StringBuffer.new();

This idea is fine. I don’t mind keeping new Foo() as sugar too. What I *do* want to see though, is the ability to override things so what is returned may be another object. This means that new can be a real factory that returns a subclass under some circumstances. Many languages (like ObjC allow this).

Reflective invocation operator to allow objects to have shapes without explicit interfaces.

Object s = “test”;
s = s->trim();

I have one reason why this shouldn’t be allowed. For copying and pasting the code. the > needs to be escaped! ;)

Closure-like (lite) anonymous inner classes

If an anonymous inner class created from an interface has only one method, allow that method to be implemented without signature. Name any arguments with the lowered classname plus a number if there is more than one or allow them to name the parameters in the new expression:

Runnable r = Runnable.new() { System.out.println(”ran method”); }

FilenameFilter ff = FilenameFilter.new() { return string.endsWith(”.gif”); }

FilenameFilter ff = FilenameFilter.new(File dir, String filename) { return filename.endsWith(”.gif”); }

I would really love full closure support. Talk to the C# guys, and they will tell you how much they love their delegates. Talk to Ruby/Groovy guys and they love their closures (don’t talk to the lisp/smalltalk guys! ;).

I do dissagree on Sam’s point that “What I really want is just a slightly better Java, not a Java-ized Ruby variant”.

I want more than that. I like the Java platform, but I want more options, language wise, on top of it. Different tasks deserve different tools in the toolbox. Although I sometimes want Groovy to be more like Java, I often finding myself thinking more like James Gosling. Why not go the other way, and innovate MORE in this language. Java isn’t going to change that quickly due to the JCP and the desire for backwards compatibility. With Groovy, and other languages, there is no backwards compatibility so new things can be tried. Java is in the toolbox. We can use it. Now let’s fill up that toolbox!

Russell Beattie has some Java 1.5 thoughts.

He has come up with my #1 favorite complaint about Generics. I am not going to complain about erasure, and the fact that is is unreadable:

An annoying part of the new Java code is the template syntax with < and > tags. Now you can’t just copy/paste your code into your blog site, instead you have to spend time escaping those tags. Bleh. I know C++ uses that convention, but I think Java could’ve done something a bit different and clearer. And there’s still tons of “redundant” lines like List<String> listOfStrings = new LinkedList<String>( ); I mean, how many times do I have to write List and String in one line to freaking tell Java what I want? I know this helps casting, but I never really had a problem with it and this seems like a band-aid, not a real fix.

That is true! Maybe with Dave “Roller” Johnson as a part of Sun, he will be in on the specs to make sure that things like this don’t happen! :)

Man. Did the guys behind naming SOAP realize how much play there would be from the witty geeks? First we have Don Box giving a talk on SOAP from a bath tub on the stage.

Now we have Don’t Be Afraid to Drop the SOAP.

This piece goes through the experience of Sam Tregar, a developer who added SOAP support to the CMS system Bricolage, with high expectations.

Now he is only a new project, Krang, and he discusses why he is using a simpler XML approach rather than going down the SOAPy road again.

Conclusion

SOAP isn’t a bad technology, but it does have limits. My experience developing a SOAP interface for Bricolage taught me some important lessons that I’ve tried to apply to Krang. So far the experiment is a success, but Krang is young and problems may take time to appear.

Does this mean you shouldn’t use SOAP for your next project? Not necessarily. It does mean that you should take a close look at your requirements and consider whether an alternative implementation would help you avoid some of the pitfalls I’ve described.

The best candidates for SOAP applications are lightweight network applications without significant performance requirements. If your application doesn’t absolutely require network interaction, or if it will deal with large amounts of data then you should avoid SOAP. Maybe you can use TAR instead!

A blog discussion has started on the subject of lightweight containers, and somehow changed to OR mappers at the end :)

Neward on Crupi

What is the state of the enterprise Java world, anyway?

I think there are some KEY differences with the recent move to lightweight containers.

The various tools that I seem to prefer these days have one thing in common:

Transparency

I think this is a huge thing. I think that so many projects have gotten away from core OO practices (and OO doesn’t mean distributed objects Ted!) because they were stuck with crappy EJBs. These applications were built using “patterns” of:

Stateless Session Bean – Entity Beans – which use DTOs

This isn’t OO. This is RPC. The entity beans often had simple mapping, and don’t allow for inheritence. DTOs are evil as they are a duplicate layer of structs that you are throwing around.

Note that I am talking about an application that isn’t a service. I am talking about building an internal application first, using good OO practices, and THEN you can lay on the service layer to allow for external stuff.

So, back to transparency.

IoC Containers

I can finally write code that is just POJO based. There are no extension points to the framework. I am not stuck extended evil EJB interfaces and classes, having to create “home” interfaces and such. This all gets in the way. Not only does it get in the way but not I am totally tied up in knots.

With a container like Spring you look at my code and would have no idea if I am using it! What if I want to move to something else like Pico or Hivemind? I can. My core business logic is in tact and I can go about my way of moving. I don’t sit around crying because I have to munge my logic from the coupling with the framework! I love it.

JDO, Hibernate, etc

I like transparent persistence (not that it is truly transparent due to the OO-DB mismatch… but it gets close). Once again, I can develop a full, rich, domain object model. The model can even have inheritence and interfaces, and maybe people will put in real business methods that do things instead of just gets and sets (gasp!).

Now with a marriage of these technologies I have a clean domain object model (transparent persistence), and clean services (lightweight container). Testing IS a lot nicer too in my experience Ted. You don’t need to run around finding or building bloody mocks for the environment.

2PC

I do agree with Ted in that EJB is good for some things, such as 2PC and Message Driven Beans. There is going to be a kick arse way to do MDB in Spring coming up soon, so that need will go away. What about 2PC?

Well, a couple of things can happen:

a) The lightweight container can support them
b) You use an EJB when you need to do 2PC! One nice thing about the lightweight containers is that they can be used WITH EJB too :) However, HOW many applications need 2PC? 2%? And then within those applications, how many of their transactions need to be 2PC?

If you can’t see that Spring isn’t nicer than EJB? Ouch. You must like eating the elephant ;)

I have just gotten back from a vacation. Part of it was induced from being sick with a virus recently.

This vacation didn’t have anything to do with going anyway. Rather it was a vacation from a piece of technology.

I have recently left off my IM client for a couple of weeks. It allowed me to get a break from a little of the madness, and focus on some other matters.

Now I am rested, just like I had been on a real vacation, and the IM jumps up into life again :)

A developer in my Groovy presentation at this weeks No Fluff in Chicago brought up a good point.

He has been using Groovy for the last month or so, and he feels like he can experiment a lot.

What does this mean? I totally understand what he is saying here.

If I am working with a language such as Groovy, or Ruby, or many others, I find myself starting up a shell, or an editor, and hacking out some code. I poke and prod at new APIs. I try new things. I play.

With environments like Java, C/C++, etc I don’t feel like that. It feels more ridged, and I feel like I have to “Start a new Project” in an IDE. I have to setup classpaths. Copy over all of these libraries. It FEELS like a pain. It is annoying to have to write some code and go through the compile/build/run cycle, even though the tools help me out now.

Deep down I also feel like I should be comtemplating my code a lot more. Designing it. Etc. I feel bad about playing :)

A lot of this is pschological of course. I do setup a “scratchpad” directory under src/ to allow me to play on a project more easily.

Sometimes I want to be a kid again. And when I do that I play with Groovy :)

Joe Walnes just emailed the SiteMesh list with plans for SiteMesh 3. They all sound good, and it is great to see work ramp up.

If anyone has good ideas, send them over to the list.

If anyone is using Tiles. Give SiteMesh a try ;)

Hi everyone,

I just thought I’d give you an update of what’s in store for the upcoming SiteMesh releases and how they benefit you.

Firstly, there are a number of accumulated bugs that we’re steadily working our way through. The recent 2.1 and 2.2 releases have been mostly bugfixes, and this will continue for the 2.x series, including those related to using MVC frameworks such as Struts and WebWork.

http://jira.opensymphony.com/secure/BrowseProject.jspa?id=10000&report=roadmap

Meanwhile, SiteMesh 3 has been brewing. It’s been four years since SiteMesh was first open-sourced (it existed for two years before that as closed-source) and in that time it hasn’t really changed significantly. SiteMesh 3 is going to see the largest set of improvements since it was initially released.

== Flexible HTML processing ==

The core of SiteMesh is based around an HTML parser that is very fast and tolerant to badly formed HTML, however at the cost of being extremely hard to extend.

SiteMesh 3 will contain a new parser, which is easy to customize, without compromising on performance and tolerance to malformed HTML. This will allow extensions to be written that can:

* Extract user-defined properties from the page beyond the predefined ones from
<title>, <meta>, <content>, etc.
* Remove blocks of content from the page.
* Transform HTML as the page is parsed.

SiteMesh will come bundled with extensions for popular tasks and it will be trivial to add your own. More on this in a follow discussion.

== Improved Velocity integration ==

This follows on from some work done by Atlassian and will allow a page
to be generated using the Velocity API as an alternative to calling Servlet
RequestDispatchers and the Filter.

This offers significant performance improvements for applications that don’t
use JSP and allows more of SiteMesh to be used in environments outside of
the Servlet container, which leads nicely on to the next feature.

== Offline support with StaticMesh ==

There has been a lot of demand for using SiteMesh to generate web-sites in an
offline manner. A common case for this is a simpler alternative to
DocBook style tools, allowing documents to be authored in standard HTML
capable word-processing tools (such as MS Word, OpenOffice and Mozilla
Composer), giving you the full capabilities of a rich-text word-processor and
without the need to learn a special markup/schema.

SiteMesh can then process these raw HTML files and generated another set of
static HTML files with the appropriate presentation and navigation added.

Building upon the extended HTML processing capabilities, it will also be
possible to do things like generate a table of contents, footnotes, and
diagrams from inline syntax.

There have been at least three seperate incarnations of StaticMesh appear over
the last few years. We hope to bring the best bits from each of these into the
final version.

http://www.pols.co.uk/downloads/static-mesh/tutorial.html

StaticMesh will have a simple API for configuration, bundled with a
command-line wrapper and Ant task.

== Backwards compatability ==

Just to ease your minds, you’re not going to have to rewrite your applications
to use SiteMesh 3. Great effort will be taken to ensure that backwards
compatability is preserved. The library will have more features, but at the
same time a lot of the old stuff can be simplified. Dependencies will be
minimized and optional – for example, you will only need velocity.jar if you’re
actually using the Velocity stuff.

I’ll be posting more information in follow up discussions.

[Watch this space...]

cheers
-Joe

You are playing poker with a bunch of geeks.

You have to get up to go to the bathroom.

Do you count your chips as you don’t trust them?

Not Jason Hunter. He gets out his cell phone and take a photo of his chips :)

Then when he comes back he tries to map his photo to his stack to see if they are still there.

It was a fun poker game last night at the No Fluff. I hope we have more!

del.icio.us shows you that Google aren’t the only guys that get it ;)

The concept could have easily come out of Google though.

The concept is so simple too. You create bookmarks, and you tag them with metadata. This is exactly what I want to be able to do with my email (and you can with GMail).

del.icio.us gives me:

• The ability to easier sort through my book marks.
• An easy way to find great content through the “Those who care about, also cared about” mechanism.

I just love it.

Aslak brought my attention to Guantanamo.

Guantanamo is a tool that deletes all code lines that are not covered by tests. Guantanamo is part of the Extreme XP Tools family. Some thoughts about why it was created are written down here.

Now that is hard core. Nuking un-tested code :)

I can picture myself forgetting to write a test first and then writing the best piece of code in my career…. and seeing it deleted ;)