ThePanda

As most people know, I am on one of my semi-annual (or rather annual as this year’s going to prove, one hopes) trips to Delhi, or have been rather seeing as I am closer to departing than to arriving, which is probably why inclement weather warnings from the Med/Downcity SafeRide do not bode well for me, and are mildly scary. Oh well so much for winteryness, blizzards and the like. So I realize I haven’t actually updated in a while, and I do not really wish to give too much background, I will entertain certain questions, will elaborate on “shit happened” statements if asked about it nicely by people who I wish to elaborate to. Hmm so the things so far, let’s see: shit happened, became CS166 TA, summer party, more shit happened, exams, flew back home, got bored in Delhi, went to strange place in the hills, shit happened, came back to Delhi sooner than expected, am sitting typing this out, will leave soon. There, that was short and concise, the details are unimportant at best.

Which brings us to the point of this blog entry, JOGL, JNI and Cocoa. Let’s not do this in order, since I know far more about the last than either of the first two, know more about the first than the second, don’t really like either of the first two, and have mixed feelings on the third. The important things is the first and the last ones are impacting my new programming strategy, which isn’t all that different from my old one, and are the first library/language feature type things I am learning in a while, and are thus proving to be more than a little amusing, we’ll see how this comes along, its been ages since I last wrote about computing stuff, and hence my reviews are bound to be more irrational. This is not unexpected, and hence works out pretty well.

Ook, let’s get started with JOGL, not because it is the first thing on the list, which it is, since I don’t really care about the list, but rather because I was trying to decipher JOGL more recently than everything else. History first, JOGL’s supposed to be a project aimed at creating Java bindings for the hitherto unbound OpenGL libraries. I lie, ever so slightly, JOGL does aim to create a Java binding for OpenGL and hardware-accelerated 3D graphics, but this is not new, it has been attempted by people before, has led to such things as GL4Java, and has generally been subsequently abandoned, for reasons unknown. Now I am forced to sympathize with people who abandon these projects, especially since I am not a big fan of Java and to an extent because Java is slow enough to make me more worried about running background processes fast enough than about actual rendering. This could in part be a result of not really understanding the complexities involved in rendering relatively complex 3D imagery. This however does not change the fact that I do not actually like Java, and perhaps the only reason I am working at figuring out JOGL is because the chances of me finding a rational set of likable individuals who’d actually chose to work with me, should I chose to fixate on C or C++, during the course of CS32, are slim to none. JOGL helps I am told, am not completely sure how. So that being said, there are good things about JOGL, things to be proud of, things like a newly implemented natively Java version of GLU which did break backward compatibility with everything written so far, a supposedly simplified interface into the OpenGL libraries, a JSR release which did more to outdate old JOGL applications than everything else combined and such things. JOGL’s documentation proudly states that not all functions within JOGL follow native OpenGL conventions, since Java is different. Java is indeed different, it claims to be fully, or almost fully object oriented, and whenever I have read books on Java or taken classes in said language, the object oriented nature of Java has always been stressed on. Calling JOGL object oriented is similar to calling a C struct an object, the beginnings are there, it sort of fails to completely fit in. Well whoever was creating the library sort of came up with this plan of packaging every GL function in existence into a class known as GL (what else), and every GLU function in existence into a class known as GLU. Using Swing is out, hardware acceleration does not quite work with Swing, AWT, old, dead, and forgotten as it is, is the way of the future according to the creators of JOGL, this depending on your perspective, can be a good or a bad thing. Clearly history in Java world does repeat itself, and hopefully most Java programmers will be working on learning Fotran compiled to their VM and some form of a weird VM assembly language soon enough, seeing as these are things that shall accelerate the future. Of course seeing as Java was originally intended to power toasters, and has in the recent past been used to power everything and including, very nearly including toasters, I am pretty sure all of Java will do a good job of living up to its originally intended use (I want a Java powered toaster, I want one for the cool factor). Somewhere down there, right after all the JOGL experts were done with writing JOGL tutorials, JOGL developers decided net.java.games was not a good place to put all the JOGL packages, and instead placed everything into javax.media.opengl. Sadly enough everything in the package that was formerly known as net.java.games.jogl, is now contained in javax.media.opengl leading to obvious questions about why the project’s still called JOGL. Now if this was all the JOGL developers decided to change we’d be safe, however life’s never that simple. JOGL implements its OGL functionalities by exposing a GLEvent interface which can be sent event messages by GLCanvas. Until recently GLEvent methods used to receive a GLDrawable argument giving them a GL object on which they could draw and do other OpenGL things, somewhere down the line someone subclassed GLDrawable (or rather subinterfaced seeing as GLDrawable and its children are interfaces), came up with an interface named GLAutoDrawable, and changed everything within GLEvent so they took GLAutoDrawable objects instead of taking GLDrawable objects. This is not a major change, not really anyways, it’s merely fact that it is annoying, auto typing and some of the cool features in Eclipse seem to rely on pulling out argument names from how interfaces are implemented, this really does not help. Also while we are on the topic of Eclipse, if there’s someone out there reading this entry, someone who writes libraries for Java, especially if this someone happens to use JNI, please do not name your arguments arg0, arg1, arg2, etc, I know it makes life simpler while writing libraries out, and it is the kind of thing I am more likely than not to do, it does bad things with Eclipse, it is annoying to be faced with method signatures who’s argument names make no sense, and give you no clue as to what you are supposed to supply. Eventually I will get so used to writing JOGL code that it wouldn’t really matter, argument order would be second nature, I hope it would anyways, but while I am still working on getting there, generically named arguments are sucky and do not help anyone. I am not going to go into the problems associated with installing JOGL thanks to the JNI interface, I am however going to speak/bitch about the entire GLU implementation. So let us see, there were a few bright developers working on JOGL, they worked hard, implemented a native version of GLU, implemented funky constructors which allowed GLU objects to figure out GL contexts and other such things by relying on the thread they were created in, fancy stuff, sounds good, is cool, etc. However let us go back to the day before this funky GLU implementation was released, people lived in a different world. GLU was still dependent upon JNI libraries, and was amongst other things, one of the objects you acquired by calling functions on GLDrawable. Most people would expect these functions would still be present in the new funky GLU world, be deprecated perhaps, but their mere existence hurts no one, there’s a GLU object lying around, GLDrawable could just return a new GLU, doesn’t take much, adds almost no computational complexity, and keeps old code running like new. Well the JOGL developers disagree, at the expense of much of the JOGL code that had been in existence before this new funky GLU implementation came into being, the getGLU method was removed from GLDrawable. Now I am not going to complain about how much of an issue this is when you are trying to use JOGL to simultaneously learn OpenGL, much like I am right now, because at the end of the day, reasonably good hackers are supposed to figure these issues out for themselves, a lack of migration documents being the ultimate sign of machoness in the twisted world of hacking geekiness. However JOGL was designed to promote game development in Java, it’s a project hosted by Sun, I am figuring somewhere down the line the powers that be at Sun will come up with this bright plan to integrate parts of JOGL with Java, perhaps the cellphone, toaster, car and whatever else they are putting Java into these days gaming market wants to exploit the power of 3D hardware rendering and use JOGL, I am figuring they would want some of those big evil corporations which make games to try and use their technology to leverage their fancy games into these markets, and I am figuring these big funky game companies won’t rewrite the code for their games every time a new JOGL release comes along, what happens then, if JOGLs to eventually start being backward compatible, what in the world is wrong with starting now. A year ago, my then advisor, who also happened to be my CS professor, preached in class on the evils of backward compatibility, told us about how backward compatibility was bogging parts of Java down (I believe part of this was for generics and Swing), and kept insisting how much cleaner it would be to just throw a lot of the java libraries away. Well, there’s a reason they don’t do that, use tje JSR release of JOGL and you’d rapidly figure out those reasons…

JNI, there’s little to say about it, there’s a reason most Java developers don’t use it, and don’t know much about it anyways. There are probably all of 200 reasons why anyone would ever want to use JNI, I am stuck with working on one of those reasons, and while I haven’t really started working on this thing, I spent some time going through the JNI documentation, preparing myself for when I do have to work on using JNI, and I don’t like it a bit, enough said.

Cocoa, I am back to a Cocoa fixation after I picked up a copy of Aaron Hillegass’s excellently written introduction to the library/language, and owing perhaps to a recent uninterestedness in both C/C++ and Java code (two of my traditional mediums of coding), I have come to appreciate some of the things Cocoa stands for. Cocoa however is scary in that it is VBishly simple in someways, while deceptively hard in others, and as a sufficiently lazy learner it seems to be a good way of missing out on stuff.

Bah I had grand plans to write more about Cocoa, and about Pattern Recognition which I do wholly recommend (I will warn you about weird thought processes generated by said book), about Symbian powered phones, and other stuff, but it’s late at night. I might convince myself to write tomorrow, I might not, read DrunkenBlog and the stuff about NTP in there, perhaps also about Glogg… It has its good points…

Ze Panda
PS: I believe I was supposed to spew out things about the New Year and the holidays which came before and stuff. Imagine generic greetings added onto previous entry.

This entry was posted on Tuesday, January 3rd, 2006 at 12:37 pm and is filed under article, hope for the future. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.