Fresh from my Inbox. Enjoy.

How did they made the jump from J2EE design patterns to Windows device drivers, I don't know. However their guess is not completely without merit. Take a look at the Windows device driver I wrote: WQGHLT. It's GPL-ed.

Responses[2]

Posted by Weiqi Gao on February 29, 2008 8:24:50 AM CST #

This is related to my past posts on Debugging Into JNI Code from 42 days ago. I haven't tried it yet. I'm blogging about it so that I don't lose the link or the tip.

Roman Kennke: The last couple of hours I struggled to debug a segfault some JNI code of OpenJDK. I could not get GDB doing anything useful with Hotspot. Until I discovered the following very useful command line option:

java -XX:OnError="gdb - %p" MyApplication

This fires up gdb whenever an error occurs, and sets up all the libraries etc for debugging. Very nice. Ideally you do this using a debug build of OpenJDK, so get get as much useful information as possible.

Add a comment

Posted by Weiqi Gao on February 29, 2008 6:57:49 AM CST #

It looks like java.net doesn't like me any more. I'm not allowed to post a comment to Alex Winston's blog:

Alex Winston's Blog

Comment Submission Error

Your comment submission failed for the following reasons:

You are not allowed to post comments.

Posting as: weiqigao
Allowable html: a href,br/,p,b,strong,em,i,ol,ul,li,blockquote,pre

So I'll post what would have been a comment on that blog here. This is in response to a Cay Horstmann comment that reads:

Cay Horstmann: I think int plus2(int) is a non-starter. Don't entangle the declared variable within fragments of the type. That approach has been thoroughly discredited after it made a disastrous appearance in C/C++. Try writing a function that yields an int=>int function using your syntax...

@Cay, it is actually quiet simple to write such a function:

int makeAdder(int n)(int x) = int (int n)(int x) {
  return int(int x) { x + n };
}

Given the above, we can have

int add7(int x) = makeAdder(7);

and

int result = add7(8); // yields 15

Responses[2]

Posted by Weiqi Gao on February 28, 2008 10:02:57 AM CST #

It looks like I'm not alone in wanting the Java closures syntax to be more Java methods like.

• Pointer Syntax for Java Closures (WarpedJavaGuy)

  int y = 6;  
  boolean* (int) a = (int x) {x <= y};  
  boolean* (int) b = (int x) {x >= y};  
  boolean c = a.invoke(3) && b.invoke(7);

• Closure Syntax (Alex Winston)

  int plus2(int) = int (int x) { return x + 2; };

Both of the above, like mine, are non-proposals from non-language designers. And like mine, both appeal to the C function pointer syntax.

I understand that the C function pointer syntax is a little bit foreign to the non-C/C++ Java programmers. I still believe C function pointer syntax based Java closures syntax will mesh well with the rest of Java syntax.

For another reference point, here's the syntax for one of the C++ closure proposals:

tr1::function<int(bool)> A::f2 = int(bool b) { return b ? 1 : 2; };

Of course, for designers of the Java closure fetures, (I imagine) the syntax is the least important aspect of the design. Just like for those of us who writes GUI applications, we are not thinking about how good the screens are laid out when we are concentrating on the internals.

However, when they show their design to us, the syntax is the first thing that we have to get used to. Just like when we show a half baked GUI application to our users, the first thing they see is how ugly the screens are.

We are focusing on the syntax because that's all we see. And if my analogy can be carried a little further, the language designers don't usually know what the best syntax for the feature is. Just like the programmer usually design the ugliest GUIs.

Responses[2]

Posted by Weiqi Gao on February 27, 2008 10:50:48 PM CST #

The pattern of lead engineer jumping off the Java train continues with Chet Haase, the lead Java client architect, joining Adobe's Flex SDK team.

Eric Burke, over there at Stuff That Happens.com, as usual, has the in depth analysis:

([Update] Eric has since toned down the original wording of the comment and withdrew two out of three frames of the comic, and issued an apology. I have updated my quote accordingly.)

Eric Burke: This is a real XXXX in the XXXX...

Of course, Adobe doesn't think so:

James Ward, commenting on Eric's Comic: Adobe is not trying to kill anyone or anything. We are always looking for great engineers. Chet is a great engineer and we are really happy to have him on board.

Instead of getting all depressed, let me salvage the situation and turn this situation into a fun little Sunday Java People Quiz:

Q: For each of the following former Sun engineers, discuss the importance of their contributions to the Java platform, what prompted them to leave the Java team, and which company, if any hired them away?

• Arthur van Hoff
• Alan Baratz
• Patrick Naughton
• The original CAFEBABE
• Calvin Austin
• Joshua Bloch
• Neal Gafter
• Gilad Bracha
• Peter van der Ahe
• Graham Hamilton
• Dick Wall (or one of the other Java Posses, I can't tell them apart)
• Bill Joy
• Ken Arnold
• Mary, the lady who use to give out Friday Free Stuff
• (Add more in the comments)

The point? Java has survived in the face of all these public high profile separations. It will live on past this one.

Responses[6]

Posted by Weiqi Gao on February 24, 2008 9:58:57 AM CST #

In case you are not checking your [javasig-announce@ociweb.com] email (and are checking this blog, strange as that may be), the following email went out to the [javasig-announce] list fifteen minutes ago:

All,

Because of weather and road conditions, we are canceling tonight's JBoss SEAM presentation. We hope to reschedule this with Red Hat sometime.

Our apologies for any inconvenience.

STL JUG Steering Committee

Be safe in the bad weather! We'll see you next month.

Responses[1]

Posted by Weiqi Gao on February 21, 2008 3:09:04 PM CST #

Stephen Colebourne: Function types, or method types as FCM refers to them, are one of the most controversial features of closures. Is there an alternative that provides 80% of the power but in the style of Java?

Stephen went on to derive an alternative syntax for the part of BGGA closures proposal that's hardest for ordinary Java programmers to "get".

To understand what Stephen's talking about, look again at my Friday Java Quiz closure example 20 days ago:

public class Fib {
  private static {int=>int} fib = {
    int n =>
      n==0 ? 0 :
      n==1 ? 1 :
      fib.invoke(n-1) + fib.invoke(n-2)
  };

  public static void main(String[] args) {
    System.out.println(fib.invoke(6));
  }
}

Knowing that most ordinary (by which I mean non-new-language-feature-designing) Java programmers are not following the closures development, I put this example on the white board in my office and quizzed everyone walking by. Of the six or seven extremely bright people who were put on the spot by my question "Come here. Take a look at this and see if you can figure out what this program means" only Rob deciphered the program without any hint.

There are three difficulties associated with this piece of code:

• The function type syntax (the red part)
• The input variables specification syntax (the blue part)
• The invocation syntax (the green part)

Of the three, the function type syntax is the most severe cognitive barrier. Most of my innocent victims simply get stuck at the notation and can't parse any further. I have to draw a black box around it and say "This is a type" before they can make sense of the rest of the example. They'll then say "Oh, so fib is a function that take an int and returns an int. Which is the input and which is the output?" Or "Why don't we name the input variables and the output variables in the function type?" David even asked "Why can't we have more than one output variables?"

Those who learned Ruby closure syntax quickly recognized the resemblance between the "{ int n => ... }" and Ruby's "{ n |... }" . But some reacted violently to the newly coined token "=>". Brian is offended by it enough to come up with his own alternative using the # character instead.

The problem with ".invoke" are revealed by questions like "The .invoke() must be a method of fib. Where is it defined?" At which point an explanation must be given about the generated interface for function types and its invoke() method. Brian went so far as to erase the ".invoke"s from the example. And I do agree that the code looks more natural without them.

Mark's reaction to my quiz included the question about what can go legally into the right hand side of the "=>" in a closure literal. You can't guess it by looking at my example, but a sequence of zero or more statements terminated by semicolons and an optional final expression without the terminating semicolon can go there. And the final expression will be the value of the closure invocation expression.

As long as attitude towards closure proposals are concerned, I'm still seeing mainly two camps: the "I've been programming in Java for ten years, and never once were I wishing Java had closures" camp, and the "If we are going to add closures to Java, which seems inevitable at this moment, let's do a full fledged one like the BGGA closures" camp. There are some switch overs from the first camp to the second camp. Amazingly, nobody is switching from the no-closures camp into the other lets-do-a-little-bitty-syntax-sugar-here-and-there camps.

My personal experience with trying out the BGGA closures prototype is very similar to those of my victims: puzzled a little at first, and one by one, the concepts clicked. And the whole thing doesn't feel that crazy as my first impression suggests. Unlike Brian, I had no problems with the "=>" notation. Maybe it has something to do with my mathematics background where we use "=>" or "->" to mean exactly what the BGGA closures proposal means. For example:

floor: R ⇒ Z
floor(x) = max { n ε Z | n ≤ x }

However, I do see points in Brian's and now Stephen's proposal. I like Brian's proposal better because it doesn't introduce a new name for the type. Stephen's proposal is like a typedef, where many names could be introduced to represent the same function type.

I do have a better solution. Instead of inventing a new, different way of representing function types, why don't we borrow the notation from a language where functions are first class entities. No, I'm not talking about Haskell or ML or even Scheme. I'm talking about C. Yes, C, as in, the C language where Java inherited a whole bunch of basic syntax.

For those who are not familiar with C, a variable in C can be of a type of a function. And functions can be arguments and return types of other functions. And those three places are exactly where the BGGA closures needs syntax for function types. So why don't we borrow the C syntax with some simplifications.

To designate a variable or field as of the type "{int=>int}", we simply say:

int (*fib)(int);

compare with:

{int=>int} fib;

To designate that a method takes a function type parameter, we simply say:

int apply(int (*fib)(int), int x) {
  return fib(x);
}

compare with:

int apply({int=>int} fib, int x) {
  return fib.invoke(x);
}

Similarly for returning function types:

int (*addn(int))(int) {
  // ...
}

compare with:

{int=>int} addn(int) {
  // ...
}

To initialize a field or a variable with the closure literal, we can say:

int (*fib)(int n) {
  n == 0 ? 0 :
  n == 1 ? 1 :
  fib(n - 1) + fib(n - 2)
}

compare with the definition at the beginning of the post.

Notice all of the above are valid C code and should make Java programmers feel more at home.

If we want to go further along this direction, we can define a closure literal with the following syntax:

(*)(int n) { n * n }

If the thought of using the "*" clouds your mind, we can use "#" in its place.

A caveat: I'm not a language designer, and I'm not proposing anything here. What I said may or may not make sense. To quote Dennis quoting Dennis Miller, I could be wrong!

But I don't like the idea of Stephen Colebourne having all the fun! ;=)

Responses[13]

Posted by Weiqi Gao on February 21, 2008 9:44:57 AM CST #

I get a fair amount hits from Google Translate. And I usually take a look at the translated page, just for the fun of it.

I was looking at such a translated page this morning and noticed something is wrong, very wrong. If you work at Google, please pass the word to the Google Translate team that your English to Simplified Chinese translation has gone comical.

Instead of posting a whole translation of my post, I'll just mention a few choice bits. (You can verify these from the Google Translate page yourself if you don't believe me.)

For those who don't know Chinese, Google Translated "Who" into "The World Health Organization" in Chinese. It translated the common name "Alex" into a totally unrelated, neither phonetically nor by meaning, Chinese name pronounced "Xujia". It translated the common name "Miller" into a Chinese name pronounced "Miao".

I'm sure whatever problem I'm experiencing right now will be fixed soon. So if you are reading this after Feb 20, 2008, you may not get the comical result I'm getting right now.

Responses[3]

Posted by Weiqi Gao on February 20, 2008 8:15:00 AM CST #

Last Friday, Mark Volkmann presented a tutorial on ANTLR v3 at the OCI internal Java lunch. Since Mark has posted his presentation slides out on the internet, I did not take my usual amount of notes.

For me, ANTLR has been something that I'm aware of for a long time. I may have encountered it before it became ANTLR (PCCTS) when it was C++ based. However, its lack of applicability in everyday programming and the terseness of the documentation meant that I never get to know it well enough to actually use it in production code. The situation changed last year when the Pragmatic Bookshelf published the The Definitive ANTLR Reference book.

I have been staring at my copy of the book for a few months waiting for the time when I would have a big chunk of time to start reading and experimenting with it. Mark's talk gave me enough of a push to start my experimentation with ANTLR v3. Hopefully, this time I can sustain my energy and finish the book.

And one particularly good thing about Mark's talk is that its accompanied by a couple of examples that I can play with. Here's what the example does:

[weiqi@gao Math]$ java -jar build/math.jar 
math> f(x) = x^2 - 3x + 2
math> print f()
f(x) = x^2 - 3x + 2
math> print f'()
f'(x) = 2x - 3
math> print f(3)
2.0
math> help
In the help below
* fn stands for function name
* n stands for a number
* v stands for variable

To define
* a variable: v = n
* a function from a polynomial: fn(v) = polynomial-terms
  (for example, f(x) = 3x^2 - 4x + 1)
* a function from adding or subtracting two others: fn3 = fn1 +|-ghg fn2
  (for example, h = f + g)

To print
* a literal string: print "text"
* a number: print n
* the evaluation of a function: print fn(n | v)
* the defintion of a function: print fn()
* the derivative of a function: print fn'()
* multiple items on the same line: print i1 i2 ... in

To list
* variables defined: list variables
* functions defined: list functions

To get help: help or ?

To exit: exit or quit

If you've been trying to get to know a little bit about ANTLR but never have the right incentive or courage to open the book, give Mark's presentation material a try. And if you are in the St. Louis area, Mark will be giving the same presentation at the NFJS conference in March and the St. Louis Java Users Group in June.

Come!

Add a comment

Posted by Weiqi Gao on February 18, 2008 8:43:09 PM CST #

Tomorrow, February 7, 2008, will be the Chinese New Year. The year of the Pig ends and the year of the Rat begins.

恭喜发财! 过年好!

Seeing that my past postings have risen to the top of the results page for the "happy chinese new year" search phrase on Google.cn, topping even the Wikipedia page on the same topic, I'm encouraged to keep the tradition going, even though I'm battling a bad cold right now.

I'll try something different this year. I will attempt an English translation of one of the classical Chinese stories.

Peach Blossom Village—Tao Yuanming (365-427)

In the reign of Taiyuan of the Jin dynasty (376-396), a man from Wuling made his living as a fisherman. One day he was following a stream and forgot how far he had gone. He came upon a grove of peach trees along the banks for hundreds of paces. There wasn't a different kind tree among them. The grass was fragrant and fresh and beautiful. The fallen peach blossom pedals were everywhere and colorful. The fisherman thought this strange and rowed his boat more to get to the end of the peach grove.

The end of the grove was the source of the stream. And there was a hill. The hill had a small passage way and lights were coming out of it. He got off his boat and entered the passage way. The beginning of the passage way was very narrow, enough just for one man. He walked a few tens of paces, the passage way suddenly widened. A flat land was in front of him with neatly situated houses, rich fields, beautiful ponds, mulberry trees, bamboo bushes and the like. The south-north and east-west trails in the fields connected together. The sounds of chickens and dogs could be heard. People worked in the fields. Men and women were dressed just like the people outside. The elderly and the children were among them. They were happy and without a care. When they saw the fisherman, they were very surprised. They asked him where he was coming from, and the fisherman answered their questions one by one. They invited him to their houses, brought out liquor and slaughtered chicken for dinner to treat the fisherman. The villagers heard of this, they all came to ask questions. They said their ancestors came to this place with their wifes, children and villagers to flee the wars of the Qin dynasty (221 BC-206 BC). They never went out, hence they were isolated from outside people. They asked the fisherman what dynasty this was. They did not know about Han (206BC-220AD), let alone Wei (220-265) Jin (265-420). The fisherman told them all the details of the outside. They all were amazed and sighed. The rest people each invited him to their home and treated him with liquor and food. He stayed for several days. Then he bid goodbye. The villagers told him: "Don't bother telling the outside people about us."

He came out, got his boat, and went back along the way he came, leaving markers everywhere. He went to the jun (a jun has several counties) seat and told his story to the Tai-Shou (head of a jun). The Tai-Shou sent people to find this place with him. They followed his markers but eventually got lost and could not find the way.

Nanyang's Liu Ziji was a noble person. When he heard of this, he was happy and wanted to visit this place. But he couldn't make the trip. He died shortly after. After that no one else ever tried to find the place.

Responses[3]

Posted by Weiqi Gao on February 6, 2008 11:46:49 PM CST #

The closures are coming!
The closures are coming!!
The closures are coming!!!

And don't let your baby cry out loud.

To celebrate Java's entry into the closures era, today's Java quiz is about closures, specifically the BGGA closures.

Will the following

public class Fib {
  private static {int=>int} fib = {
    int n =>
      n==0 ? 0 :
      n==1 ? 1 :
      fib.invoke(n-1) + fib.invoke(n-2)
  };

  public static void main(String[] args) {
    System.out.println(fib.invoke(6));
  }
}

program compile? Run? If so, what will it print out?

You can bend the rules and actually run the prototype compiler that is available here.

Responses[6]

Posted by Weiqi Gao on February 1, 2008 10:20:41 AM CST #