Wine is a software to allow running Windows applications in Linux, MAC etc. platforms. It is available for installation from package managers like yum (RHEL, CentOS) and apt (Ubuntu). You can find more details on how it works in Wine wiki . But the default Wine package available from package manager does not have support for 32 bit Windows applications. This was the case for me. In Redhat Enterprise Linux 7.3, the wine package did not contain support for 32 bit windows applications. So the only option was to build a separate rpm of wine which will include this support. All the steps are executed on a RHEL 7.3 VM (x86_64). Step 1 Download and run shell script which will make wine 64 and 32 support for RHEL: https://github.com/zma/usefulscripts/blob/master/script/install-wine-i686-centos7.sh It accepts a version no. as CLI parameter e.g. 2.0.3 The script installs wine in /usr/local/ directory by default. We can verify the files that are being copied for wine using "
Few days back I was disturbed with some maven build issues in office. I got back home pretty late. Already, as you can understand, mood was off. I thought of relaxing by watching a good movie but next day I had an interview scheduled. So, I had to brush up my skills a bit (I don't use them often in office :-) ). The first topic I started with was Singleton pattern. This one is so famous among interviewers that you better be able to explain it.
I had read the pattern many a times already. Nothing to prove the book wrong, never occurred to me. But that day, may be due the horrible mood, I challenged the pattern. I thought I'll find ways to break the pattern down. I wanted to create 2 Singleton instances in same JVM. Thats how the attack began.
Below is the code for creating a Singleton class
Here is the code to test the pattern
I have used VisualVM (comes as part of JDK 6) tool to check the no. of instances for Singleton class. You just need to pass a VM argument (-Dcom.sun.management.jmxremote) while running the program.
So, far so good. Only one instance.
Here is the VisualVM output-
I have added a readReasolve() method in the modified Singleton class above. This gets called during de-serialization and the singleton static reference is returned.
Finally, I tried Java reflection (very elegant way indeed). It is so powerful that you can even call private constructors. See how-
Yahooo!!! again success. This time also I was able to create 2 instances of the singleton class. Though by this time I was more oriented to find a solution to this one. Let's see that-
In this solution, I have made the private constructor throw InstantiationException when the static reference is not null (yes, constructors can throw exceptions). Thus it will throw an exception if we call the private constructor 2nd time even if in a reflective way.
Is the last solution thread safe? Frankly speaking, I don't know. This part is yet to be explored. There may be some gotchas here. But I am not feeling wise enough to try it now. May be sometime later.
I had read the pattern many a times already. Nothing to prove the book wrong, never occurred to me. But that day, may be due the horrible mood, I challenged the pattern. I thought I'll find ways to break the pattern down. I wanted to create 2 Singleton instances in same JVM. Thats how the attack began.
Below is the code for creating a Singleton class
Here is the code to test the pattern
I have used VisualVM (comes as part of JDK 6) tool to check the no. of instances for Singleton class. You just need to pass a VM argument (-Dcom.sun.management.jmxremote) while running the program.
So, far so good. Only one instance.
This was rather bookish experiment. I knew it would happen. But still tried to make sure my setup is ok. Though the actual action happens next.
Then I tried serialization of the singleton object. I saved the serialized object to a file. Next, I de-serialized the object from file. Hurray!!! 2 Singleton objects are loaded in JVM. The test class code is-
Here is the VisualVM output-
So, the pattern has been broken. It is not anymore a Singleton. But the question here is, how to prevent this attack. The code goes here -
I have added a readReasolve() method in the modified Singleton class above. This gets called during de-serialization and the singleton static reference is returned.
Finally, I tried Java reflection (very elegant way indeed). It is so powerful that you can even call private constructors. See how-
Yahooo!!! again success. This time also I was able to create 2 instances of the singleton class. Though by this time I was more oriented to find a solution to this one. Let's see that-
In this solution, I have made the private constructor throw InstantiationException when the static reference is not null (yes, constructors can throw exceptions). Thus it will throw an exception if we call the private constructor 2nd time even if in a reflective way.
Is the last solution thread safe? Frankly speaking, I don't know. This part is yet to be explored. There may be some gotchas here. But I am not feeling wise enough to try it now. May be sometime later.
Comments
Post a Comment