It's been a while since I contributed something to the open source world, mostly because Java class library and our LookingGlass source base are enough for a lot of things. However, I needed a JLabel that can word wrap. I found MultiLineLabel, which was pretty cool initially. Then, as I revalidate()'d my swing containers, it started to act strange. I reported it on the website and proposed a workaround.

I should update our Drupal and get rid of these bots spamming. Dang captcha why did you fail me? Maybe I'll try reCaptcha this time. I hope it's just a captcha solving problem and not a backdoor.

developing with open-source libraries: you know what's what and act accordingly. you don't develop the habit of "magic code". you get used to acting right-to-the-point and become a better programmer. 

developing with closed-source libraries: you read and trust the api docs. docs are often imprecise, and cumbersome (after all, how efficient would it be to read what mona lisa looks like rather than just looking at the painting?). you grow accustomed to not trusting, you start speculating rather than knowing. you get used to doublethink, fail to hold a precise model of what's below. these habits make you a worse programmer. 

as you keep working with closed source libraries, you learn to ignore api docs and start trusting little chunks of experimental code. you start to reverse engineer and become something other than a good programmer. 

therefore, you have to open source your libraries if you want a quality programmer base around it, as well as deeper and more innovative apps. hear me apple! 

Gotta run home!

Alright, I'm so happy I found the source code for JMF: 

http://forums.sun.com/thread.jspa?threadID=5351339

It's a shady forum post linking to the zip, but it's there. 

I've had many personal programming projects started with great ambition, and abandoned in a short time. I think it was mostly me being too much of a perfectionist and setting high goals that if achieved would become great things. However, the amount of time I was able to allocate was usually much less than enough and most of them didn't become anything. My design philosophy was usually top-down, I had this goal in my head that I had to reach, and if there are obstacles on the way, I wouldn't avoid them, rather conquer them and make them behave. This usually resulted in spending too much time fighting the obstacles, fixing a buggy library, making something behave, etc. While beating those obstacles was fun, it would suck up most of the time that I was able to spend for that project and would not result in its completion. 

But now, I think I've found a great way to get personal projects done. Rather than setting the goal well in advance and trying to beat the obstacles on the way while sticking to it, having a vague idea on what I want to do, identifying what kind of low level abilities I would need, creating small proof-of-concept applications to make sure I can do them, and gradually getting closer to the actual goal that evolves over time seems to be working much much better. This is a bottom-up approach, while keeping the top in mind. This makes me spend much less time on fighting dragons and enables me to avoid them while moving towards something close to the actual goal. While slaying dragons is a lot of fun, being able to reach the target in the end is much more rewarding and opens up many more other possibilities. 

It's amazing how so many companies are rolling their own app stores. It seems Intel will also have one through their Moblin platform. I'm hoping to install it and play with it one of these days. 

Well, their website also runs on Drupal. Which goes to show how awesomely successful this CMS came to be. *tips hat*

Here's a JNI proof of concept that is mostly a note-to-self:

JNI PROOF OF CONCEPT

Eclipse tool settings:


C:\Program Files\Java\jdk1.5.0_19\bin\javah.exe
${workspace_loc:/${project_name}/bin}
-jni ${java_type_name}


select class and fire the tool.

Java class with native method:


public class NativeUsingClass {
static { System.loadLibrary("JniProofOfConceptDll"); }
native public int nativeFunction(int a, float[] b, double c);
}


C++ funcs use that header. Eclipse CDT needs -Wl,--kill-at in its miscellaneous linker flags and jdk/include and jdk/include/win32 in its include paths. The dll needs to be in -Djava.library.path="/dll/dir";

Oh boy. Everytime I mess with JNI it has to turn into a nightmare... This time it's about Eclipse CDT.

Eclipse CDT is awesome. Much better than MSVC, no comparison. However, it uses MinGW and this results in problems every now and then. Here is one such problem:

I wanted to create a JNI DLL using Eclipse CDT. While MSVC exports functions with a leading underscore, CDT with MinGW doesn't. So, here is what the exported functions look like in each:

MSVC: _Java_mypackage_MyClass_myMethod@8

CDT: Java_mypackage_MyClass_myMethod@8

And since JNI and MSVC work fine, DLLs that you create from CDT don't. You get something like this as an exception:

Exception in thread "main" java.lang.UnsatisfiedLinkError: myMethod
at mypackage.MyClass.myMethod(Native Method)
at mypackage.MyClass.main(NativeUsingClass.java:14)

So I tried hard to see why is this underscore thing is happening, and sort of concluded that the underscore and @ are there for the stdcall convention on Win32. Even though gcc says so, too, CDT just doesn't add that underscore.