String Pools in Java

My teammate recently commented on my using of the "==" sign to compare String literals in Java, as I was accustomed to using .NET, and the code worked anyway, I didn't mind using .equals. Why did it work? XYZWS Java FAQ explains the cases wherein references to String literals are treated as the same by the JVM. A little bit elementary, but here it goes:
------

String Literals in the Java Language Specification Third Edition

Each string literal is a reference to an instance of class String. String objects have a constant value. String literals-or, more generally, strings that are the values of constant expressions-are "interned" so as to share unique instances, using the method String.intern.

Thus, the test program consisting of the compilation unit:

package testPackage;
class Test {
public static void main(String[] args) {
String hello = "Hello", lo = "lo";
System.out.print((hello == "Hello") + " ");
System.out.print((Other.hello == hello) + " ");
System.out.print((other.Other.hello == hello) + " ");
System.out.print((hello == ("Hel"+"lo")) + " ");
System.out.print((hello == ("Hel"+lo)) + " ");
System.out.println(hello == ("Hel"+lo).intern());
}
}
class Other { static String hello = "Hello"; }

and the compilation unit:

package other;
public class Other { static String hello = "Hello"; }

produces the output:

true true true true false true

This example illustrates six points:

* Literal strings within the same class in the same package represent references to the same String object.
* Literal strings within different classes in the same package represent references to the same String object.
* Literal strings within different classes in different packages likewise represent references to the same String object.
* Strings computed by constant expressions are computed at compile time and then treated as if they were literals.
* Strings computed by concatenation at run time are newly created and therefore distinct.

The result of explicitly interning a computed string is the same string as any pre-existing literal string with the same contents.

JOX: Java Objects in XML

I've been working on a Java Swing prototype and today I researched about using XML as data storage for temporary persistence of data.

I came across JOX, or Java Objects in XML which uses serialization to transfer data between documents and Java Beans. A rather old open source library, I used it in place of SAX and DOM parsers to minimize effort in the parsing of data. One issue that I've encountered is the Unsupported date format exception during loading of java.util.Date fields. I thought maybe the library don't support all Locales. I had to use a temporary string variable to store the date in String format before converting them to Date class.

There's got to be some other way to save application state for Swing applications. Hmm..

---
References: http://www.wutka.com/jox.html

Preparing for the Sun Certified Enterprise Architect for J2EE Technology (Step 1 of 3) (CX-310-051) Exams

Just this week, I've decided to take the SCEA (Part 1) exams. Scanning through the outline of the exams, it seems that this novice programmer still have much to learn.

As I brush through Sun Certified Enterprise Architect by Mark Cade & Simon Roberts, I'm surprised that the book is an easy read, consisting of measly 159 pages including title page and all, so I'm kind of feeling positive right now that I can actually make this despite not having any clue about EJBs, legacy connectivity, and the other contents of the exam.

For those who are not familiar with it, the Sun Certified Enterprise Architect for J2EE Technology certification exam or SCEA is for enterprise architects responsible for architecting and designing Java 2 Platform, Enterprise Edition (J2EE) compliant applications, which are scalable, flexible and highly secure.

There are 8 main points to consider in building software:
(1) Performance. For this, two important measurements are used: response time and transaction throughput.
(2) Scalability. There are two types of scaling: Horizontal and vertical scaling, horizontal scaling adds more machines to the environment to add system capacity while vertical scaling adds more processors, memory, disks or machines.
(3) Reliability.
(4) Availability.
(5) Extensibility. To make extensible systems, remember to LIE: Low coupling, Interfaces, and Encapsulation.
(6) Maintainability. LMD: low coupling, modularity, and documentation.
(7) Manageability. The ability to manage the system to ensure the continued health of a system with respect to scalability, reliability, availability, performance, and security.
(8) Security. Consider CID: confidentiality and integrity, Denial-of-Service (DoS)

Again, repeat after me: PaSaRAEMaMaSa - Performance, scalability, reliability, availability, extensibility, maintainability, manageability, and security.

The topics included in the exams generally revolves around how to address these issues in building J2EE 1.4 softwares.

---

References: http://www.sun.com/training/certification/java/scea.xml