A dirt-ugly hack to modify private final fields in Java

We all use reflection from time to time. We may even tamper with visibility through Java’s Field.setAccessible() and similar methods. But this post here takes things to the extreme and shows how to modify private (static) final fields in Java. Think twice, when choosing this tool šŸ˜‰


Bloated JavaBeansā„¢, Part II – or Don’t Add “Getters” to Your API

I have recently blogged about an idea how JavaBeansā„¢ could be extended to reduce the bloat created by this widely-accepted convention in the Java world.

That article was reblogged on DZone and got quite controversial feedback here (like most ideas that try to get some fresh ideas into the Java world):

I want to revisit one of the thoughts I had in that article, which was given a bit less attention, namely:

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

I’m specifically having trouble understanding why we should use getters all over the place. Getters / setters are a convention to provide abstraction over property access. I.e., you’d typically write silly things like this, all the time:

public class MyBean {
    private int myProperty;

    public int getMyProperty() {
        return myProperty;

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

OK. Let’s accept that this appears to be our everyday life as a Java developer, writing all this bloat, instead of using standard keywords or annotations. I’m talking about standards, not proprietary things like Project Lombok. With facts of life accepted, let’s have a look at java.io.File for more details. To me, this is a good example where JavaBean-o-maniaā„¢ went quite wrong. Why? Check out this source code extract:

public class File {

    // This is the only relevant internal property. It would be "final"
    // if it wasn't set by serialisation magic in readObject()
    private String path;

    // Here are some arbitrary actions that you can perform on this file.
    // Usually, verbs are used as method names for actions. Good:
    public boolean delete();
    public void deleteOnExit();
    public boolean mkdir();
    public boolean renameTo(File dest);

    // Now the fun starts!
    // Here is the obvious "getter" as understood by JavaBeansā„¢
    public String getPath();

    // Here are some additional "getters" that perform some transformation
    // on the underlying property, before returning it
    public String getName();
    public String getParent();
    public File getParentFile();
    public String getPath();

    // But some of these "transformation-getters" use "to", rather than
    // "get". Why "toPath()" but not "toParentFile()"? How to distinguish
    // "toPath()" and "getPath()"?
    public Path toPath();
    public URI toURI();

    // Here are some "getters" that aren't really getters, but retrieve
    // their information from the underlying file
    public long getFreeSpace();
    public long getTotalSpace();
    public long getUsableSpace();

    // But some of the methods qualifying as "not-really-getters" do not
    // feature the "get" action keyword, duh...
    public long lastModified();
    public long length();

    // Now, here's something. "Setters" that don't set properties, but
    // modify the underlying file. A.k.a. "not-really-setters"
    public boolean setLastModified(long time);
    public boolean setReadable(boolean readable);
    public boolean setWritable(boolean writable);

    // Note, of course, that it gets more confusing when you look at what
    // seem to be the "not-really-getters" for the above
    public long lastModified();
    public boolean canRead();
    public boolean canWrite();

Confused? Yes. But we have all ended up doing things this way, one time or another. jOOQ is no different, although, future versions will fix this.

How to improve things

Not all libraries and APIs are flawed in this way. Java has come a long way and has been written by many people with different views on the subject. Besides, Java is extremely backwards-compatible, so I don’t think that the JDK, if written from scratch, would still suffer from “JavaBean-o-maniaā„¢” as much. So here are a couple of rules that could be followed in new APIs, to get things a bit cleaned up:

  1. First off, decide whether your API will mainly be used in a Spring-heavy or JSP/JSF-heavy environment or any other environment that uses JavaBeansā„¢-based expression languages, where you actually WANT to follow the standard convention. In that case, however, STRICTLY follow the convention and don’t name any information-retrieval method like this: “File.length()”. If you’re follwoing this paradigm, ALL of your methods should start with a verb, never with a noun / adjective
  2. The above applies to few libraries, hence you should probably NEVER use “get” if you want to access an object which is not a property. Just use the property name (noun, adjective). This will look much leaner at the call-site, specifically if your library is used in languages like Scala. In that way, “File.length()” was a good choice, just as “Enum.values()”, rather than “File.getLength()” or “Enum.getValues()”.
  3. You should probably ALSO NOT use “get” / “set” if you want to access properties. Java can easily separate the namespace for property / method names. Just use the property name itself in the getter / setter, like this:
    public class MyBean {
        private int myProperty;
        public int myProperty() {
            return myProperty;
        public void myProperty(int myProperty) {
            this.myProperty = myProperty;

    Think about the first rule again, though. If you want to configure your bean with Spring, you may have no choice. But if you don’t need Spring, the above will have these advantages:

    • Your getters, setters, and properties have exactly the same name (and case of the initial letter). Text-searching across the codebase is much easier
    • The getter looks just like the property itself in languages like Scala, where these are equivalent expressions thanks to language syntax sugar: “myBean.myProperty()” and “myBean.myProperty”
    • Getter and setter are right next to each other in lexicographic ordering (e.g. in your IDE’s Outline view). This makes sense as the property itself is more interesting than the non-action of “getting” and “setting”
    • You never have to worry about whether to choose “get” or “is”. Besides, there are a couple of properties, where “get” / “is” are inappropriate anyway, e.g. whenever “has” is involved -> “getHasChildren()” or “isHasChildren()”? Meh, name it “hasChildren()” !! “setHasChildren(true)” ? No, “hasChildren(true)” !!
    • You can follow simple naming rules: Use verbs in imperative form to perform actions. Use nouns, adjectives or verbs in third person form to access objects / properties. This rule already proves that the standard convention is flawed. “get” is an imperative form, whereas “is” is a third person form.
  4. Consider returning “this” in the setter. Some people just like method-chaining:
        public MyBean myProperty(int myProperty) {
            this.myProperty = myProperty;
            return this;
        // The above allows for things like

    Alternatively, return the previous value, e.g:

        public int myProperty(int myProperty) {
            try {
                return this.myProperty;
            finally {
                this.myProperty = myProperty;

    Make up your mind and choose one of the above, keeping things consistent across your API. In most cases, method chaining is less useful than an actual result value.

    Anyway, having “void” as return type is a waste of API scope. Specifically, consider Java 8’s lambda syntax for methods with / without return value (taken from Brian Goetz’s state of the lambda presentations):

    // Aaaah, Callables without curly braces nor semi-colons
    blocks.filter(b -> b.getColor() == BLUE);
    // Yuck! Blocks with curly braces and an extra semi-colon!
    blocks.forEach(b -> { b.setColor(RED); });
    // In other words, following the above rules, you probably
    // prefer to write:
    blocks.filter(b -> b.color() == BLUE)
          .forEach(b -> b.color(RED));

    Thinking about this now might be a decisive advantage of your API over your competition once Java 8 goes live (for those of us who maintain a public API).

  5. Finally, DO use “get” and “set” where you really want to emphasise the semantic of the ACTIONS called “getting” and “setting”. This includes getting and setting objects on types like:
    • Lists
    • Maps
    • References
    • ThreadLocals
    • Futures
    • etc…

    In all of these cases, “getting” and “setting” are actions, not property access. This is why you should use a verb like “get”, “set”, “put” and many others.


Be creative when designing an API. Don’t strictly follow the boring rules imposed by JavaBeansā„¢ and Spring upon an entire industry. More recent JDK APIs and also well-known APIs by Google / Apache make little use of “get” and “set” when accessing objects / properties. Java is a static, type-safe language. Expression languages and configuration by injection are an exception in our every day work. Hence we should optimise our API for those use cases that we deal with the most. Better, if Spring adapt their ways of thinking to nice, lean, beautiful and fun APIs rather than forcing the Java world to bloat their APIs with boring stuff like getters and setters!

Emulating the SQL standard derived column list

Derived column lists are a fine feature, if your database supports them. The SQL:2008 standard specifies

   7.6 <table reference> 

    <table reference> ::= 
        <table factor> 
      | <joined table> 

    <table factor> ::= 
        <table primary> [ <sample clause> ] 

    <table primary> ::= 
        <table or query name> [ [ AS ] <correlation name> 
      [ <left paren> <derived column list> <right paren> ] ] 
      | <derived table> [ AS ] <correlation name> 
      [ <left paren> <derived column list> <right paren> ] 
      | [...] 

When you put this in action in an actual query, the above becomes (in Postgres SQL):

SELECT t.a, t.b
  SELECT 1, 2
) t(a, b)

In words: You can rename a derived table AND its columns in a single step, by supplying a <derived column list> to your <correlation name> (also known as table alias). The main advantage of this syntax is the fact that you only need to know the degree of your derived table, not the concrete (possibly auto-generated) names of its columns. This is particularly useful when renaming columns from an unnested table or from a table or array function:

SELECT t.a, t.b
FROM unnest(my_table_function()) t(a, b)

Emulating derived column lists

Not all databases support <derived column lists> along with a <correlation name>. But you can always emulate them. The simplest way is to use common table expressions. In Oracle, for instance, you could rewrite the above Postgres SQL statement to this:

-- Postgres
SELECT t.a, t.b
  SELECT 1, 2
) t(a, b)

-- Equivalent Oracle query
WITH t(a, b) AS (

-- Or a bit more verbose, if you really want to hide the
-- common table expression within the derived table
SELECT t.a, t.b
  WITH t(a, b) AS (
) t

Note that the CTE solution was given on this Stack Overflow question:

If your database supports neither derived column lists, nor common table expressions, you will have to push down the derived column list into the derived table and transform your nested SQL. In MySQL or H2, the above Postgres query would look like this:

-- MySQL, H2, and others
SELECT t.a, t.b
  SELECT 1 a, 2 b
) t

It looks simple, but of course you’ll have to be able to actually transform your nested select and other sorts of table references

The solution to rule them all

If the latter isn’t an option for you, here’s one that will always work:

-- All databases
SELECT t.a, t.b
  SELECT null a, null b FROM DUAL WHERE 1 = 0
) t

Just concatenate an empty record in front of your actual query, which imposes column names upon your UNION ALL query. Thanks go to Bill’s great answer on Stack Overflow