Litany of errors strike after manually updating


So, after I manually updated the JDK to release 19, as I wrote in this post, a series of errors strike me. First, I was unable to run my applet. It threw ExceptionInInitializer error. Then I had to revert to using JRE 16, as I wrote in this post. OK, running applet was resolved. But then, another error occurred. This time it happened when I built my project in Eclipse. I encountered KeyStoreException error when I tried to sign my applet. I then remember that I was still using the JRE 19 vm when invoking the Eclipse. OK, so I changed the run.sh of Eclipse to use JRE 16. I still could not sign my applet. So what went wrong? It turned out that I did not have JDK to go with JRE 19... or... something to that effect. So I looked around and stumbled upon this site, explaining how to update your JDK and JRE. This is a very simple process, compared to when I did it manually.

To install proprietary Java, you must have the Multiverse repository enabled. Click on System > Administration > Software Source > Select Multisource > Close







Open a shell prompt (terminal) and type the following to install JDK and JRE:
$ sudo apt-get install sun-java6-bin sun-java6-jre sun-java6-jdk
Setup the default Java version

Ubuntu Linux comes with update-java-alternatives utility to updates all alternatives belonging to one runtime or development kit for the Java language. To select, Sun's JVM as provided in Ubuntu 7.10, enter:
$ sudo update-java-alternatives -s java-6-sun
You also need to edit a file called /etc/jvm. This file defines the default system JVM search order. Each JVM should list their JAVA_HOME compatible directory in this file. The default system JVM is the first one available from top to bottom. Open /etc/jvm
$ sudo vi /etc/jvm
Make sure /usr/lib/jvm/java-6-sun is added to the top of JVM list
/usr/lib/jvm/java-6-sun
At the end your file should read as follows:
/usr/lib/jvm/java-6-sun
/usr/lib/jvm/java-gcj
/usr/lib/jvm/ia32-java-1.5.0-sun
/usr/lib/jvm/java-1.5.0-sun
/usr
Save and close the file.
Setup the environment variable

You also need to setup JAVA_HOME and PATH variable. Open your $HOME/.bash_profile or /etc/profile (system wide) configuration. Open your .bash_profile file:
$ vi $HOME/.bash_profile
Append following line:
export JAVA_HOME=/usr/lib/jvm/java-6-sun
export PATH=$PATH:$JAVA_HOME/bin
Save and close the file.
Test your new JDK

Type the following command to display version:
$ java -version
Output:

java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)

Try HelloWorld.java - first java program

$ vi HelloWorld.java
Append code:

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

Save and close the file. Compile HelloWorld.java and execute program by typing following two instructions:
$ javac HelloWorld.java
$ java HelloWorld

Output:

Hello, World!

Find file with certain title, make bash re-read the .bashrc

Make bash re-read the config file .bashrc, type the following:

. .bashrc


Note the space between the dots.

Find file with certain title:

find / -name "filename" -print

java.lang.ExceptionInInitializerError after manually updating Java

OK, after I did the manual updating as was explained in the last post, I was unable to run my applet. The Java Console throws java.lang.ExceptionInInitializerError error. I did not know what went wrong.
After googling, I arrived at the following information.
#
Run sudo update-java-alternatives -l to see the current configuration and possibilities.
#
Run sudo update-java-alternatives -s XXXX to set the XXX java version as default. For Sun Java 6 this would be sudo update-java-alternatives -s java-6-sun
#
Run java -version to ensure that the correct version is being called.
I ran the command, and the following was the result on my console:
java-6.19-sun 60 /usr/lib/jvm/java-6.19-sun
java-6-sun 63 /usr/lib/jvm/java-6-sun
java-gcj 1042 /usr/lib/jvm/java-gcj
java -version shows:
Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
Java HotSpot(TM) Server VM (build 16.2-b04, mixed mode)

So, my manual installation works. But why does running applets throw the above error? So I decided to revert to java-6-sun. And the exception does not show again. What went wrong?

Updating Sun JDK in Ubuntu

I recently had to update my JRE to the latest 6 update 19 to replicate a security warning dialog. I found the tutorial here. I will copy it here just in case something happens to that blog and this info that I surely will need again later disappears (Og, God forbids!)

Start by downloading the JDK for your architecture from SUN. Take the .bin file, extract it by running it as a shell script:

sh jdk-6u19-linux-i586.bin

This will create a new folder called /jdk1.6.0_19. Rename this to java-6-sun-1.6.0.19 (just to remain consistent with how Debian/Ubuntu refers to JDK's) and move this folder to /usr/lib/jvm:
 
sudo mv jdk1.6.0_19 java-6-sun-1.6.0.19
sudo mv jdk1.6.0_19/ /usr/lib/jvm

Officially you are suppose to use the update-java-alternatives command when using a Debian distro, but frankly I find it easier to do this manually. We need to update the /usr/lib/jvm/.java-6-sun.jinfo, so type:

sudo gedit .java-6-sun.jinfo

This will open up a hidden configuration file. The first line likely shows:
 
name=java-6-sun-1.6.0.06
...
Simply change this to point to the new version:
 
name=java-6-sun-1.6.0.10
...
Also, update the java 6 symlink to point to the one we just installed:
sudo rm /usr/lib/jvm/java-6-sun
sudo ln -s /usr/lib/jvm/java-6-sun-1.6.0.10/ /usr/lib/jvm/java-6-sun

If anything goes wrong after the above steps are taken, proceed to the following. But only if anything screws up. (Taken from here).

  • Open a Terminal window
  • Run sudo update-java-alternatives -l to see the current configuration and possibilities.
  • Run sudo update-java-alternatives -s XXXX to set the XXX java version as default. For Sun Java 6 this would be sudo update-java-alternatives -s java-6-sun
  • Run java -version to ensure that the correct version is being called.
You can also use the following command to interactively make the change;
  • Open a Terminal window
  • Run sudo update-alternatives --config java
  • Follow the onscreen prompt

session_start() error

Session functions, including session_start() should come first in an PHP page. It can not be preceded by any other thing, not HTML tags, not even a new line!

Moving wordpress blog to a different domain

Recently I moved my wordpress blog to a new domain. Many links broke. Styles were not applied. After googling, I stumbled upon this wisdom.

To update WordPress options with the new blog location, use the following SQL command:
UPDATE wp_options SET option_value = replace(option_value, 'http://www.old-domain.com', 'http://www.new-domain.com') WHERE option_name = 'home' OR option_name = 'siteurl';
After that you will need to fix URLs of the WordPress posts and pages, which translated from post slug, and stored in database wp_posts table as guid field. The URL values in this field are stored as absolute URLs instead of relative URLs, so it needs to be changed with the following SQL query:
UPDATE wp_posts SET guid = replace(guid, 'http://www.old-domain.com','http://www.new-domain.com');
If you have linked internally within blog posts or pages with absolute URLs, these links will point to wrong locations after you move the blog location. Use the following SQL commands to fix all internal links to own blog in all WordPress posts and pages:
UPDATE wp_posts SET post_content = replace(post_content, 'http://www.old-domain.com', 'http://www.new-domain.com');
Browse through WordPress blog to check if everything is okay. You also need to re-login to WP Administration as authentication cookie has now became invalid due to different domain.

Changing the default storage engine in MySQL

I am reading this tutorial from Philip Greenspun. He uses Oracle. He uses reference constraint. One commenter said that you can do that in MySQL only if you use InnoDB storage engine.
The default storage engine in MySQL is MyISAM. If you want to change it, there are quite a numerous ways to do that.
You can change what storage engine to use for a table.
You can change what storage engine to use for a session.
You can change THE DEFAULT  storage engine so that whenever you create a new table, that default will be used.

To do the last, you need to edit the file /etc/mysql/my.cnf (in Ubuntu).
Under the [mysqld] add the following line as shown below!  
[mysqld] default-storage_engine = innodb 

And then restart the mysql:
sudo /etc/init.d/mysql restart