Java: OutOfMemoryError vs StackOverflowError

Some Java fundamentals that I read recently. Yes a bit ashamed ( : (  ) of myself that I never really considered their differences apart from knowing that they both relates to a lack of memory. But essentially the cause of their problems are actually quite different! : O


OutOfMemoryError:
Thrown when Java is running out of memory and cannot allocate any more memory in the heap for the object

StackOverflowError:
The stack space lives at the top-end of the address space and the heap lives at the bottom-end of the address space. As stack grows, it grows downwards. As heap grows, it grows upwards. So there is a potential that the two can collide and when that happens, you get a StackOverflowError thrown. Typically happens when you call some methods recursively (that keeps going-and-going).

(Really good explanation on StackOverflowError here: http://stackoverflow.com/questions/214741/what-is-a-stack-overflow-error)

XML Encoding & Special Characters

Another day at work (right after holiday too) I encountered this problem with XML and encoding. As I have a lack of knowledge on this topic, it took me a while to figure this out (asking around for help) and it turned out to be a very valuable lesson for me.

You see the XML file that created the error contains some special XML characters. Now what I mean by 'special characters' are one of these (see link): Special Characters and Symbols, e.g. ™, • or √.

The 'actual' symbols you see are in UTF-8 format. However XML may be stored as Latin-1 (ISO-8859-1) encoded. Now because Latin-1 is only 8-bit long so it can only represent characters that is not bigger than the 255 range. On the other hand, UTF-8 can represent up to 8 bytes of data. So it is obvious that some characters in UTF-8 will not be able to be directly converted into Latin-1. In these cases, the ampersand encoded version may be used instead to represent the same character in Latin-1, e.g. ™ •  &#8730. This is why it would be important to ensure the 'encoding' you listed in your XML file matches the same encoding the actual file is saved in.

Now the actual problem I was experiencing is I believe someting called HTML purifier. See this very very useful web page which tells you all about this (and gives a good explainations in XML encoding)! You see I was trying to write some Java classes to remove some unwanted node from an XML file's DOM tree. However everytime when I pass in an XML file with 'special characters', it always come back out with a question mark ('?'). The problem was because I got fooled by the encoding that was listed in the xml file and also with the unexpected kindness of Java to try to help me by purifying the XML file.

The problem was resolved by understanding how Java and XML works. Most importantly to understand that the encoding in an XML file is not just purefly for the sake of meta-data, but it is very important in determining which encoding / decoding to use when writing Java classes to process the XML file.

Additional ref: Processing XML with Java

Hibernate - The Basics (Part 1)

Have been working on a new project recently, finally get to really deal with the basics of Hibernate. Here are two basic things that I've learnt so far:

1. The concept of "Persistent":
   My intention is to insert two new rows into a database table.
   

   Bean bean = new Bean("Hello");
   session.save(bean);
   
   bean.setName("Bye");
   session.save(bean);
   

   But this isn't going to work!!! With the first save action, it has already 'persisted' the bean. Hibernate remembers that you have already saved the bean, so with the second save action, it will think that you are trying to save the same bean and rather than something new that represents a new row.
   
   So in order to insert a second row into the table, I MUST create a new instance of Bean before I try calling the save action again.
   
   
2. The concept of "Dirty" data:
   Let's say I have already persisted a bean. I then update the bean and try to get the same type of bean from the database.
   

   Bean bean = new Bean("Hello");
   session.save(bean);
   
   bean.setName("Hi"); // updated the bean with new value
   Bean retrievedBean = getBeanFromDB(bean.getName());
   

   You would've think the "get" method will only execute a SELECT query. But WRONG! Hibernate is smart enough to realise that the bean that it persisted is dirty (i.e. its data has been updated). In the "get" method, Hibernate goes "ah oh...need to retrieve some Bean objects from the table. I know some data is dirty, I must write it to the DB first, so I can return the latest data back to the user".

Updating Java JRE with Daylight Savings Patches

Recently I had to update the daylight saving data on the Java JRE due to the recently NZ daylight saving changes. Updating the daylight saving changes wasn't as hard as I thought and the process went very smooth too! : )

Here's a quick summary of my findings and what I did:
The Java SE platform uses its own private repository of timezone data. Therefore patching your OS's timezone data will not update or change your Java's timezone data.

Inside the JRE the timezone data is maintained inside the folder: jre/lib/zi.

The list of timezone data version can be found in:
http://java.sun.com/javase/timezones/tzdata_versions.html

The easiest way to do it is by using the TZUpdater available from this page:
http://java.sun.com/javase/timezones

You can first run a test on the JRE to see what version of the timezone data it is using by (where tzupdaterXYZ.jar is the name of the TZUpdater jar):

java -jar tzupdaterXYZ.jar -t

In the printout you should be able to tell the version of data it is using.

Finally, to update the timezone just run the jar without the "t" flag. Run a test again to verify that the timezone data has been updated.

Viola your JRE timezone is now patched! Easy as that! : )

Reference:
http://java.sun.com/javase/timezones/DST_faq.html#tzupdater
http://java.sun.com/javase/timezones/

Java error: Unsupported major.minor version

If you see the following error popping up (or something similar):

Unsupported major.minor version 49.0

It means that the one of the classes you are using / referred to when running / compiling your source was previously compiled with a version of Java that is different to the one you are currently using on your machine. In particular version 49.0 is Java 5 while 48.0 is Java 1.4

For example the class was compiled against Java 5, but you are currently using Java 1.4. Obviously the best way to resolve is to change the version of Java you are using, or if you can recompile the class file in a different Java version.

Reference:
http://www.artima.com/forums/flat.jsp?forum=1&thread=108274
http://forum.java.sun.com/thread.jspa?threadID=722374&messageID=4165690

Just the Exact Description at Work!!!

Not too long ago, one of my workmate sent me this! LOL...it's just SO RIGHT!!!! : P Love it!!!!!!!

101% match up with what we (programmers) are like (or be like) at work!!!!
(oops I mean "No we Don't do that"....mwahah Yeah right : P !!!)

(Original image can be found from http://xkcd.com/303/)

SQL Server weirdness: Alter column datatype from ntext to nvarchar

Came across this SQL Server weirdness at work...if anyone is designing a database with column datatype of 'ntext'....then think twice! : O

You see i was writing up a SQL Server DB upgrade script and I wanted to alter a table column of datatype 'ntext' to 'nvarchar'. After I have written the SQL statement, executing it resulted in an error:

Cannot alter column 'xxx' because it is 'ntext'

Thankfully my beloved friend Google was able to help me out on this! Apparently this works in Enterprise Manager (hmm I wonder if it works for SQL Server 2005...but I would believe so) because EM does some magic to ensure it gets its job done for their user:

"You will see that it (EM) is actually copying the old table, creating a
new one, copying the data from old to new and dropping the old. That is
why it works in EM and not in the query tool!"

Right...so EM creates a new table, copy the data and then drop the old table, so that's why EM has no problem with it. But you see I am writing a script, so I am forced to 'write the query' myself! So all I need to do is to write a few more statements to manually emulate the EM behaviour in my script. (Not a hard task when table is small...but could become hideous if table is a big one)

I only have one complain about all this....ahha why can't SQL Server display more 'informative' error message! -.-" Thank goodness my friend Google is around! hehe : P

References (thanks to the following pages):
http://forums.devx.com/archive/index.php/t-48982.html
http://www.dbforums.com/archive/index.php/t-318199.html

Software Project "Postmortems"

Prelude:
Yip...have been off the blogging world for a bit longer than usual as I've been quite busy trying to catch up and finish off various businesses in 'me' life!

During my 'off blogging' period...of coz I'm still relatively active on the web....and I have so many so many so many blog posts that have accumulated for the past couple of months or so....so, let me see if I can slowly catch up! : P

Meanwhile let me move on to "Postmortems"!!!

What is "Postmortems"?
Typing in "define: postmortem" on Google gives me the following:

Occurring after death.
www.dabney.com/wacomuseum/library/medterms.html

After death. Often used to describe an autopsy.
www.stjude.org/glossary

Complete exam of chicken after death
www.geocities.com/KelliAnn293/definitions.htm

Came across this article today at work:
Gave Development Postmortem
which talks about what can and should be discussed after a software project has come to an end.

Obviously this rarely happens in reality, but I reckon and agree it is very important to have 'some sort of postmortem' no matter how short it takes. By having communication and discussions, everyone and those participated can all 'learn' from the experience....so that the next project will be better to manage, better to develop and more efficiently completed!

My conclusion:
If I am a manager or a project leader one day.....I'll definitely look into this!!! : P

*P.S. - Inside the article there, there is a link to another article "The Value of Project Postmortem"

Review on "The Pragmatic Programmer"

Prelude:
Yeah!!! : ) Another job done for 2007!!! I finally finished reading the book "The Pragmatic Programmer" (after holding on to it for almost a year now! -.-" which I felt bad indeed!!!). But this doesn't mean that it is a bad book at all...in fact it is a very informative one (but only to programmers and programmers who 'cares' and 'want to become better')!


Brief Review and My Thoughts on the Book:
The book is definitely about how to become not just a 'good' but a 'professional' programmer! The book contains various tips and ideas on ways to make a programmers' life more efficient and prevention from tripping up in a software project.

It goes from talking about the general ways to improve coding; how to approach and begin a project; to expanding your software tools to make your programming life easier; testing of the software and user satisfaction.

Speaking from a SE (Software Engineer) grad point of view, a lot of the things mentioned in the book are already known & taught to us e.g. decoupling and cohesion of modules, testing should be done along side of coding. But after reading the book, I feel that it was able to emphasize these importance concepts to me, making it more 'believable' in practise.....encouraging their application in real life projects.

Notable Tips from the Book:
Some of the notable tips for me from the book (extracted and referencing from the book):

• DRY - Don't Repeat Yourself
  "Every piece of knowledge must have a single, unambiguous, authorative representation within a system." Duplication should not arise not only in the code, documentation (code + technical), functionality of the system and even information and even 'interdeveloper' where the same function gets implemented in duplication.
• Eliminate effects between unrelated things
  "We want to design components that are self-contained: independent and with a single, well-defined purpose. Then you know that you can change one without having to worry about the rest."
  
• Fix the problem, Not the Blame
  "It doesn't really matter whether the bug is your fault or someone else's - it is still your problem and it still needs to be fixed."
• Don't Panic When Debugging
  "Take a deep breath and think about what could be causing the bug."
• You Can't Write Perfect Software
  "Software can't be perfect. Protect your code and users from the inevitable errors."
• Configure, Don't Integrate
  "Implement technology choices for an application as configuration iptions, not through integration or engineering."
• Separate Views from Models
  "Gain flexibility at low cost by designing your application in terms of models and views." This does not mean the MVC model from web development....the same concept can be applied to any application at its entirety...where the whole system support the concept of multiple views of the same data model, or common viewers on many different data models, or even multiple controllers to support various input mechanisms on the same view.
  
• Don't Program by Coincidence
  "Rely only on reliable things. Beware of accidental complexity, and don't confuse a happy coincidence with a purposeful plan." i.e. don't program by 'fluke'! Understand why something happened in such a way!
• Test Your Software, or Your Users Will
  "Test ruthlessly. Don't make your users find bugs for you."
• Gently Exceed Your Users' Expectations
  "Come to understand your users' expectations, then deliver just that little bit more." But don't overdo it....as it may be so overdone that it does not match their original concepts.
  

Conclusions:
Overall the book does have a lot of recommendations and ideas on how a programmer can improve their programming life. Although at places I found it to be boring to read (probably because I read it right before my sleeping time! -.-"), but I think it is definitely beneficial for all programmers to who want to better themselves to read this book. I think the book would fit better as a reference book, where you take the book out for a read when you are 'lack of motivation'.