Thinking functionally (Teil 1)
Thinking functionally (Teil 2)
Thinking functionally (Teil 3)
Immutability
Coupling and composition (Teil 1)
Coupling and composition (Teil 2)
Functional features in Groovy (Teil 1)
Functional features in Groovy (Teil 2)

Weitere Artikel sollen folgen.

Currently, Grails uses Maven repositories for dependency resolution, but the build system of a Grails application uses Gant. For Grails 3.0 it is planned to establish Gradle as the build system of choice, as Gradle is getting more and more popular.

But as Maven is already widely used in the Java world, Graeme wants to provide Maven as an alternative build system.
There will be an initial plugin providing basic Maven support soon, which will be compatible with Grails 2.0.
A more refined integration will become available later, but it will probably requiere Grails 2.1.

The popular web developer tool Firebug has been released in version 1.9.

The new features include:

• Firebug panel docking
  it is now possible to dock the Firebug panel to any of the four sides of the browser window.
• Syntax error position
  Firebug now shows not only the line of an error, but also the exact position.
• Support for JSON responses
  JSON responses are now supported, including a partial copying of tree elements to the clipboard.
• Console log output linked to origin
  All console messages are now linked to their origin (file+line).
• More tooltips while debugging scripts

The full changelog is available at hacks.mozilla.org.

Firebug 1.9 is compatible with Firefox 5.0 – 11.0

.

Knockout JS is a small Javascript library that offers declarative data binding for your HTML code. It enables you to separate you HTML code from your data and UI logic, offering automatic UI refresh and dependency tracking.
I’m going to write an introductional blog post on KnockoutJS soon. In the meantime, check out the great introduction video of the creator Steve Sanderson.

The new features of version 2.0.0 are:

• Control flow bindings
  You don’t need a template engine like jquery-tmpl any longer. Simply use the new control flow bindings if, ifnot, with, and foreach.
  

  <ul data-bind="foreach: products">
      <li>
          <strong data-bind="text: name"></strong>
          <em data-bind="if: manufacturer">
              &mdash; made by <span data-bind="text: manufacturer.company"></span>
          </em>
      </li>
  </ul>
  

• Containerless control flow
  You can now avoid using a container element for bindings like foreach by using the new comment-based control flow syntax.
  

  <ul>
      <li><strong>Here is a static header item</strong></li>
      <!-- ko foreach: products -->
      <li>
          <em data-bind="text: name"></em>
      </li>
  </ul>
  

• Access to parent binding contexts
  You can now access properties that exist at the upper levels of binding via the new pseudo-variables $data, $parent, $parents and $root.
• Cleaner event handling
  There is now a cleaner, more declarative syntax for event handling bindings that does no longer require to write inline function literals.
• Binding providers
  There is a new binding providers API to extend the default data binding mechanism. It acts as a general extensibility mechanism.
• Throttling
  It is now possible to limit how often change events are fired (e.g. only one change event per 500ms). BTW, ko.dependentObservable has been renamed to ko.computed.

For a full list of all new features see Steve Sanderson’s blog entry.

There is also a Grails Plugin available, but as Knockout is just a single JavaScript-File, I would recommend to include it in a Grails project directly without a plugin.

http://www.mediafire.com/?831pp1kk5p8kgjd

Source: https://groups.google.com/forum/#!msg/google-web-toolkit/wElYN-Thi2M/TCgLDSNRusEJ

Today we’re happy to announce that the Spring Framework has moved to GitHub!
As you’ve probably noticed, nearly every other Spring project has already made the move, and those that haven’t will soon.

In this context, there is an interesting post about „social computing, what to do when things get complicated…„

This document is an overview of the current state of Project Jigsaw, an exploratory effort to design and implement a module system for the Java SE Platform and to apply that system to the Platform itself and to the JDK.

To put it into context: this is draft 1 of the big picture, that comes after draft 12 of a jigsaw module-system requirements document. Why two documents? Is draft 12, although more complete, deprecated now?

One of goals of jigsaw – among many others, to many other IMHO – is to provide a scheme of some sort for versioning. Is this the way to go concerning versions? When it comes to documents and versions, one is not leading by example, not, not really… I am following the jigsaw from a public point of view for a while now – but I can’t tell you where to find versions 1 to 11 of the requirement document, and I find it somehow frightening to see a draft 1 on a related topic coming along. The „still to come“ topics at the end of the document can be found at draft 12 of the requirements documents.

To be honest, I have a bad feeling on all this modularization effort targeting jdk8. If I take a look at lambda (nice post here), we have a state document, a JSR and a plan to integrate it into the JDK source. Sure, we have voices complaining that it is too much, too little, to late – but hey – there is something to build upon. It is in a state we can actually believe it is coming. This feels far more solid that anything – everything – regarding jigsaw and modularization. We do not even have a JSR for modularization, as stated in the jdk 8 JSR!

Now back to the big picture document. It does not report the jigsaw status, and it is by far not as complete as the requirements document draft 12. But it does explain the syntax of module definitions on a more precise way, and does recap some of the big picture goals of jigsaw.

Big picture, the design principles:

(1) Modularity is a language construct
(2) Module boundaries should be strongly enforced
(3) Static, single-version module resolution is usually sufficient

Sounds good, but (1) is the whole point of adding modularization to the jdk, or we could just stick to OSGi. A modularization that is not enforced is not (read enforcement here), so we all agree on (2). That we are going to need split packages loaded in a common class loader because of the mess in the jdk (see java.util package) goes against (2). From the requirements document, draft 12:

In support of platform modularization, it must be possible to declare that the types defined in a specific set of modules must be loaded by the same class loader.

But (3) is something that I really do not get. Again, from the requirements document:

Multi-version support should only be enabled when type collisions can be detected and reported as errors. This most likely means that it cannot be enabled for run-time linking since detecting collisions is nontrivial.

Seriously – just one version at runtime? The whole point of versioning and modularization is that we HAVE version collisions, and we are witnessing repackaging of all sorts circumventing our version conflicts. This is why we started using something like OSGi, despite of all the doing, tooling and architectural pain.

If we can have only one version resolved, we aren’t getting any better than with  ivy or maven dependency management and dependency mediation. By the way, the new Big picture is messing around with the terminology we are used to: from maven, spring – and somehow from common sense – we know „scopes“ as where to use the artifacts/ components (runtime, compile-time, test-time, etc.). Then we have different life cycles: maven defines a concise project lifecicle. Every single component model defines its own component life cycle, and regarding modules (at the same level of granularity) we have a bundle life cycle defined by OSGi. In this context, take a look at „Phases“ in the big picture…

Big picture, the phases:

Compile time
Install time
Run time

There is not much to comment here. I just have the strong feeling that this is not enough, too late, to little? The big picture turns out to be a very small one. If you really need modularization today, take a look at the really big pictures drawn by maven, spring, osgi. Even GWT – nothing more than a web framework – does provide its own little module system.

On his blog „there’s not a moment to loose“, Mark described how cool it would be to have a small memory footprint, modularized jdk. That was 2008. Lots of things changed since than.

• dynamic finders
• HQL queries
• Hibernate Criteria Builder

If the database query is very simple, dynamic finders are a good choice. But for everything else, I used Criteria Builder which is just the Hibernate Criteria API with builder syntax.

Starting with Grails 2.0, there is another alternative: Where Queries.
Where Queries are similar to the Criteria Builder approach, but using a nicer „programmer friendly“ syntax and your queries get checked at compile-time (!).
As it uses Detached Criterias under the hood, it should (hopefully) support everything that is possible with Criteria Builder.

Here is an example of a simple Where Query:

def query = Book.where {
   title == "Grails in Action"
}
Book grailsInAction = query.find()

The syntax is more natural for Groovy developers. You don’t need to have the Hibernate Criteria API in mind. Just write your query as if you would deal with a normal collection using Groovy code. Because it uses AST transformations (compile-time metaprogramming), your query gets compile time checked and you will get IDE support / code completion (e.g. using STS). Using Where Queries, you can refactor your domain model and you will almost instantly see whether or not the refactoring breaks existing query logic.

I asked myself if the Where Query approach is as powerful as Criteria Builder. Are there queries that you can’t implement using Where Queries?
And is the generated SQL identical to Criteria Builder’s SQL statements?

I started to expermiment with same common database queries which I wrote both using Criteria Builder and Where Queries:

Multiple restrictions and querying associations

This example shows how to use multiple restrictions in one query and how to query associations. In this case: list all books with a title that contains the word ‘grails’ (case insensitive) and that have an author whose last name starts with an ‘R’ character (again, case insensitive).

// Criteria Builder
Book.createCriteria().list {
	ilike('title', '%grails%')
	authors {
		ilike('lastName', 'r%')
	}
}

// Where Query
Book.findAll {
	title =~ '%grails%' && authors.lastName =~ 'r%'
}

The generated SQL statements are identical for both approaches:

SELECT THIS_.ID AS ID0_1_, THIS_.VERSION AS VERSION0_1_, THIS_.DATE_CREATED AS DATE3_0_1_, THIS_.ERSCHEINUNGSDATUM AS ERSCHEIN4_0_1_, THIS_.ISBN AS ISBN0_1_, THIS_.LAST_UPDATED AS LAST6_0_1_, THIS_.PUBLISHER_ID AS PUBLISHER7_0_1_, THIS_.TITLE AS TITLE0_1_, AUTHORS3_.BOOK_ID AS BOOK1_0_, AUTHORS_AL1_.ID AS AUTHOR2_, AUTHORS_AL1_.ID AS ID3_0_, AUTHORS_AL1_.VERSION AS VERSION3_0_, AUTHORS_AL1_.FIRST_NAME AS FIRST3_3_0_, AUTHORS_AL1_.LAST_NAME AS LAST4_3_0_ FROM BOOK THIS_ INNER JOIN AUTHOR_BOOKS AUTHORS3_ ON THIS_.ID=AUTHORS3_.BOOK_ID INNER JOIN AUTHOR AUTHORS_AL1_ ON AUTHORS3_.AUTHOR_ID=AUTHORS_AL1_.ID WHERE lower(this_.title) like ? and (lower(authors_al1_.last_name) like ?)

Pagination and sorting

This example show how to sort the results of the query and how to limit the result count, starting at a given offset. In this case: list all books with a title containing the word ‘grails’ (case insensitive), limit results to one result, starting at index 1, sorted by property ‘title’ ascending.

// Criteria Builder
Book.createCriteria().list {
	ilike('title', '%grails%')
	maxResults(1)
	firstResult(1)
	order('title', 'asc')
}

// Where Query
Book.findAll(max:1, offset:1, sort:'title', order:'asc'){
	title =~ '%grails%'
}

The generated SQL statements are identical for both approaches:

SELECT THIS_.ID AS ID1_0_, THIS_.VERSION AS VERSION1_0_, THIS_.DATE_CREATED AS DATE3_1_0_, THIS_.ERSCHEINUNGSDATUM AS ERSCHEIN4_1_0_, THIS_.ISBN AS ISBN1_0_, THIS_.LAST_UPDATED AS LAST6_1_0_, THIS_.PUBLISHER_ID AS PUBLISHER7_1_0_, THIS_.TITLE AS TITLE1_0_ FROM BOOK THIS_ WHERE LOWER(THIS_.TITLE) LIKE ? ORDER BY this_.title asc limit ? offset ?

Unfortunately, the sort order of the Where Query (sort:’title’) doesn’t get compile time checked.

Sorting by more than one propery

This example shows how to sort by two properties. In this case: list all books, sorted by title and isbn.

// Criteria Builder
Book.createCriteria().list {
	order('title', 'asc')
	order('isbn', 'asc')
}

// Where Query
def query = Book.where {}.order('title', 'asc').order('isbn', 'asc')
query.list()

The generated SQL statements are identical for both approaches:

SELECT THIS_.ID AS ID3_0_, THIS_.VERSION AS VERSION3_0_, THIS_.DATE_CREATED AS DATE3_3_0_, THIS_.ERSCHEINUNGSDATUM AS ERSCHEIN4_3_0_, THIS_.ISBN AS ISBN3_0_, THIS_.LAST_UPDATED AS LAST6_3_0_, THIS_.PUBLISHER_ID AS PUBLISHER7_3_0_, THIS_.TITLE AS TITLE3_0_ FROM book this_ order by this_.title asc, this_.isbn asc

Although it is possible to use Where Queries here, you have to add the sort order to the query using Criteria API. So: no compile time checks, no IDE support -> no advantage over Criteria Builder approach.

Projections

This example shows how to use restrictions, which means retrieving just some fields and not domain objects. In this case: retrieve just the ‘isbn’ property of all books in the database.

// Criteria Builder
Book.createCriteria().list {
	projections {
		property('isbn')
	}
}

// Where Query
def query = Book.where {}.projections {
	property('isbn')
}
query.list()

Again, it is possible to use Where Queries here, but you have to add the projection to the query using Criteria API. So: no compile time checks, no IDE support -> no advantage over Criteria Builder approach.

Conclusion

Where Queries offer a nicer syntax and – which is imho a really great feature – get compile time checked.
Unfortunately, it lacks some advanced query features like multi sorting or projections. As Where Queries use the Criteria API under the hood, it is possible to do such things by adding them to your query using the Criteria syntax, but you are loosing compile time checks. This hopefully gets fixed with future Grails releases.
Personally, I’m going to use Where Queries whenever possible, falling back to Criteria Builder for queries that are not possible with Where Queries.

[update]
Updated „Sorting by more than one propery“ and „Projections“: it is possible to do such things by combining Where Queries with Criteria API. (thanks to Stephane Maldini)
[/update]

What’s new? 
 
A lot of things; too many to list here. But here is a list of the major improvements done in 4.0:

• Initial multi-tenancy support. See http://in.relation.to/Bloggers/HibernateAndMultitenancyWebinar and http://in.relation.to/Bloggers/MultitenancyInHibernate for more information.
• Introduction of ServiceRegistry. This is a major change in how Hibernate builds and manages services. See the information in the Hibernate Developer Guide. 
• Clean up of Session opening from SessionFactory 
• Improved integration via org.hibernate.integrator.spi.Integrator and auto discovery 
• Improved logging with i18n support and message codes 
• Initial work on more clear split between API, SPI and implementation classes. If you import a class contained in an internal package, you know that this code is not guaranteed to work between releases. 
• Clean up of deprecated methods, classes, etc

Along with the core release, the hibernate search project also updated to the version 4.

The Springframework release 3.1 a few days ago, among many other features, also introduced hibernate 4 support.

After reading the „new and noteworthy“ postings, it gets quite clear that there has been a lot of groundwork been done by all the development teams.

Especially the multi-tenancy support is something to keep an eye on. Here is a nice definition of multi-tenancy  I found on an article about the gae app engine:

Multitenancy is a software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants). With a multitenant architecture, an application can be designed to virtually partition its data and configuration (business logic), and each client organization works with a customized virtual application instance. It suits SaaS (Software as a Service) cloud computing very well; however, they can be very complex to implement.

Anonymous Pro is a family of four fixed-width fonts designed especially with coding in mind. Characters that could be mistaken for one another (O, 0, I, l, 1, etc.) have distinct shapes to make them easier to tell apart in the context of source code.

Anonymous Pro also features an international, Unicode-based character set, with support for most Western and European Latin-based languages, Greek, and Cyrillic.

Anonymous Pro is distributed with the Open Font License (OFL).

It is my default font in eclipse now: