J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource… WAT??

WAT? This hilarious talk about the incredible quirks of JavaScript had been going around on Twitter and other media. In case you haven’t already, take a look at it here: https://www.destroyallsoftware.com/talks/wat Speaking of WAT, let’s talk about Spring Security. Spring has undertaken great effort to replace the clumsy, verbose parts of J2EE to replace them with straightforward and intuitive APIs. In Spring Security, you will find great features like the eraseCredentialsAfterAuthentication property, which keeps you from accidentally letting credentials lie around. Accidentally. What, like printing them to the standard out, or to the HTML document?? If this happens to you accidentally, then you might have a lot of other problems, too. Frameworks helping people to avoid such accidents remind me of PHP and this interesting post about how fundamentally broken PHP is: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ If you’ve ever heard about PHP’s abominable “magic quotes”, you’ll understand what I mean.

More examples

There’s more. Spring has incredibly specialised API types, such as:
  • J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource
  • PreAuthenticatedGrantedAuthoritiesWebAuthenticationDetails
  • PreAuthenticatedGrantedAuthoritiesAuthenticationDetails
  • GrantedAuthorityFromAssertionAttributesUserDetailsService
  • MutableGrantedAuthoritiesContainer
  • MethodSecurityMetadataSourceBeanDefinitionParser
  • AbstractUserDetailsServiceBeanDefinitionParser
Wow. I didn’t know Java identifiers were even allowed to be that long. And there’s more. Consider the package names (line break introduced artificially for improved readability):


Note the repetition of concepts in both package and class names:
  • 2x “web”
  • 4x “authentication” (out of which 2x “pre-authenticated”)
  • 2x “websphere
For all of you who weren’t aware that the class browsing frame in the regular Javadoc frameset has a horizontal scrollbar, I invite you to navigate through the incredible verbosity of Spring Security: http://static.springsource.org/spring-security/site/docs/3.1.x/apidocs/index.html </rant>

jOOQ makes a step forward towards JPA

With the upcoming release 1.6.4 and the implementation of #198, jOOQ will start to better integrate in “standard” J2EE architecture. While jOOQ is being developed as an alternative to JPA, it should not compete with it. This means that there are some parts in JPA which can easily co-exist with jOOQ in a J2EE application: For this purpose, jOOQ will interface the fetching of org.jooq.Result with JPA-annotated entites. This interface can be accessed as of release 1.6.4 in any of these types:

public interface ResultQuery {
    // [...]

    // Fetch results directly into a list of your custom annotated entity
    <E> List<E> fetchInto(Class<? extends E> type) throws SQLException;

public interface Result {
    // [...]

    // Copy existing results into a list of your custom annotated entity
    <E> List<E> into(Class<? extends E> type);

public interface Record {
    // [...]

    // Transform a single record into your custom annotated entity
    <E> E into(Class<? extends E> type);

The above API extension shows how easily JPA-annotated types can be integrated in jOOQ. With any of these methods, you can use jOOQ’s fluent querying API to execute complex queries, and then further process your data using your own POJO‘s, which can be further modified and persisted using your favourite JPA implementation’s EntityManager. But most importantly, your POJO’s will have no dependency on jOOQ anymore, unlike today’s org.jooq.Record. Even better, this will also work with non-annotated types, where jOOQ will try to match Record fields against Class members and methods by a common naming convention. A snapshot preview of version 1.6.4 can be seen on the Sonatype Maven repository: https://oss.sonatype.org/content/repositories/snapshots/org/jooq/