*** MOVED ***

NOTE: I have merged the contents of this blog with my web-site. I will not be updating this blog any more.


R.I.P.: Old Bytecode Verifier

The old bytecode verifier used by the GCJ compiler has now finally been removed. It was a small and straightforward verifier but had a few bugs that made it difficult to use GCJ with random JARs. At the same time, the newer bytecode verifier (written in C++) used by the GCJ interpreter gij had far fewer bugs and could handle almost all JARs found in the wild. Since no one was fixing the bugs in the old verifier, GCJ could not work with many JARs for a long time and thus was unusable for a large number of potential users. Bryce made the new bytecode verifier work with the GCJ compiler to support the work on the new Binary Compatibility ABI. After some time I made the new verifier the default for even the old C++ ABI.

I feel guilty and sad now because once upon a time I had resolved to fix some of these bugs but never actually got around to fixing them. I had studied the source code and had read several papers on bytecode verification, especially some of the excellent ones by Alessandro Coglio, but never implemented any of the techniques. Not good.

(Originally posted on Advogato.)


Scratching An Itch: Terry Laurenzo, GCJ and Generics

One of the stumbling blocks in supporting generics in native programs created by GCJ is the fact that the C++ method-name-mangling used by GCJ does not encode the return type of the method and thus cannot support the Java 1.5 kludge for implementing generics (PR9861).

Terry was just another bloke who was trying to make his program work with GCJ when he hit this issue. Unlike most other blokes however, he has decided to do something about it. Cool!

(Originally posted on Advogato.)



VikGup takes a sabbatical for three months starting next week. I really envy him and I wish I could do the same.

Sabbaticals might be quite common in the west, but here in India they are very rare. Even when people want to take sabbaticals, many a time they are discouraged. I hope more people take off on sabbaticals like VikGup has done so that employers and family realise that it is OK, and actually quite healthy, to take a sabbatical.

Have fun VikGup!

PS: Is Mohan back?

(Originally posted on Advogato.)



I have been meaning to check out Lisp (or one of its dialects) for a very long time now. I first came across functional languages (via Standard ML) when we studied Principles of Programming Languages (PoPL) at college. PoPL was also responsible for introducing us to declarative programming (via Prolog). I found these two styles of programming very difficult to grasp as I had been programming with imperative languages (BASIC, Pascal and C) for around 4 years by then. The unfortunate part was that by the time we "got it", the semester was over and we moved on to other things. I told myself at that time that I would learn Lisp and Prolog on my own "soon".

Almost eleven years have passed since then and I still have not come around to actually learning these languages and the programming styles associated with them. Lisp at least keeps appearing on my radar every now and then. The urge to learn it becomes particularly strong when I read about the ravings of the early oldskool hackers in Steven Levy's "Hackers" or one of Paul Graham's articles on Lisp or SICP. Tromey's recent blogentries have once again aroused my interest in Lisp.

Instead of continuing to procrastinate, I want to start learning Lisp now. I think I would start by reading "Practical Common Lisp". I also hope to be able to understand the origins of Lisp by reading John McCarthy's original paper on Lisp. I hope to be able to overcome my revulsion for seeing so many parantheses in even the most trivial of programs.

(Originally posted on Advogato.)


GoF Honoured by ACM SIGPLAN

The authors of "Design Patterns" have been honoured by ACM SIGPLAN this year with the "Programming Languages Achievement Award". I personally think that this award is justly deserved. Their book has had a strong influence on the way I approach designing a program. I would gladly recommend this book to any programmer - you do yourself a disservice if you haven't read this book yet, for whatever reason.

Unfortunately, I see either a rampant abuse of Design Patterns ("Let's see how many design patterns we can fit into our design for this project") or a refusal to accept that they can have any merit besides being useful in impressing your PHB. Whether by diktat or by choice, if you are trying to come up with an object-oriented design for a project, it helps tremendously to know how other people have solved some of the specific problems in a way that allows the design to remain flexible while solving the immediate constraints. The flexibilities are precisely what come in handy in the face of ever-changing requirements. A secondary benefit is being able to use a common vocabulary to describe parts of your design to others, who can then immediately grasp what you are trying to do.

(Originally posted on Advogato.)