Java Deep

Pure Java, what else

The Little Architect

Uncle Bob published recently an article titled “A Little Architecture“. The article is a conversation between a young developer and a senior (Uncle Bob himself presumably) about being software architect. The article starts with these sentences:

  • I want to become a Software Architect.
  • That’s a fine goal for a young software developer.
  • I want to lead a team and make all the important decisions about databases and frameworks and web-servers and all that stuff.

The next part asks the young developer to list what the important things are. However that is not the only thing that may be interesting in this last sentence. There is another thing, perhaps less technical, that hit me. The young developer says: “make … decisions”.

That may be a mistake. You can interpret it differently what “making decision” means, but let me here tell you my thoughts about that. Some thoughts that were triggered by those two words. First of all here is a story, when I was making some decisions.


Not really many years ago when I was much younger I was acting as system architect and I made a decision on how to store some content. Mainly text and not too large pictures. The obvious choice could be to use database and implement the CRUD operations. A database is always a good solution just as a scarf is always a good gift for Christmas. You love getting a new scarf for every Christmas, don’t you?

On second thought, however the real power of database is when the content is to be searched, indexed and when transactions are executed. They are not really requirements for a media store. On the other hand versioning and user level access control was. I have previously implemented something like that in the past and that time we used SVN for content storage. And that worked fine. So I decided that we should go and use SVN this time also. The project was a success story. A little bit more story than success though. Halfway thriving towards the solution the back-end storage was replaced by a DB layer.

Why didn’t SVN work?

The reason is simple. The developers did not like and understood the decision. They were not familiar with the technology. They used SVN for source code storage but they never used the programming API of it. Instead of using the Java client they forked external svn processes and they were checking out files individually. Displaying a directory containing 20 files was starting 20 processes one after the other. On that system that was approx. 20 seconds.

Okay. It could have been mended in different ways: there was not enough control on the use of the technology and there was a lack of professional code review as well as performance testing due time and so on. The root of the problems though was that I made the decision. I was acting like an omnipotent god, who knows it much better. I was not and I did not.

So what?

I could do it better discussing the solution more with the developers until we all agree on what the solution could have been. I could understand that the DB solution was better or they could understand how the SVN could have been used that way. We could make a decision together. I could make it so that they could make the decision.

A real architect never makes a decision.

A real architect works with the team developing the software asking the right questions making sure that the team make the right decision.

Good architects approve the decision of the team and bear the responsibility. Bad architects make the decisions and blame the team.

Part of it is psychology. If the team makes the decision they are more likely to love the ideas than if they were force fed. They may come up with some ideas that you missed. Good architects recognize that and improve him/herself. Really good architect can even admit at this stage being wrong. On the contrary of what young developers think this increases the esteem. (Unless the architect is wrong more times than not, in which case he/she is not really a good architect.)

Asking the questions also reveal if the team is not prepared for some of the technologies. If they have to learn something new. It may turn out that education is in place or some more familiar technology is to be used. This may also be a smell that you wanted to use some niche technology that may require expensive developers in the coming years to maintain the product. You better don’t!

This does not mean that you should open the floodgates. You still should approve the decision and you should not approve a decision you can not live with. If the team makes a decision on some technology that you feel not good enough it means you have not asked the right questions. You should ask more. The responsibility is your.

I recommend that if you want to be a good architect let the team make the decision and help them forging a good one. Approve it and never blame them. That way they will not leave you in cold water. If you even bring free pizza now and then they may even love you.

Creating proxy object using djcproxy

During the last weeks I have shown how to create a proxy object using Java reflection API and cglib. In this article I will show you how this can be done using djcproxy.

Oh, not again, another proxy implementation!

What is the point to write about this in addition to the selfish fact that I created this proxy? The point is that this is a proxy that is written in Java, it creates Java code that can be examined. It also compiles and loads the created Java classes on the fly so it is also usable but the main advantage is that you can easily get a good insight how a dynamic proxy works. At least a bit easier than digging around the code of cglib, which is creating byte codes directly.

How to use it

You can get the source from github or you can just add the dependency to you project maven pom.


After that you can use the following code:

class A {
  public int method() {
  return 1;
class Interceptor implements MethodInterceptor {

  public Object intercept(Object obj, Method method, Object[] args,
    MethodProxy mproxy) throws Exception {
      if (method.getName().equals("toString")) {
        return "interceptedToString";
      return 0;


    A a = new A();
    ProxyFactory<A> factory = new ProxyFactory<>();
    A s = factory.create(a, new Interceptor());

This code can be found in the tests of the project in GitHub. This is an edited abbreviated version prone to editing errors.

The class ‘A’ is the original class and when we want to create a new proxy object we create a proxy to an already existing object. This is different from reflection or cglib. In case of cglib you create a proxy object and it “contains” the original object. It is not really a containment in OO terms, because the proxy class extends the original class. However because of this extending the proxy object is also an instance of the original class. Cglib does not really care which class instance (object) you want to intercept. You can inject a reference to any object instance to your interceptor if you want. Djcproxy uses a different approach and it does that for you and in your interceptor you will get this object passed as argument. This is why you have to instantiate the object in line 20.

The Interceptor implements the interface MethodInterceptor also provided in the library. It has only one method: intercept, which is invoked when the proxy object method is called. The arguments are

  • obj – the original object
  • method – the method that was invoked in the proxy object
  • args – the arguments that were passed to the method call on the proxy object. Note that primitive arguments will be boxed.
  • mproxy – the method proxy that can be used to call the method on the original object or on just any other object of the same type

This is all about how to use this library. The next thing is to have a look at what is generated so that you can get a better understanding how a proxy works. Insight never hurts, even if you use a different proxy. Many times debugging or just generating better code is easier when you know the principles of a library you use.

While cglib gives you a static factory method to create new objects djcproxy requires that you create a proxy factory. This is on line numbered above 21. If you want to use it the same way as you used cglib you can declare a static ProxyFactory field in the class where you want to use the factory from. On the other hand it is possible to have different factories in different parts of the code. Although the advantage of it is rare, still I believe it is a cleaner approach than providing static factory method.

How does the proxy work?

The extra thing in this package is that it lets you get access to the generated source. You can insert the lines

    String generatedSource = factory.getGeneratedSource();

to print out the generated proxy class which is after some formatting is this:

package com.javax0.djcproxy;

class PROXY$CLASS$A extends com.javax0.djcproxy.ProxyFactoryTest.A implements com.javax0.djcproxy.ProxySetter {
    com.javax0.djcproxy.ProxyFactoryTest.A PROXY$OBJECT = null;
    com.javax0.djcproxy.MethodInterceptor PROXY$INTERCEPTOR = null;

    public void setPROXY$OBJECT(java.lang.Object PROXY$OBJECT) {
        this.PROXY$OBJECT = (com.javax0.djcproxy.ProxyFactoryTest.A) PROXY$OBJECT;


    public void setPROXY$INTERCEPTOR(com.javax0.djcproxy.MethodInterceptor PROXY$INTERCEPTOR) {




    private com.javax0.djcproxy.MethodProxy method_MethodProxyInstance = null;

    public int method() {

        try {
            if (null == method_MethodProxyInstance) {
                method_MethodProxyInstance = new com.javax0.djcproxy.MethodProxy() {
                    public java.lang.Object invoke(java.lang.Object obj, java.lang.Object[] args) throws Throwable {
                        return ((com.javax0.djcproxy.ProxyFactoryTest.A) obj).method();

            return (int) PROXY$INTERCEPTOR.intercept(
                    PROXY$OBJECT, PROXY$OBJECT.getClass().getMethod("method", new Class[]{}),
                    new Object[]{}, method_MethodProxyInstance);
        } catch (Throwable e) {
            throw new RuntimeException(e);


... other overridden methods deleted ...


Note that the class A is a static nested class of ProxyFactoryTest for this generated code.

The interesting code is the overriding of the method method(). (Sorry for the name. I have no fantasy to have a better name for a method that does nothing.) Let’s skip the part where the method checks if there is already a MethodProxy instance and if is missing it creates one. The method method() actually calls the interceptor object that we defined, passing the proxied object, the reflective method object, the arguments and also the method proxy.

What is the method proxy

The name may be confusing first because we already have an “object” proxy. There is a separate method proxy for each method of the original class. These can be used to invoke the original method without reflective call. This speeds up the usage of the proxies. You can also find this call and a similar mechanism in cglib.


The implementation has some flows, for example the late method proxy instantiations have no advantage really but the same time may hurt in case of multi-thread execution of the proxies. It could also be possible to create a proxy object that not only extends a class but also implement arbitrary interfaces (perhaps some that is not even implemented by the extended class). The implementation is used in some other hobby opensource project also available on github about which I may write in the future. They are more demonstrative, educational and proof of concept projects than production code. If you have anything to say on the implementation, the ideas, or just any comments, please reward me with your comments.

Creating a proxy object using cglib

In the previous post I was talking about the standard Java based proxy objects. These can be used when you want to have a method invocation handler on an object that implements an interface. The Java reflection proxy creation demands that you have an object that implements the interface. The object we want to proxy is out of our hand, it does not implement the interface that we want to invoke from our handler and still we want to have a proxy.

When do we need proxy to objects w/o interface?

This is a very common case. If ever we have a JPA implementation e.g. Hibernate that implements lazy loading of the records. For example the audit log records are stored in a table and each record, except the first one has a reference to the previous item. Something like

class LinkedAuditLogRecord {
  LinkedAuditLogRecord previous;
  AuditLogRecord actualRecord;

Loading a record via JPA will return an object LinkedAuditLogRecord which contains the previous record as an object and so on until the first one that probably has null in the field named previos. (This is not an actual code.) Any JPA implementation grabbing and loading the whole table from the start to the record of our interest would be an extremely poor implementation. Instead the persistence layer loads the actual record only and creates a proxy object extending LinkedAuditLogRecord and that is what the field previous is going to be. The actual fields are usually private fields and if ever our code tries to access the previous record the proxy object will load it that time. This is lazy loading in short.

But how do the JPA implementations create proxies to objects of classes that do not implement interfaces? Java reflection proxy implementation can not do that and thus JPA implementation uses something different. What they usually use is cglib.

What is cglib

Cglib is an open source library that capable creating and loading class files in memory during Java run time. To do that it uses Java byte-code generation library ‘asm’, which is a very low level byte code creation tool. I will not dig that deep in this article.

How to use cglib

To create a proxy object using cglib is almost as simple as using the JDK reflection proxy API. I created the same code as the last week article, this time using cglib:

package proxy;

import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;

public class CglibProxyDemo {

    static class Original {
        public void originalMethod(String s) {

    static class Handler implements MethodInterceptor {
        private final Original original;

        public Handler(Original original) {
            this.original = original;

        public Object intercept(Object o, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
            method.invoke(original, args);
            return null;

    public static void main(String[] args){
        Original original = new Original();
        MethodInterceptor handler = new Handler(original);
        Original f = (Original) Enhancer.create(Original.class,handler);

The difference is that name of the classes are a bit different and we do not have an interface.

It is also important that the proxy class extends the original class and thus when the proxy object is created it invokes the constructor of the original class. In case this is resource hungry we may have some issue with that. However this is something that we can not circumvent. If we want to have a proxy object to an already existing class then we should have either an interface or we have to extend the original class, otherwise we just could not use the proxy object in place of the original one.

Java Dynamic Proxy

Proxy is a design pattern. We create and use proxy objects when we want to add or modify some functionality of an already existing class. The proxy object is used instead of the original one. Usually the proxy objects have the same methods as the original one and in Java proxy classes usually extend the original class. The proxy has a handle to the original object and can call the method on that.

This way proxy classes can implement many things in a convenient way:

  • logging when a method starts and stops
  • perform extra checks on arguments
  • mocking the behavior of the original class
  • implement lazy access to costly resources

without modifying the original code of the class. (The above list is not extensive, only examples.)

In practical applications the proxy class does not directly implement the functionality. Following the single responsibility principle the proxy class does only proxying and the actual behavior modification is implemented in handlers. When the proxy object is invoked instead of the original object the proxy decides if it has to invoke the original method or some handler. The handler may do its task and may also call the original method.

Even though the proxy pattern does not only apply into situation when the proxy object and proxy cass is created during run-time, this is an especially interesting topic in Java. In this article I will focus on these proxies.

This is an advanced topic because it requires the use of the reflection class, or byte code manipulation or compiling Java code generated dynamically. Or all of these. To have a new class not available as a byte code yet during run-time will need the generation of the byte code, and a class loader that loads the byte code. To create the byte code you can use cglib or bytebuddy or the built in Java compiler.

When we think about the proxy classes and the handlers they invoke we can understand why the separation of responsibilities in this case is important. The proxy class is generated during run-time, but the handler invoked by the proxy class can be coded in the normal source code and compiled along the code of the whole program (compile time).

The easiest way to do this is to use the java.lang.reflect.Proxy class, which is part of the JDK. That class can create a proxy class or directly an instance of it. The use of the Java built-in proxy is easy. All you need to do is implement a java.lang.InvocationHandler so that the proxy object can invoke that. InvocationHandler interface is extremely simple. It contains only one method: invoke(). When invoke() is invoked the arguments contain the original object, which is proxied, the method that was invoked (as a reflection Method object) and the object array of the original arguments. A sample code demonstrate the use:

package proxy;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

public class JdkProxyDemo {

    interface If {
        void originalMethod(String s);

    static class Original implements If {
        public void originalMethod(String s) {

    static class Handler implements InvocationHandler {
        private final If original;

        public Handler(If original) {
            this.original = original;

        public Object invoke(Object proxy, Method method, Object[] args)
                throws IllegalAccessException, IllegalArgumentException,
                InvocationTargetException {
            method.invoke(original, args);
            return null;

    public static void main(String[] args){
        Original original = new Original();
        Handler handler = new Handler(original);
        If f = (If) Proxy.newProxyInstance(If.class.getClassLoader(),
                new Class[] { If.class },


If the handler wants to invoke the original method on the original object it has to have access it. This is not provided by the Java proxy implementation. You have to pass this argument to the handler instance yourself in your code. (Note that there is an object usually named proxy passed as an argument to the invocation handler. This is the proxy object that the Java reflection dynamically generate and not the object we want to proxy.) This way you are absolutely free to use a separate handler object for each original class or use some shared object that happens to know some way which original object to invoke if there is any method to invoke at all.

As a special case you can create an invocation handler and a proxy of an interface that does not have any original object. Even more it is not needed to have any class to implement the interface in the source code. The dynamically created proxy class will implement the interface.

What should you do if the class you want to proxy does not implement an interface? In that case you have to use some other proxy implementation. We will look at about that next week.

Value types in Java: why should they be immutable?

Value types need not be immutable. But they are.

In the previous post I discussed the difference between pointers and references in Java and how the method parameters are passed (passed-by-value or passed-by-reference). These are strongly related to value types that do not exist in Java (yet).

There is a proposal from John Rose, Brian Goetz, and Guy Steele detailing how value types will/may work in Java and also there are some good articles about it. I have read “Value Types: Revamping Java’s Type System” that I liked a lot and I recommend to read. If the proposal is too dense for you to follow the topic you can read that article first. It summarizes very much the background, what value types are, advantages, why it is a problem that Java does not implement value types and why it is not trivial. Even though the terminology “value type” may also be used to denote something different I will use it as it is used in the proposal and in the article.

How do we pass arguments vs. what do we store in variables

As you may recall from the previous article I detailed that Java passes method arguments by reference or by value depending on the type of the argument:

  • reference is passed when the argument is an object
  • by-value when the argument is primitive.

There are some comments on the original post and also on the JCG republish that complain about my terminology about passing an argument by-reference. The comments state that arguments are always passed by value because the variables already contain reference to the objects. In reality variables, however contain bits. Even though this is important to know how we imagine those bits, and what terminology we use when we communicate. We can either say that

  1. class variables contain objects and in that case we pass these objects to methods by-reference
  2. or we can say that the variables contain the reference and in that case we pass the value of the variables.

If we follow the thinking #1 then the argument passing is by-value and/or by-reference based on the actual nature of the argument (object or primitive). If we follow the thinking #2 then the variables store reference and/or values based on the nature of their type. I personally like to think that when I write

Triangle triangle;

then the variable triangle is a triangle and not a reference to a triangle. But it does not really matter what it is in my brain. In either of the cases #1 or #2 there is a different approach for class types and for primitives. If we introduce value types to the language the difference becomes more prevalent and important to understand.

Value types are immutable

I explained that the implicit argument passing based on type does not cause any issue because primitives are immutable and therefore, when passed as method argument, they could not be changed even if they were passed by reference. So we usually do not care. Value types are not different. Value types are also immutable because they are values and values do not change. For example the value of PI is 3.145926… and it never changes.

However, what does this immutability mean in programming? Values be real numbers, integers or compound value types are all represented in memory as bits. Bits in memory (unless memory is ROM) can be changed.

In case of an object immutability is fairly simple. There is an object somewhere in the universe that we can not alter. There can be numerous variables holding the object (having a reference to it) and the code can rely on the fact that the bits at the memory location where the actual value of the object is represented are not changed (more or less).

In case of value types this is a bit different and this difference comes from the different interpretation of the bits that represent a value type from the same bits when they may represent an object.

Value types have no identity

Value types do not have identity. You can not have two int variables holding the value 3 and distinguish one from the other. They hold the same value. This is the same when the type is more complex.

Say I have a value type that has two fields, like

ValueType TwoFields {
  int count;
  double size;

and say I have two variables

 Twofields tF1 = new TwoFields(1,3.14)
 Twofields tF2 = new TwoFields(1,3.14)

I can not tell the variables tF1 and tF2 from other. If they were objects they would be equals to each other but not == to each other. In case of value types there is not == as they have no identity.

If TwoFields is immutable class I can not or should not write

 TwoFields tF;

or some similar construct. But I still can write

 TwoFields tF;
 tF = new TwoFields(tF.count+1, tF.size)

which leaves the original object intact. If TwoFields is a value type then either of the constructs, whichever is allowed, will create a new value.

Value types as arguments

How are value types passed as method argument then? Probably copying the value to the parameter variable. Possibly passing some reference. It is, however, up to the compiler (be it Java, or some other language). Why?

  • Value types are usually small. At least they should be small. A huge value type looses the advantages that value types deliver but have the disadvantages.
  • Value types are immutable so there is no problem copying them just like in case of primitives. They can be passed by value the same way as “everything in Java is passed by value”.
  • They have no identity, there can be no references to them.

But this is not only about passing them as arguments. This is also how variables are assigned. Look at the code

 Twofields tF1 = new TwoFields(1,3.14)
 Twofields tF2 = new TwoFields(1,3.14)

and compare it to

 Twofields tF1 = new TwoFields(1,3.14)
 Twofields tF2 = tF1

If TwoFields is a value type there should be no difference between the two versions. They have to produce the same result (though may not through the same code when compiled). In this respect there is no real difference between argument passing and variable assignment. Values are copied even if the actual variables as bits contain some references to some memory locations where the values are stored.


As I started the article: value types need not be immutable. This is not something that the language designers decide. They are free to implement something that is mutable, but in that case it will not be value type. Value types are immutable.

Pointers in Java

Are there pointers in Java? The short answer is “no, there are none” and this seems to be obvious for many developers. But why is it not that obvious for others?

That is because the references that Java uses to access objects are very similar to pointers. If you have experience with C programming before Java it may be easier to think about the values that are stored in the variables as pointers that point to some memory locations holding the objects. And it is more or less ok. More less than more but that is what we will look at now.

Difference between reference and pointer

As Brian Agnew summarized on stackoverflow there are two major differences.

  1. There is no pointer arithmetic
  2. References do not “point” to a memory location

Missing pointer arithmetic

When you have an array of a struct in C the memory allocated for the array contains the content of the structures one after the other. If you have something like

struct circle {
   double radius;
   double x,y;
struct circle circles[6];

it will occupy 6*3*sizeof(double) bytes in memory (that is usually 144 bytes on 64 bit architecture) in a continuous area. If you have something similar in Java, you need a class (until we get to Java 10 or later):

class Circle {
   double radius;
   double x,y;

and the array

Circle circles[6];

will need 6 references (48 bytes or so) and also 6 objects (unless some of them are null) each 24bytes data (or so) and object header (16bytes). That totals to 288bytes on a 64bit architecture and the memory area is not continuous.

When you access an element, say circles[n] of the C language array the code uses pointer arithmetic. It uses the address stored in the pointer circles adds n times sizeof(struct circle) (bytes) and that is where the data is.

The Java approach is a bit different. It looks at the object circles, which is an array, calculates the n-th element (this is similar to C) and fetches the reference data stored there. After the reference data is at hand it uses that to access the object from some different memory location where the reference data leads.

Note that in this case the memory overhead of Java is 100% and also the number of memory reads is 2 instead of 1 to access the actual data.

References do not point to memory

Java references are not pointer. They contain some kind of pointer data or something because that comes from the nature of today computer architecture but this is totally up to the JVM implementation what it stores in a reference value and how it accesses the object it refers to. It could be absolutely ok though not too effective implementation to have a huge array of pointers each pointing to an object of the JVM and the references be indices to this array.

In reality JVM implement the references as a kind of pointer mix, where some of the bits are flags and some of the bits are “pointing” to some memory location relative to some area.

Why do JVMs do that instead of pointers?

The reason is the garbage collection. To implement an effective garbage collection and to avoid the fragmentation of the memory the JVM regularly moves the objects around in the memory. When memory occupied by objects not referenced anymore are freed and we happen to have a small object still used and referenced in the middle of a huge memory block available we do not want that memory block to be split. Instead the JVM moves the object to a different memory area and updates all the references to that object to keep track of the new location. Some GC implementations stop the other Java threads for the time these updates happen, so that no Java code uses a reference not updated but objects moved. Other GC implementations integrate with the underlying OS virtual memory management to cause page fault when such an access occurs to avoid the stopping of the application threads.

However the thing is that references are NOT pointers and it is the responsibility of the implementation of the JVM how it manages all these situations.

The next topic strongly related to this area is parameter passing.

Are parameters passed by value or passed by reference in Java?

The first programming language I studied at the uni was PASCAL invented by Niklaus Wirth. In this language the procedure and function arguments can be passed by value or by reference. When a parameter was passed by reference then the declaration of the argument in the procedure or function head was preceded by the keyword VAR. At the place of the use of the function the programmer is not allowed to write an expression as the actual argument. You have to use a variable and any change to the argument in the function (procedure) will have effect on the variable passed as argument.

When you program in language C you always pass a value. But this is actually a lie, because you may pass the value of a pointer that points to a variable that the function can modify. That is when you write things like char *s as an argument and then the function can alter the character pointed by s or a whole string if it uses pointer arithmetic.

In PASCAL the declaration of pass-by-value OR pass-by-reference is at the declaration of the function (or procedure). In C you explicitly have to write an expression like &s to pass the pointer to the variable s so that the caller can modify it. Of course the function also has to be declared to work with a pointer to a whatever type s has.

When you read PASCAL code you can not tell at the place of the actual function call if the argument is passed-by-value and thus may be modified by the function. In case of C you have to code it at both of the places and whenever you see that the argument value &s is passed you can be sure that the function is capable modifying the value of s.

What is it then with Java? You may program Java for years and may not face the issue or have a thought about it. Java solves the issue automatically? Or just gives a solution that is so simple that the dual pass-by-value/reference approach does not exist?

The sad truth is that Java is actually hides the problem, does not solve it. So long as long we work only with objects Java passes by reference. Whatever expression you write to the actual function call when the result is an object a reference to the object is passed to the method. If the expression is a variable then the reference contained by the variable (which is the value of the variable, so this is a kind of pass-by-value) is passed.

When you pass a primitive (int, boolean etc) then the argument is passed by value. If the expression evaluated results a primitive then it is passed by value. If the expression is a variable then the primitive value contained by the variable is passed. That way we can say looking at the three example languages that

  • PASCAL declares how to pass arguments
  • C calculates the actual value where it is passed
  • Java decides based on the type of the argument

Java, in my opinion, is a bit messy. But I did not realized it because this messiness is limited and is hidden well by the fact that the boxed versions of the primitives are immutable. Why would you care the underlying mechanism of argument passing if the value can not be modified anyway. If it is passed by value: it is OK. If it passed by reference, it is still okay because the object is immutable.

Would it cause problem if the boxed primitive values were mutable? We will see if and when we will have value types in Java.

Constructors, superconstructors and Swift

Recently I was looking at the language tutorial of Swift. It is totally different from Java. It resembles more to C++ in its structure. It is compiled code, no VM, no garbage collection (it uses reference counting that is more like C++ smart pointers). At the same time it is a modern language that tries to get all the good constructs from other languages. Some part of the tutorial is easy to read when the construct is similar to Java. In that case terminology and the way the language designer was thinking is the same as in Java that I know well. In other cases the approach is totally different. In that case it is harder to understand the language construct but the same time there is some intellectual reward.

One such aspect is class constructor. It has lots of similarities to Java constructors. The functionality of the constructor is the same as in Java: it has to initialize the object. Fields have to be initialized almost the same way as in Java. Though Java allows you to have non-final fields to keep some default value (zero or null), Swift requires that all fields are initialized or have explicit default values. Some way I can understand that restriction: Swift tries to get rid off the one million dollar mistake, the null value. (It calls it nil, and has build-in optional value handling.)

The interesting thing is how superclasses are initialized. In Java the super constructor has to be invoked by the constructor before any other code is executed. There is a good reason for it. The class inherits fields from the super class and before executing the super constructor the part of the object that belongs to the super class is not properly initialized. Initializer blocks make it even more complex, but the essence is the same.
Source Code showing syntax error calling super constructor too late

Swift on the other hand allows you to call the super constructor any time from the child constructor. You may think that Swift in this sense is not so restrictive. But it is a modern language and avoids all messy constructs, like uninitialized variables, half initialized objects or even implicite null values in variables. Knowing that I could soon realize reading the tutorial that Swift is not less restrictive. It has more complex rules.

Swift defines a two phase initialization process. It does not require that the very first thing an initializer does is invoking the super constructor, but it does not allow the initializer to do much before doing so. Very specifically the constructor can not access any of the fields in the first phase.
The only extra functionality is that this way the constructor can use the constructor arguments to decide which super constructor to invoke. This is not possible in Java.

These are the facts. The rest is subjective.

Should I miss this possibility in Java? Several years of experience show that we can program with the restrictions of Java successfully and I have never felt the lack of this feature as a huge burden.

At the same time I feel that Swift’s more complex rules may be confusing and complex to learn and get experience with for a novice programmer.

But neither languages are for novice programmers, and also I got used to the restrictions of Java I live with. If you, as a programmer, get too much freedom from a programming language you also get the numerous possibilities to create bad code. Restrictions are good. Freedom is slavery. Or not? This may lead too far.

Do Not Create DSL for the Customer

Domain Specific Language (DSL) solutions are many times created with the intent to give a tool to the hands of the customer representatives (business people) to do the configuration of the application on their own. Most of these attempts fail miserably: the DSL ends in the hands of the developers. (Sometimes there can be exceptions those I have never experienced.) Why can’t business people use DSL?

That is because

customers are stupid.

After all this is the rule number one when you are working in a support organization on L1 level. And it will never change. So long as long “never” means the time until you are the customer in a situation. In that case

the customer is always right.

Right? Although it may seem funny, stupid or exagarating both of these ideas have some background and can be true to some limit no matter how contradicting they are.

The harsh and offending formulation “customers are stupid” comes from the fact that customers are not expert in your area. If you are a mechanic your customers do not know about the injectors and the valve settings. They just want the car running from A to B. If you are plumber your customers just want to have a shower and drink fresh water but they are not really interested nor knowledgable about fittings. If you are electrician your customers just want light and wiring is an unavoidable nuisance.

Customers are not stupid. They just see the world from a different angle and they do not know your profession. And this is very good, otherwise you would be jobless.

On the other side of the scale customers are not entirely right all the times. It is just the fact that they have the money you want to work for and if they are not satisfied they will not pay.

Customers pay for the value they get and not for the work you do.

Generally: you have to find a job where you can create great value with minimal work. Some people are good at it some are not that good.

You can fix their cars but it has to be a value for them. If you just refill the water in the screenwash: that is not a huge value as compared to the effort. They could do it themselves and actually today they do. Likewise if you are a plumber your service is not requested each time the client wants the water to run. Similarly there is no need for an electrician to switch the light on and off.

This is the idea of DSL. A switch on the wall is a DSL. Does it work?

Why do most of the DSL projects fail then?

What I see is that most of these project implement first the switch on the wall and the outlet to plug in the TV, washing machine and so on but then they start to go on and try to invent other tools that would support the reorganization of the wiring. Someting like a cross connection table at the electric center of the house where the customer can plug in wires to have 12V direct current in some of the outlets, 120V alternating current in other outlets and 220V in the guest room when visitors come from Europe.

I hope you get the point: DSL solutions become just too complex for the customers. First it starts off with a simple text file. Later on it is an Excell table. Then a whole buch of sheets with many columns. Even later somehow scripts emerge that help the editing and the conistency maintenance of the data. And it all supposed to be maintained by the customer.

The house will burn down! Call the firebrigade!

And you do call the firebrigade and you realize that you, as a programmer do nothing but edit XLS files and maintain scripts that edit XLS files and fix bugs that were introduced by the customer. To avoid that you invent new XLS files that the customers fills in and that the developers use as a definition manually entering, copy pasting data to the XLS that controls the application. (Btw: Excell could be anything else, some other tool, but it is just the fact of life: it is Excell.)

You wanted to focus on more advanced programming tasks and offload the everyday burden of configuration and you ended up editing XLS 10 hours a day. You made the right choice, didn’t?

So what is the right way to do it? Are DSLs doomed and should not be created?

The fact is that you can create DSL for the customer but they have to be as simple as a light switch or a tap. You can build DSL that is more complex but do not expect a customer to use it. Layer the tasks, and separate who can do what so that everybody is working on tasks where he/she can have the most added value.

Yes, this is a simple advice that is hard to execute. But we can try.

Can you call non-static method from a static?

There are questions on a Java technical interview that even the most entry level junior is expected to give the right answer for. Since I am facing candidates who are not that junior I do not even bother most of the times to ask those questions. I assume that the candidate knows the correct answer. Some time however there are some candidates who I feel from the start they are juniors and to cut the interview short not wasting his/her and my time I ask some of those simple questions. The answers usually reveals the real level of knowledge and we can get to an agreement in short time about the assessed level.

Sometimes I also meet candidates who not only simply do not know the answer but give wrong answer. To know something wrong is worse than not knowing. Out of these very few even insists and tries to explain how I should have interpreted their answer. That is already a personality problem and definitely a no-go in an interview.

One such simple question is:

Can a static method in a class call a non-static method of the same class?

If you know Java a little bit you know the answer: no, it can not. A static method belongs to the class and not the instance. It can even be executed using the name of the class directly without any instance of the class. It can even run when there is not even a single instance of the class in the whole JVM. How could it invoke a normal method that runs attached to an instance?

But then again: the answer from one candidate this time was: yes. And he even started to explain that it may happen that the static method has access to an instance. It may get an instance as a method argument and through that reference it can call an instance method. That person was right. It did not, however, mended the fact that he did not know Java good enough, but as a matter of fact in this very specific question she was right.

What is the morale of the story? You tell.

Do we need coding conventions?

There are things that just come natural and we forget to wonder if it could be some other way. It is like that the sun rise morning and sets evening. But scientists raise the question and even though the sun still rise in the morning and still sets evening we gathered a lot of knowledge about it. It is similar to every profession. We do thing, follow procedures and do not ask the question: why? Should we?

In some cases we follow some procedure because that is the way we always did. We write program codes in lines, because that was the only way to record code in RPG that was created for Hollerith cards. You do not even know what a Hollerith card is but you still write code lines in an editor and still many times the suggested maximal line length is 72 characters. Should we write code into 72 character length lines? No, obviously. Many times we do not. Modern editors and screens make it more feasible to have longer lines. Still there is a maximum length that makes the code more readable. Integrated development environments, like Eclipse wrap too long lines if we ask them. Nobody questions it. What people question is the actual length of the line. Should be 80 character, 130 or 125 or something else? One thing is certain: when coding in a team there should be only one decided and agreed limit. The sad thing is that setting a coding standard sometimes is a good ground and source for dissension.

From my practice the most important Java coding question (as far as temperature of debates shows) before starting a project is:

“Should there be a space between the keyword ‘if’ and the opening parenthesis?”

You may laugh, but just look at the following two sample code segments:

  if( debugIsSwitchedOn )log.debug("Here we go");


  if ( debugIsSwitchedOn )log.debug("Here we go");

Now you can understand that answering this question and having a consensus on that may make a project success or fail. The proper selection between waterfall and agile methodology is a matter of free choice and does not really effect the outcome of the project as much as this question. At least if I measure importance based on the effort put into the debate usually.

Now you think that I am kidding. Some way yes, but lets have a look at from another angle:

If having or not having a space between the keyword ‘if’ and the opening parenthesis is not important then why do people invest so much emotion and effort discussing it?

It seems that such nuances are important for the developers. And what is important for the developers is important for the project. Unhappy developers do not deliver successful project.

This is not a hard coded area, like performance of reflection or thread local usage in Tomcat that you can try, test, measure and have a final word. This is more psychology that I am not an expert in, but still I have my experience in coding and I have my ideas about the question I set forth. After all having a discussion about a topic we are not expert in is at least such a good ground for a dispute as something that is more religious than fact based, like the space between the ‘if’ and ‘(‘.

Code is owned by the developer

Today agile methodology says that the code belongs to the group. Anyone can fix any part of the code. In old times it was not the case. We did not stick to such “expensive” and strict rules. Developers were lone wolfs and were responsible for their own code. Sharing the code has its cost involving the other members to learn the code somebody else from the group developed. In the long run it is cheaper when you consider the maintenance cost of the code starting even before the first release during debugging sessions. Even though sharing the code is not the human nature. Developers in the deep soul are still lone wolfs and honestly when I code I am alone. I am in a kind of flow state many times realizing that last ten minutes I spent with coding was actually more than an hour. Having enough experience I am not reluctant to share the code with others, explain if needed what and why is there. (Btw: need for extensive explanation is already a code smell unless the other side is junior, in which case the explanation is more kind of education.)

This means that in the deep heart we still own the code. Each and every member of the developer team should feel owning the code to be effective when she has to fix a bug, extend a feature. And the feeling is greatly affected by small nuances, like how we usually format the code. I open the source code in my IDE, I see the code using the coloring and the font face I set (that already makes it a bit cosy) and try to understand the code. If the coding convention is totally different from my code: it is a distraction. Up to some level I can convince myself not to pay attention to the fact the the opening braces are on the next line, like we do when we program C# but it is an annoyment when we code in Java. That is not the way we usually do it. Eclipse, IntelliJ or even some vi macro helps to reformat, but then we waste time when comparing the pull request in GitHub: there will be a lot of changes most of it formatting. We loose the information in the noise.

If the group has coding convention the code will look more like mine even if developed by some fellow programmer. I will look at it, I will understand it easier. You should not underestimate the effect of that.

The actual coding convention is not important

It is more important that the group has one (and only one). To have it settled during the start of the project is a good topic to increase group cohesion. Even if the discussion goes into a wrong direction and the final decision is not optimal, what can you loose? A space between the keyword ‘if’ and ‘(‘? People, especially when a group is recently formed has to forge itself and forging is usually at high temperature. It has to be like that and what can be a better topic where flames make no real harm?


Get every new post delivered to your Inbox.

Join 1,105 other followers