Thursday, October 2, 2008

Why Strings are immutable?

From all the objects in the java world the String object is the most exceptional one. It's the only object that you can use the operators + and += on it. This is the only object that you can define like String myString = "moshe". And the most important feature that affects all of us is that Strings are immutable? Why? What so special in Strings and why it's not like it in different languages? In fact strings are very important and unique objects in java for the following reasons:
Java is the internet and networking language. Therefore, we will need a language that supports reading text very well. Therefore, we don't want to allocate new string for every string object. The solution: java creates a constant pool for strings each string that is allocated in compile time is allocated in the pool so we will reduce creation of redundant object. Therefore, the string must be immutable, since if not changing in one reference of the string will change the string in other references of the program.
Since string is so basic in java, the java developers would like to give the string the essence of primitive. Since string is immutable it looks like it pass by value for a method (if the string has changed is no longer the same object) so String is immutable like all the other wrappers of the primitives.
Since Strings are very popular mainly for configuration, it is highly important that the String will be thread safe without paying the cost of synchronization therefore, using immutable object is highly recommended here.
String is one of the basic objects in java this is why it's so unique. It is highly important to understand its place in the java world.

Sunday, September 21, 2008

link to the video of the open house

as i promised you, this is the link http://iwebcast1web.you-niversity.com/SLVideoPLayer/Player.aspx?ID=96a96806-1344-40d1-adcf-8ef34152ffc7 for the java open house that took place last week. I would like to thank to all the participents that come to this lecture and i hope to see you next time.
bye bye.
Moshe

Thursday, September 11, 2008

open house about java threads


Hi,

in the 17.9 i will give a lecture in Sela about java threads.

more information and registration at http://www.sela.co.il/

In this lecture i will try to focus about issues that hidden to the common programmer.

in the lecture i will talk about:

thread life cycle

thread groups

thread perofrmence

thread utilities

thread design pattern.

the lecture will be recorded and will be published in the site.

the lecture will look something like:


the lecture will be in hebrew.

Since i have a lot of material and probably two hours will not be enough, i will put the rest of the material in my blog.


below you can find the brocure for this open house.







Sunday, August 31, 2008

Java memory leak

One of fun things in java is that you don't need to release the memory of your application, this future effect dramatically on the way you write code.
For example: if you allocate some objects in java in a method and suddenly an exception is thrown you don't need to free the memory, the GC will do it for you.
In C++ for example is very disturbing problem. Since you have to release the memory you allocated in case of failure.
Student a;
Try {
Int I = getIdForStudent();
a = new Student(id);
int ave = a.getAverage()
}
catch (...){
// should we release memory of a?
}
Here you can see the problem of this issue, even the allocation can be fail. Then we don't even know if we should release the memory or not. Luckily in java we don't have that issue.
However, it doesn't mean we don't need to release the memory in java!
In order to understand how you are release memory in java you have to understand how the garbage collector works. The GC scan the memory of the application looking for objects that doesn't have reference to other objects or has reference to objects that are not connected to other objects, the garbage collector release the memory of such objects once it found them.
Therefore, if you have a list of students and the user removes one of the students, the user should be removed from the list as well.It's not always that simple, I worked on one projects that we have a log event and the log event developer decided to hold a reference to the objects that related to the log record. For example:
Student Moshe was created: contains the object Moshe.
After some working we sense that we have a serious memory problem. I examine the code closely and I saw that the object LogEventRecord holds a reference to the Student object; it means that the student object that in our case holds a lot of references as well was never deleted from the memory! Therefore, we tie the student object with weak reference so the garbage collector will collect the object despite its connection to the event log. The application can fetch the data from the database via the DAL layer, if you open the event log and ask for more details on the student. The upside is that we release the memory and the downside is that fetching the log event includes execute queries from the database.