There is a formal proposal to introduce closures to the Java programming language. For those of us who have been in the Java world for a while (10+ years for yours truly) this could really open up a lot of interesting possibilities to express solutions to really complicated problems, the way the functional programmers have been doing things, which can mean, less and cleaner code.

For example, anonymous functions, and first-class functions would be introduced as well as incorporating some of the more interesting features of languages like ruby (think blocks and yield) and scala will make for more concise code and, as an example, provide the developer with the ability to write your own control structures.

From the (current) specification:

“Modern programming languages provide a mixture of primitives for composing programs. Most notably Scheme, Smaltalk, Ruby, and Scala have direct language support for parameterized delayed-execution blocks of code, variously called lambda, anonymous functions, or closures. These provide a natural way to express some kinds of abstractions that are currently quite awkward to express in Java. For programming in the small, anonymous functions allow one to abstract an algorithm over a piece of code; that is, they allow one to more easily extract the common parts of two almost-identical pieces of code. For programming in the large, anonymous functions support APIs that express an algorithm abstracted over some computational aspect of the algorithm.”

This is pretty exciting for Java, and as a fan of functional programming, this is a real bonus for the Java platform.

Over the last several years the design paradigm of inversion of control/dependency injection has gone from an interesting design exercise to major league time savings and making complex things less complex (and at the same when done wrong, making complex things even more complex.) Developers in the Java world have enjoyed Spring, the de facto library that makes all of the promises of IoC/DI possible and rather straight forward.

However, with the continual maturity of OOP in PHP the concept of inversion of control/dependency injection has been slow to catch on. There have been attempts at providing IoC/DI functionality to PHP but many have just withered away and died. One such framework that may show some significant promise is Flow3, produced by the community of developers who have been slaving away at Typo3, a long running, incredibly feature-rich open source enterprise CMS. However, to date, Flow3 is very much like vaporware. Oh sure you can download it, but documentation is scarce to non existent and its missing one thing that I believe would slow its adoption, its similarity to Spring.

Spring got it right, by my estimation. The notion of wiring an application together via an XML file is spot on and truly enables developers to “write to interfaces” without ever having to concern themselves with the concrete implementations. The better code design, testing and time savings become very apparent once fully in practice. This shouldn’t just be something that Java (or .NET) developers enjoy. PHP is a major piece of technology, so with that said, I’ve taken the time and out of a graduate school project I recently finished devised a rudimentary IoC/DI container written in PHP. Currently it only supports a limited set of features, but uses the same concepts as used by Spring. Enter, phpBoing, which right now is quite simple and is just an academic curiosity, but with some work it could grow into a full fledged mature application development framework. No it is NOT meant to be another MVC framework. There are too many of those already, in fact, this system simply provides an object registry that lives in memory, defined through an “application context” XML where you can “inject” object dependencies via XML syntax, thus enabling you to “wire” your PHP applications together in XML (as opposed to doing so in actual PHP code).

In invite you to take a look, stab around at it, and if so inclined, contribute code.

We (that is, “we” developers) all have our favorite secret weapons when it comes to making the complicated (read: RIA) applications seem easy, stuff like JQuery, YUI, Flex, mootools (hahaha, funny right?) Flash, ZK, Openlazlo, etc. But allow me to introduce a new discovery, Appcelerator.

What is it? Well, its not just a collection of javascripts and CSS snippets, its more like a fully integrated development platform with its own (very ant-like) build system and (perl-like) updating system. Appcelerator, an open source (using the more friendly, flexible and down-to-earth license of Apache) system provides developers (not so much designers) with tools to make RIA applications less of a chore.

How it works is that Appcelerator’s SDK basically “compiles” a series of templates (HTML/CSS) and Java code and creates all the appropriate JavaScripts, and a WAR file. Using a message-oriented-architecture all communications between the front-end and back end occurs through discreet “messages” which are just serialized chunks of JSON. Appcelerator handles all of the marshaling/unmarshaling for you so your only concern is making the individual pieces of functionality.

Integration is what appears to be Appcelerator’s real strong point. With the ability to fit in nicely with a Java application, it’ll be more than happy to be in your Perl, PHP, Ruby, or Python application, as well as your Google Gears application as well. With a full suite of widgets and plugins most common pieces are probably already built for you… um, so you don’t have to!

The magic of Appcelerator happens by a dynamic HTML scripting-like language where the developer simply assigns IDs to HTML elements and an “on” attribute which defines (for Appcelerator) the action to perform:

<div id="my_comment" on="r:app.my.package.response then effect[fade]"></div>

What that basically says is when the id “my_comment” receives a response (r) of app.my.package.response then it will fade in the value.

Pretty cool huh? Yes, its way more sophisticated than just this ridiculously simple example, but the idea is that everything is done through a very human-readable scripting syntax and all of the heavy lifting and tedious code of calling the server, marshaling the objects and dealing with the output is done for you.

Fast on the heels of Craig’s last post, I bring you a new tool which is currently undergoing Apache incubation, which has the potential to radically change how you think about databases. Google kick- started this by publishing a paper on their “BigTable” system, and just a short while back Facebook released Cassandra out into Google Code, but along comes CouchDB.

CouchDB, like BigTable and Cassandra (and there are others out there) thinks in terms of documents, not tables. This is pretty significant, especially for developers who spend a lot of time building complex web applications where relationships are modeled in highly inflexible table schemes, using tedious joins and look up tables in an effort to artificially create flexibility through normalization. Well CouchDB does away with that entirely. Its not a new idea (see Berkley DB) but how they do it is what makes this thing fast, efficient and very compelling. Using the “map reduce” algorithm means the databases can be distributed over a number of disparate nodes (all on commodity hardware) and the searching is very fast in that you aren’t looking at everything all at once.

Also interesting with CouchDB is that it incorporates a “view” engine, and out of the box uses javascript as the view/query language. It doesn’t get much more simple than that. Written in Erlang, CouchDB is accessible via a RESTful HTTP interface and there are language bindings for nearly every popular platform.

Check out CouchDB, and relax! We’ll be hearing more about this in the coming months and years me thinks.

Interesting article on ReadWriteWeb today, The Main Street Web.

Its an interesting spin in how the Web/Internet/Digital-whatever will save us from a recession. A lot of interesting topics covered, and perhaps a bit on the (foolishly?) optimistic side, but at the same time, the piece actually makes a considerable amount of sense. Especially for outfits like Molecular who make all that stuff (mentioned in this piece) possible.

Read the comments as well, some good discussion (so far) happening.

At some point in a complicated development project there will come a time when you need to translate a java object (assuming of course that you are working in java) into XML or back. Sure, we’ve all gone through the pain of Castor and the performance hits you take associated with that, and there are other tools, but what is now considered (by many) to be the standard is XStream. I won’t go into too much detail as to why XStream is as great as it is (two words: pull parsing), but suffice it to say it is, great.

XStream uses an aliasing feature so that you can “pretty up” your XML (by default XStream will just use the fully qualified package name for XML node names) which can be weird.

To use the aliasing feature, in your code, you simply do something like:

xstream.alias("node-name",MyClass.class);

Well, that’s all cool and all, but its very hard-coded. Wouldn’t it be cool if you could just wire something like this together in Spring?

There is a way to do this, its quite simple in fact. It just requires you to make an interface that defines a single method, something like: String:getNodeName(). Each class that must be serialized would implement said interface. Now, you just do something like the following in your Spring XML (in this case I created a configuration bean that contains a list of my “models” that must be serialized):

<bean id="config" class="com.marley.tmac.tools.Configuration">
<property id="serializableClass">
<list>
<bean class="com.marley.tmac.models.User"/>
<bean class="com.marley.tmac.models.UserElement"/>
</list>
</property>
</bean>

Now, in the class that handles setting up XStream, you would simply have something like:

for (YourInterface model : listFromSpring) {
xstream.alias(model.getNodeName(), model.getClass());
}

As a good follow-up to Don’s piece, comes a new (Java) library that can make many of your security nightmares go away (with respect to all of those wonderful JDBC properties files with usernames and passwords for production systems, just sitting there, out in the open, just waiting to be discovered).

Jasypt, a library that supports encrypting properties files for Spring, Hibernate (and any other properties files you want to protect) will keep curious eyes confused when all they see are RSA encoded strings for what represents actual configuration data.

Red Hat’s non-profit arm, project Fedora just released Core 8, Fedora’s/Red Hat’s distribution of Linux. Fedora has long been a very developer-friendly operating system (unlike Ubuntu which lacks any developer tools out of the box) has taken further steps to embrace Java development.

Included with FC8 is OpenJDK and IcedTea, the open source version of the JDK /JVM and build tools. With Sun setting Java “free” OpenJDK and the IcedTea projects have become the de-facto open source Java environment.

Also included with FC8 is Eclipse, Maven, Ant, Tomcat5 (this should probably be 6) and Jetty. So we are talking major hardcore Java development right out of the box.

While Java 1.4 promised hot deploy, many implementations of application servers have fallen quite flat on their collective faces in delivering on this promise. Then along comes JavaRebel. A nice little library that actually makes this time consuming and frustrating problem a non-issue. Check out some of the features:

• Changing, adding and removing class/interface methods
• Changing, adding and removing class fields
• Changing, adding and removing class constructors
• Overriding existing methods
• Creating new classes or renaming old ones (as long as some other class superclass doesn’t change)
• Changing method parameter or return types or field type without changing its name
• Changing, adding and removing class/interface constant fields is supported, but will not get reinitialized and thus is only useful for primitive types and Strings

(taken, liberally, from their page here)

Yes, there is a performance penalty with this, so DO NOT EVER use something like this is a production environment, but it can make your life as a java developer, especially in a local environment, a bit more productive and a lot less infuriating (but, er, we never get mad at Java, because Java is infallible!)

With the recent release of Alfresco 2.1, this relatively new entry to the “enterprise-class” open source content management system is beginning to show some very real signs of being a major go-to tool for organizations who need all of the enterprise features of your Documentums, or Teamsites or Vignettes, but being completely open source.

Alfresco’s features are impressive, fully customizable workflow, document management, user roles, remote publishing features, as well as easily integrating other applications to create mashups. Built on a JEE platform, and runs in JBoss, Tomcat, Geronimo, it has real promising of being a mainstay in an Java open source enterprise stack.

While OpenCMS is the old timer in the enterprise-class open source CMS, Alfresco is showing remarkable maturity, in particular to documentation (if you’ve worked with OpenCMS I’m sure you know about the weakness in the documentation) and its feature set. There is also a well established organization backing up Alfresco, providing professional services and support, as well “enterprise” versions of their product, while maintaining a “community” edition.

I’m currently giving it a spin, and am incorporating it into our “home intranet” to publish web content to our various project sites, so the back-end content management is completely decoupled from the front-end content delivery (web) tier. So far, it seems to be working like a champ.