In Scala compiling, how to tell type checker to show us the added "given" it finds

More here

Find the max-diff value in a List with the difference is from the values on the right vs. the value on the left in the List

A simple example for Scala 3 type class derivation:

Setup environment to use key size greater than 128 bits in JCE

When you are using Oracle default JCE provider or BouncyCastle provider, if you only use key size 64 or 128 bits, for BouncyCastle, you need to call:

Security.addProvider( new BouncyCastleProvider() );

for Oracle JCE provider, you don't need to add anything specifically.

Then you may call for example:

// This use the default ECB mode, and PKCS7Padding

Cipher cipher = Cipher.getInstance("AES", "BC");

So, it will the same as

Cipher cipher = Cipher.getInstance("AES/ECB/PKCS7Padding", "BC" );

**** Note:

ECB has a problem to encrypt data, the cipher text shows the same pattern as the plain text, For example:

545454541234567854545454123443215454545412345678 2A8733982F64E6B35873778337192DA3931AE70A734C58761BC2A82498A133CC2A8733982F64E6B35873778337192DA33FE7286ABDE5F03943D5777020259626

More Details are here

The normal JDK download ships with a set of policy files that places certain restrictions on the key sizes that can be used. Key sizes are limited in general to 128 bits (except for the symmetric cipher Triple-DES) and RSA key generation is limited to 2,048 bits.

But if you want to use the key size greater than 128 bits, you have to download the unrestricted policy files, for Java 6, they are here:

After you unzip them you will get two JAR files:

Backup your existing files under the following location: $JAVA_HOME/lib/security

and then put the unzipped two files in this directory, now you could use the keys with size greater than 128.

If you don't do this, you will get the following exception:

Exception in thread "main" java.security.InvalidKeyException: Illegal key size or default parameters

at javax.crypto.Cipher.a(DashoA13*..) at javax.crypto.Cipher.init(DashoA13*..) at javax.crypto.Cipher.init(DashoA13*..) at com.security.cert.security.symmtric.SimpleSymmetricExample.encrypt(SimpleSymmetricExample.java:37) at com.security.cert.security.symmtric.SimpleSymmetricExample.main(SimpleSymmetricExample.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597)

Posted via email from Progress

Using Java SignalHandling and ShutDownHook

• Singal Handling

Here I only briefly talk about the the Java Signal handling under Unix/Linux using Sun's implementation; In Sun's implementation, there is an interface SingleHandler and a Single class, they are located in rt.jar file,for every signal you want to capure, you need create a corresponding instance for it, and then register it into the Singal's handlers:

1. Singal signal = new Signal( TERM );

2. YourSignalHandler youHandler = new YourSignalHandler();

3. Singal.handle( singal, youHandler);

Then your handler is ready to handle signals, you may use kill -TERM processId to send signal to your signal handler.

When you use singal handling with JVM, you need consider some signals have already been listened by the JVM, and signals can only be handled by one handler, if you want to handle it, you must tell JVM to ignore it using -Xrs option when you bring up the JVM( Sun JVM)

• Shudown hook

Sometime, you want to do some cleanup when your application is shuting down, for example, shutdown your thread pool, close your connection pool and close files gracefully.

1. Shutdown hook is a class which extends Thread class, and can be installed using Runtime.getRuntime().addShutdownHook() or removed using Runtime.getRuntime().removeShutdownHook()

2. Each shudown hook will be started when the JVM terminating, and they are running simultaneously, so synchronization should be considered if ncessary.

3. Shudown hook will be invoked under the following scenarios:

• Application normal exits, for example, calling System.exit(0), Runtime.exit(), or the last non-deamon thread exits
• JVM is terminated by some signals, such as SIGTERM, SIGHUP, etc.

4. Shutdown hook will not be invoked when:

• JVM Crash
• Runtime.halt() is called.
• JVM -Xrs option is specified when bring up the JVM

In my previous post, I have talked about how to break the blocking I/O, especailly about how to gracefully shutdown the listener, now we know we could put the serverSocket.close() into a shudown hook, and then user sends a SIGTERM signal to the JVM, the JVM will be terminated and invoke the shudown hook to close the server socket. When the shutdown hook(s) are executed, the JVM will wait until all shutdown hooks finish their job, so you must make sure all of your shutdown hook finish their jobs properly, otherwise the JVM will hung.

For more detailed information about shutdown hook and signal handling, please refer to :

Revelations on Java signal handling and termination

 

Posted via email from Progress

A few simple ways to break your blocking I/O operatio

Tranditional blocking I/O is not like Thread.sleep(), Object.wait(), Thread.join(), etc, it cannot interrupted by the Thread.interrupt() method, but the others list above could be interrupted and you will get InterruptedException.

In blocking I/O, such as ServerSocket.accept(), if no more connect requests coming, it will be blocked maybe for ever. If you create a listern listening on a port, but you want to shutdown it gracefully, you may choose the following ways to do that:

1. Create a client socket and call connect() to this listener's port:

        Socket client = new Socket();
        try {
            client.connect(new InetSocketAddress(this.IP, this.port));
            client.close();
        } catch (IOException e) {
            e.printStackTrace();
        }

    This will make the ServerSocket.accept() break, and make the thread proceeds.

2. Keep a reference( i.e serverSocket) to the ServerSocket you created in the listener, later when you want to shutdown the listener, just call serverSocket.close(), this also break the ServerSocket.accept().

3. The third way is not so graceful, but if you don't care about what is runing, it works, just uses kill -9 to kill the process.

Posted via email from Progress

How to use ClassLoader correctly

A few articles talk about ClassLoader, they are very helpful to understand how classes or resources are loaded.

1. ClassLoaders and J2EE

2. Find a way out of the ClassLoader maze

System, current, context? Which ClassLoader should you use?

Posted via email from Progress