You are here: Home » Blog

Implicit default constructors

Posted on Tuesday, December 09 2014 at 08:24 | Category: Java | 0 Comment(s)

As you certainly know, if there is no constructor implemented in a class, the compiler implicitly synthesizes a default constructor. Hence, the following code compiles:

public class ClassA {

    public static void main(String[] args) {
        new ClassA();
    }
}

The disassembled code shows that there is indeed a constructor which essentially calls its super constructor, java.lang.Object.<init>:

$ javap -c ClassA.class
Compiled from "ClassA.java"
public class ClassA {
public ClassA();
    Code:
       0: aload_0
       1: invokespecial #8                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: new           #1                  // class ClassA
       3: invokespecial #16                 // Method "<init>":()V
       6: return
}

Now, there is one detail which even long-time Java developers are not always aware of: if any other constructor overload is added to the class, the compiler will not synthesize a default constructor - hence, the following code does not compile:

public class ClassA {

    public ClassA(int a) { }

    public static void main(String[] args) {
        new ClassA();
    }
}
ClassA.java:7: error: constructor ClassA in class ClassA cannot be applied to given types;
        new ClassA();
        ^
  required: int
  found: no arguments
  reason: actual and formal argument lists differ in length
1 error

This is in accordance to the Java Language Specification: 8.8.9. Default Constructor where it says:

If a class contains no constructor declarations, then a default constructor is implicitly declared.
...

Means, if there are any constructor declarations, then no default constructor will be created by the compiler. Note that there is also the same behavior in C++. Note also that the term "default constructor" as it is used by the language specification only refers to the parameterless constructor created by the compiler - hence, strictly spoken, a parameterless constructor which is explicitly implemented in the class is not a default constructor (even though developers often call it like that).

Normally, this is not an issue, since the compiler will emit the above error when we try to instantiate the class through the default constructor. However, if the object is created dynamically (e.g. through reflection), there will be no compile time error - it will become a runtime error then:

public class ClassA {

    public ClassA(int a) { }

    public static void main(String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException {
        Class clazz = Class.forName("ClassA");
        ClassA obj = (ClassA) clazz.newInstance();
    }
}
Exception in thread "main" java.lang.InstantiationException: ClassA
	at java.lang.Class.newInstance(Unknown Source)
	at ClassA.main(ClassA.java:9)
Caused by: java.lang.NoSuchMethodException: ClassA.<init>()
	at java.lang.Class.getConstructor0(Unknown Source)
	... 2 more
</init>

This can be important when using persistence frameworks which do these kind of things in the background. Other examples are dependency injection frameworks which might complain at the lack of default or empty constructor, if no constructor has the @Inject annotation.


Using Lambdas to implement a function table

Posted on Monday, November 17 2014 at 08:28 | Category: Java | 0 Comment(s)

When I implemented an expression parser for arithmetic expressions (such as t*x+sin(x-5) + π), one part was to create a symbol table to look up constant values such as π, variables such as x and t, but also functions like sin(x). My initial approach had this structure:

 

This allowed me to create a symbol table as a HashMap, and then to add variables, constants or functions into the table:


private Map<String, Symbol> table = new HashMap<>();
...
table.put("sin",  new SinFunction());
table.put("log",  new LogFunction());
...

This works well, but requires a whole new class for each new function, where each of the classes simply provides a getValue() method which delegates to the corresponding static method from Math:

public double getValue(double arg) {
   return Math.sin(arg);
}

Using lambda expressions, the class structure can be much simplified:

Instead of an abstract class Function with specific sub classes which implement the getValue() method, we provide a concrete Function class which delegates to the functional interface DoubleFunction. The instantiation of the Function objects can then be moved into the SymbolTable class, essentially as a convenient method:


public void putSymbol(String name, DoubleFunction<Double> fun) {
   table.put(name, new Function(name, fun));
}

Now, adding new function to the symbol table is straight forward, using a lambda expression:

symbolTable.putSymbol("sin", x -> Math.sin(x));
symbolTable.putSymbol("log", x -> Math.log(x));

Especially we do not need to add another class when adding a new function. The class structure of the symbol table remains stable, all we need is to register the new function through a call to SymbolTable.putSymbol().

Besides simply mapping a function name to a method from the Math class, this works equally well for any user defined function, for example:

symbolTable.putSymbol("f1", x -> x*x + 42*x + 19);
symbolTable.putSymbol("f2", x -> Math.cos(x*x) + 42*x);

Since the Function class holds a reference to the lambda expression through the DoubleFunction interface, we simply call the DoubleFunction.apply() method to evaluate the function for a given x value:

public class Function extends Symbol {

   private DoubleFunction<Double> theFunc;

   ...

   @Override
   public double getValue(double x) {
      return theFunc.apply(x);
   }
}

JCA code sample: encrypting data with AES

Posted on Tuesday, September 09 2014 at 08:58 | Category: Java | 1 Comment(s)

The following code fragments show how a text can be encrypted and decrypted with the JCA (Java Cryptography Architecture) API using the AES cryptographic algorithm.

Lets assume that we have a text which we want to encrypt, and also a key which we want to use for the encryption (remember that AES is a symmetric encryption algorithm, so the same key is used for both encryption and decryption):

String text = "Sample String which we want to encrypt";
String key = "Bar12345Bar12345";

The first thing we need to do is to get the cipher (the cryptographic algorithm) we want to use, and we also need to create a Key which represents our String-based key we defined above so that it can be used in JCA API calls.

Cryptographic algorithms are normally working on binary data, so we also need to get the binary representation of the key first, using an appropriate character set:

Cipher cipher = Cipher.getInstance("AES");
Key aesKey = new SecretKeySpec(key.getBytes(StandardCharsets.ISO_8859_1), "AES");

The Key class has a method getEncoded() which returns the binary representation of the key as a byte[] array. We can use this method do print a hexadecimal dump of the key, and we will get the following output:

0000: 42 61 72 31 32 33 34 35 42 61 72 31 32 33 34 35  Bar12345Bar12345

Note that the key which we created is exactly 16 bytes = 128 bits long. This is the minimum key size supported by AES - and with a default JDK installation, we can not use larger keys. See Using strong encryption in Java for more information how to use larger keys (192 bit and 256 bit).

Next, we also need to get the binary representation of the text we want to encrypt, so that it can be fed into the encryption algorithm:

byte[] plaintext = text.getBytes(StandardCharsets.ISO_8859_1);

The dump of the plaintext data looks like this:

0000: 53 61 6D 70 6C 65 20 53 74 72 69 6E 67 20 77 68  Sample String wh
0010: 69 63 68 20 77 65 20 77 61 6E 74 20 74 6F 20 65  ich we want to e
0020: 6E 63 72 79 70 74                                ncrypt

Now, we can use the Cipher.doFinal() method to encrypt the whole plaintext:

cipher.init(Cipher.ENCRYPT_MODE, aesKey);
byte[] ciphertext = cipher.doFinal(plaintext);

The dump of the ciphertext (which is the encrypted data) looks like this:

0000: 29 0F 31 B5 7E D4 BD 02 69 8E C3 8E 87 C9 8A 4A  ).1µ~Ô½.i?Ã??É?J
0010: 2D C6 FB F9 E8 4E C9 F7 34 61 33 9B 46 27 57 49  -ÆûùèNÉ÷4a3?F'WI
0020: 31 44 53 5B 58 C6 1F 8A 99 A0 F5 18 5C EB 6A 05  1DS[XÆ.?? õ.\ëj.

One thing to mention is that the length of the ciphertext has been extended to a multiple of 128 bits - this is the block size which AES is using.

Now we can use the ciphertext and decrypt it using the original key:

cipher.init(Cipher.DECRYPT_MODE, aesKey);
byte[] decrypted = cipher.doFinal(ciphertext);

The hexadecimal dump of the decrypted array shows that the data has been properly decrypted:

0000: 53 61 6D 70 6C 65 20 53 74 72 69 6E 67 20 77 68  Sample String wh
0010: 69 63 68 20 77 65 20 77 61 6E 74 20 74 6F 20 65  ich we want to e
0020: 6E 63 72 79 70 74                                ncrypt

The complete runnable sample is available at https://github.com/afester/CodeSamples/blob/master/Java/JCE/src/com/example/cipher/AESSample.java (and it is using the hex dump class from https://github.com/afester/CodeSamples/blob/master/Tools/hexdump/src/com/example/hexdump/HexDump.java).


Executables contained in the Java JDK and JRE

Posted on Thursday, July 31 2014 at 15:45 | Category: Java | 1 Comment(s)

New article: Executables within the JDK and JRE.

We certainly know common executables like javac.exe and java.exe - but when looking into the bin directories of a JRE or JDK installation, there are a lot more executables. What is their purpose?

This article lists and briefly describes the various executables which can be found in an Java JRE's or JDK's bin directory. For some of the more interesting tools, screenshots and simple usage examples are also shown. In addition, each tool is linked to its official documentation, as long as it is available.


Displaying results 9 to 12 out of 23