Blog of Meng Yan

I ever write an article about the event handling of Java and C#, just want to add some of C#’s delegate.

Delegate has no semantics carried, so does interface, it only provide method signatures.

Let’s look at the following example:

Class Person’s execute method will not accept the instance that implements the Gym’s Runnable interface.

But in this case,

It’s no problem for Person’s execute method to accept the Gym’s Runnable delegate.

So, delegate defines a single method signature to be wrapped by a delegate instance, but interface defines a set of method signatures to be implemented by a class.

More entries about : Java, C#, Delegate, Interface

JAVA SE 5.0 provides two very useful APIs to help us debug our program, All this two are all class "Thread"’s method:

public StackTraceElement[] getStackTrace()

Returns an array of stack trace elements representing the stack dump of this thread. This method will return a zero-length array if this thread has not started or has terminated. If the returned array is of non-zero length then the first element of the array represents the top of the stack, which is the most recent method invocation in the sequence. The last element of the array represents the bottom of the stack, which is the least recent method invocation in the sequence.

public static Map<Thread, StackTraceElement[]> getAllStackTraces()

Returns a map of stack traces for all live threads. The map keys are threads and each map value is an array of StackTraceElement that represents the stack dump of the corresponding Thread.

We can use this two APIs to get the thread’s stack trace information and help us debug or log. I will give a example that use this to write log.

If we are going to add log before, we need to add a "java.util.logging.Logger" to our class and use it to log. It’s ok and works pretty well, the following code just wanna to give you an example of the new exposed API "getStackTrace".

Caught the meaning? Yes, it’s pretty simple.

sts[0] = java.lang.Thread :: dumpThreads

sts[1] = java.lang.Thread :: getStackTrace

sts[2] = LogTest :: log ( This function )

sts[3] = Where you called the log function

And you can use this stack trace information to finish other features.

More entries about : Stack Trace, Tiger, Java

JSR223 "describe mechanisms allowing scripting language programs to access information developed in the Java Platform and allowing scripting language pages to be used in Java Server-side Applications."

This defines a framework to allow scripting language programs to access information developed in the Java platform. We currently plan to integrate this into Mustang for b40. Aside from the framework, we will also include a JavaScript engine based on the Mozilla Rhino implementation. Later, we hope to include a scripting shell that is script language independent. This will be a very cool way to create a prototype, do some exploratory coding, and learn new APIs.

The latest release of Mustang has already included this feature. You can check out the latest release of JavaSE to have a try.

Read the rest of this entry »

More entries about : Java, Mustang, JSR

Actually, this article is posted about one year before, at here. Today, I happened to see this article, interesting. So, I found my old entry and post here. Also, I post all the comments at the end, it’s really valuable I think.

Recently(2004.08.06), a friend of mine discussed the Event handle issues in C# and Java with me, sounds interesting. I would like to blog the discussion and my investigation here.

C# (pronounced C Sharp) is a programming language developed by MS as part of its .NET platform. When I saw it the first time, I ask myseft:"is it another version of Java?". Just a joke, C# is extremely similar to Java: GC, VM, single inheritance, interfaces, packages(use "using" instead of "import" ), pure OO etc. However, C# also invent many new features, delegate is a famous one.

Ok, let’s talk about the event-handle issues. In Java, we use the well-known Observer Pattern (Gamma et, Design Patterns) to implmented the events. For example, if we wanna to handle the Button’s Click event, we simply add a ActionListener to this button:

Or we can even add listener in following way:

In C#, Anders Hejlsberg introduced the new keyword "delegate", I think it’s actually like the type-safe function pointers. Anders really love the function pointers, he bring this to Delphi & Visual J++ too. Let’s first take a look at how this keyword works:

In Java, Since the listener rely on the interfaces, so, we can not call the methods without knowledge of the target object. For example:

A more complex example is the method whose name can be variant, you can find detail information in this article.

Although these two classes have common method, but because they do not share a common interface, so, we can not call them in a uniform way. How to solve the problem? In Java, we can use the Proxy Pattern(Gamma et, Design Patterns) and Adapter Pattern(Gamma et, Design Patterns) or use the reflection mechanism to solve the problem. In C#, ok, it’s delegate’s work.

The most important usage of delegates is for event handling:

Ok, that is the mechanism C# handle events. How about it? I think everyone has his cents. In my opnion, at the first look, it’s very attractive to me, things get easy now. But soon I feel uncomfortable. I don’t think this function pointer-like mechanism should exist in a pure OO languages . So, I would rather to use patterns to keep the code clean.

To summarize:
At the above situation:
1) If I can controll all the code, then I would rather retrofit a common interface that has "show" method;
2) If things are not that easy, for example: all classes are library codes, or method has different name, I’d like to use adapter and proxy pattern to solve this problems.

Just my cents.

Woty - not bad. delegate is some how usefule. but i think method should not be the first-class object. In common OO theory: Class := data + operation on data. if member operation is first-class, how about member varible?

Mijia - I think the delegate is just the wrapper for the function pointer or callback function in C/C++, which cannot be appeared in Java or C#, because they have their restrict security architecture. As well as first class object discussed, I do not know the exact ly defined concept, so I could not tell which idea would be correct. But I would like to regard it like that callback function or function pointer seems very dangerous in C/C++, but it is a fantastic mechanism which could provide flexibility for the software design. And I think Anders Hejlsberg from the C# loved it the most, so he cannot resist to add such mechanism into C#. But in Java, for the consideration of security, the function pointer is strictly forbidden, but Java could use the Reflect to emulate the behavior of the callback function or function pointers. And it is simple and flexible as well. So I think perhaps "function as first class" may be not pretty in the view of grammar or sementics, and in C# it is just one’s idea, some camouflage beneath the security flag.

More entries about : DesignPattern, Java, C#, Delegate, Object-Oriented

A useful tip to share with you.

I need to read the file from the current directory (same directory with the main jar file). In my code, I just use "new File("test")", and it works quite well.

But in my colleague’s machine, it throws the FileNotFound exception. Oh, we I saw the exception in his screen, I know that it’s a careless fault.
The problem is I accessed files in a given
location without an absolute path prefix.

In my case:

cd /home/elan/test/
java -jar test.jar

So, the current working directory is "/home/elan/test/", and we can access the file by a relative path.

My colleague’s case:

cd /usr/java/bin
java -jar /home/elan/test/test.jar

The working directory is "/usr/java/bin", and no "test" existed in this folder.

Ok, then how to get the current directory?

As we know, System.getProperty("user.dir") will get the working directory and System.getProperty("user.home") will get the home directory ("/home/elan/" for linux and "$:/document and settings/elan/" for windows case), but I cannot get any clue to get the current directory which contains my jar file and the "test" file.

I have thought that I can get this kind of code in "java.io" or "runtime" classes, but
I cannot find any clue. So, how about get the location of the jar file since it’s the file that in this directory. After a while, I got the answer:

getClass().getProtectionDomain().getCodeSource().getLocation()

It will return the class code base’s location, and in my case, the jar file’s location. So I just need to get the parent path of this location. The problem solved.

BTW:

1) You’d better pack the file into the jar and use the classloader to read it;

2) Or you can use the home directory ( System.getProperty("user.home") )

3) In my case, for some special reason, I must do this.

More entries about : Java

Today, my friend ask me to review some code of him, his code will encounter some unexpected error. He’s very confused and worried. After digging into the code, I found the problem.

Here’s the code slice :

private boolean done;
private Message[] messages;
... ...
synchronized(this) {
if(!done || messages ==null) {
	//	1
	try {
		wait();
		//    2
	} catch (InterruptedException e) {
		e.printStackTrace();
	}

	...

	dispatchMessage(messages);

	//    3

	...
}

dispatchMessage(Message[] messages) {
	int length = messages.length;

	//    4

	... ...

	messages = null;
}

When the program run, it will throw NullPointerException sometimes, though very infrequent. And just because of its infrequence, it’s hard to debug. But when go through this code slice, I think Java Expert can learn where’s the problem.
Try to imagine such scenario:

1) messages is null

2) Thread 1 check the condition in position 1 and waiting in position 2, and it will release the lock, So other thread can obtain it;

3) Thread 2 check the condition in position 1 and waiting in position 2 too;

4) When we get the message and notify all threads using notifyAll(), both thread 1 and thread 2 will be awaked but only one thread will obtain the lock.

5) Assume thread 1 will get the lock, and it will dispatch the message using dispatchMessage. after dispatching the message, it unreference the messages.

6) When thread 1 finished dispatching the message and release the lock. Thread 2 will obtain the lock, however, NOW, messages is null, so it will throw NPE.

Then, how to solve the problem? Yeah, it should use spin lock here. So, it will re-check the condition after being awaked and will avoid such problem.
That is, it should be

while(!done || message ==null)
... ...

And this trick is called spin lock(reference1) , you can see detail discussion in this book (practice 54).
BTW: You also can find this trick in “Effective Java”, in item 50 - “Never use wait out of loop”. And, this two book is really good and worth reading.

Reference:

1) “Pratical Java” - Peter Haggar

2) “Effective Java” - Joshua Bloch

More entries about : Java

These days, when I’m reading some other guy’s code, I encounter some problem. In these code, I can read following codes:

Look, it use “==” but not “equals” here. “Oh, it must be a bug!”, I told myself. But, wait, when I excuted the program, it worked quite well. And till this moment, I remembered, current powerful JVM will maintain a constant pool for String, so maybe two “OK” will reference the same place. So, such mechanism will work.

But, does Java Language Specification has such standard? and all JVM will follow this standard? I continue to dig into it.

First, I found such item in JLS 3.10.5 — String literals.

Abstract some points here:

Literal strings within the same class ($8) in the same package ($7) represent references to the same String object ($4.3.1).
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 ($15.28) are computed at compile time and then treated as if they were literals.
Strings computed 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.

So, this is the feature of String class, every JVM should follow. And, when I read the code of String.java, I found such comments in method “intern“.

public String intern()
Returns a canonical representation for the string object.
A pool of strings, initially empty, is maintained privately by the class String.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~So good:-)

When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned. Otherwise, this String object is added to the pool and a reference to this String object is returned.
It follows that for any two strings s and t, s.intern() == t.intern() is true if and only if s.equals(t) is true.
All literal strings and string-valued constant expressions are interned. String literals are defined in $3.10.5 of the Java Language Specification.

It’s quite clear about the case I encountered. Then I understand, this is not a bug, but the trick . But, why he use “==” but not “equals“, I think that will be more clear and more easy to read, I think there must be other guys to be puzzled as me .

I think the author must care more about the performance than the code, the performance of “==” sure if better than “equals“, especially when the String is long~.

Ok, everything clear now, and sure, not only String has such pool. For example:

what will System.out.println(i==l) output? I think you can get the right answer.

Update (2005.11.09):

"String"’s method "equalsIgnoreCase" also take advantage of this string pool:

If the two string point the same one, simply return true.

So, if you need to compare Strings frequently, you should "Intern" them.

For example, in Lucene’s source code, you need to compare the Field name very often, so, they intern the field name.

More entries about : Java, Performance