How to provide a good pull request


A jOOQ user just provided me with an awesome pull request. Check this out:

What’s so nice about this particular pull request:

  • It has a couple of little refactoring steps
  • It contains a little regression test
  • Only at the end, it contains the actual fix

This is really nice. With these many commits, I can easily review the pull request, which makes it easy to decide whether it should make it into the code base or not.

Wikileaks To Leak 5000 Open Source Java Projects With All That Private/Final Bullshit Removed


Hilarious. Not even written on April 1! Taken from here:
http://steve-yegge.blogspot.ch/2010/07/wikileaks-to-leak-5000-open-source-java.html

EYJAFJÖLL, ICELAND — Java programmers around the globe are in a panic today over a Wikileaks press release issued at 8:15am GMT. Wikileaks announced that they will re-release the source code for thousands of Open Source Java projects, making all access modifiers ‘public’ and all classes and members non-‘final’.

JavaBeans™ should be extended to reduce bloat


JavaBeans™ has been around for a long time in the Java world. At some point of time, people realised that the concept of getters and setters was good to provide some abstraction over “object properties”, which should not be accessed directly. A typical “bean” would look like this:

public class MyBean {
    private int myProperty;

    public int getMyProperty() {
        return myProperty;
    }

    public void setMyProperty(int myProperty) {
        this.myProperty = myProperty;
    }
}

In various expression languages and other notations, you could then access “myProperty” using a simple property notation, which is good:

// The below would resolve to myBean.getMyProperty()
myBean.myProperty

// This could resolve to myBean.setMyProperty(5)
myBean.myProperty = 5

Critique on Java properties

Other languages, such as C# even allow to inline such property expressions in regular C# code, in order to call getters and setters. Why not Java?

Getter and Setter naming

Why do I have to use those bloated “get”/”is” and “set” prefixes every time I want to manipulate object properties? Besides, the case of the first letter of the property changes, too. If you want to perform a case-sensitive search on all usage of a property, you will have to write quite a regular expression to do so

Setter returning void

Returning void is one of the biggest reasons Java generates so much bloat at API call sites. Since the early days of Java, method chaining was a wide-spread practice. No one would like to miss StringBuilder’s (or StringBuffer’s) chainable append() methods. They’re very useful. Why doesn’t the Java compiler allow to re-access the property container after calling a setter?

A better Java

In other words, this API:

public interface API {
    void oneMethod();
    void anotherMethod();
    void setX(int x);
    int  getX();
}

Should be usable as such:

API api = ...
int x = api.oneMethod()     // Returning void should in fact "return" api
           .anotherMethod() // Returning void should in fact "return" api
           .x;              // Getter access, if x is not accessible

Let’s make this a JSR!

ElSql, a new external SQL DSL for Java


Stephen Colebourne who is frequently commenting on the lambda-dev and other Java 8 mailing lists, has recently published an idea he has been having for a while: ElSql, a new external SQL DSL for Java.

An example SQL statement is given on the blog posts or on GitHub:

 @NAME(SelectBlogs)
   @PAGING(:paging_offset,:paging_fetch)
     SELECT @INCLUDE(CommonFields)
     FROM blogs
     WHERE id = :id
       @AND(:date)
         date > :date
       @AND(:active)
         active = :active
     ORDER BY title, author
 @NAME(CommonFields)
   title, author, content

As can be seen, this is almost mere string-based SQL, enhanced with some “hooks” for later use in Java. While Stephen’s idea here is to keep it simple (much simpler than jOOQ) it shows some useful applications of allowing to write external DSLs which resemble SQL even more than jOOQ.

DSL authoring support is becoming a more and more interesting topic in various platforms. Eclipse is developing Xtext, Scala is experimenting with even more powerful Macros. While Xtext doesn’t allow to mix the DSL grammar with Java, Scala’s Macros do precisely that. They allow for simple compile-time checked Scala syntax extension, if you have a powerful enough CPU to compile such source code. Where this could go for jOOQ was discussed on this blog before

For more details, read about ElSql on Stephen’s or the OpenGamma blog:

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):

org.springframework.security.web
   .authentication.preauth.websphere
   .WebSpherePreAuthenticatedWebAuthenticationDetailsSource

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>