Dear Netbeans Development Team

Dear Netbeans Development Team;

I’ve been using Netbeans for, wow, as long as I can remember. I switched when the Kawa project folded. I loved Kawa. Netbeans felt like Kawa. It felt like home. So I stayed. I loved the interface and the power. But recently you dropped the ball on SAF support. You promised that it would be okay to use it, even though it would be dropped from the Java spec. You promised that the only thing was that it would not be updated. Maybe, someday in the future, we wouldn’t be able to create projects with it. Okay. Well I’ve been using Netbeans and SAF for a very long time, more than six years. Maybe back since 2002. Not sure. I have code that old but not sure if I was using SAF back then. Of course, if SAF was promoted as the default for new GUI projects in 2002 (it was in 2009, at least) I would have been using it.

But when you released 7.1 and included IF-statements that explicitly prohibited SAF forms from being loaded into the editor, you made a mistake; You did something you had no right to do, you tried to funnel users into migrating away from SAF into NBP (Netbeans Platform). Most of the reasons you gave for your decision were lies or excuses:

1. You said SAF (i.e. JSR-296) was being dropped from the Java Standard and therefore would be removed from Netbeans.
Ok so what is Netbeans Platform then? A JSR? It’s not even a JSR. So dropping it just because it won’t be in Java and then promoting Netbeans Platform does not make sense. If the reason is that it won’t be in Java, then how can we trust you and use NBP? It’s not logical.

2. You said SAF was not supported.
Reality #1: SAF was supported — by several fork teams. BSAF for example. It’s an extremely well known thing in the Java community, yet you failed to bring the BSAF team on-board or consider their work at all.
Reality #2: SAF was supported — by Netbeans. You actively promoted SAF and made it the default for new projects. Then you broke backwards compatibility with no warning, in reverse of previous statements you made that you would not do this. This is an EXTREMELY bad thing, for the reason I am about to tell you at the end of this list.

3. You said that Netbeans Platform was superior to SAF.
Reality #1: It’s not. I tried using Netbeans Platform from the project creation menu. It created a bloated heap of giraffe poo. Why is there a web browser in my new project, and how do I turn it off? You need to seriously think about that and why I was never able to solve the issue. You need to think about how you pissed me off as a developer. Never mind everyone else. We want the features of SAF without the bloat of Platform. Hint: My project is 300kb. Why would I upgrade it to Netbeans platform and have it quintuple in size with no visual benefit?

4. You provided no way out.
No, the “solution” in the form of an XML file which people had to dig thru a buglist to find WAS NOT ACCEPTABLE and did not work on 10-20% of files making the whole thing a pointless effort.
Reality: This was your biggest mistake. You have done this in the past with your Visual Web thingy. You have done this in the past with other technologies. Well, this time you pissed me off.
Reality #2: Sure, for people entering Netbeans today, or people PAID to do it, this is no problem. Welcome to the happy candy land of Netbeans and Netbeans platform. Well I’m not like that, and I am thru with Netbeans forever.
Reality #3: We can’t even use SAF or BSAF as standalone libraries because you put explicit IF-statements in the code blacklisting SAF. I can’t believe you did that.

How dare you do this to me.

Here’s that reason I promised you at the end of the list.

If you’re going to drop the ball like this, users are going to call you on it. You lied. You promised it was okay to make SAF forms. SAF was the default for many years. Many people who just wanted to use Swing were funneled into SAF by Netbeans, then you ripped the floor out from us. So I’ll tell you what. If I have to rewrite my projects in plain Swing, fine, I will.

In Eclipse.

And I will never, ever use Netbeans again and I will relate my story to as many people as possible.

I hope you all burn in hell.


Kongzi Beta-8 announced for June

Okay. Kongzi Beta-7 has been in classroom-use testing for about 6 months now and it seems pretty solid. A lot of changes have gone on under the hood. It’s using a database for the main type of save files now and you can merge (import) data from other files without destroying your user info. This will be tuned as time goes by, but as of now it is solid for general use.


All the quizzes have gotten a swift kick up in power, they now don’t just present random items but will sometimes present items which are similar to the correct answer. To do this I have created an engine which analyzes the user’s expected knowledge level and searches for similar words .This works in any language and with sentences (shown below) as well as with words (shown above).

Another thing which I’ve done is add the list of test mistakes to the score screen for easy studying. The following example is from the dictionary I use to teach “Let’s Talk in English” to Chinese students.


Once I give the manual a once-over and double check a few features on my to-do list, I’m going to have to start looking at how to package this beast.

For one, I plan to blow away the competition by offering a companion textbook with preloaded vocabulary. The MCI Chinese project (see the navbar up top) isn’t dead at all and has actually expanded with sister projects such as MCI Japanese and so forth. Here are some shots of the MCI Japanese book, “Welcome to Japanese”:





As you can probably guess I’m really excited to have reached this point in the Kongzi project and I will be able to package and offer these materials to YOU (well, to anyone) very soon. Target is this summer, around June for a complete Chinese/Japanese/Korean package which will take you from step one to “fluency”.

Thank you for keeping patient all these years. The wait has been difficult for me, too! But it is almost ready now, for real!

Populating Trees and Lists in Java

I’d like to comment on what went into the new Font Chooser dialog for Kongzi Beta-5. The problem can be posed as follows:

Create a dialog box that takes, as input, existing data.
Complication: Selecting a value on some lists will change the contents of the others.

Obviously this sort of design pattern would have important usages; configuration boxes, persistant user profiles, and so forth. Or, for example, a specialized Font Chooser – which is the example I’ll discuss. Take a look at this screenshot from Kongzi Beta-4:

Kongzi Beta-4 Japanese Fonts

I remember how fiendishly difficult this was to code the first time around, so the second time around I was prepared. The problem would be that I had to follow a special order: populate the language box, select the language, then use that event to populate the font box. But then I had to interrupt the normal order of things and populate the font box before I selected the font from pre-existing data. I couldn’t think of a way to do that without cutting and pasting code or creating a very convoluted logic.

But worrying about that before I wrote any code would drive me insane. So I plunged in head first, fleshing out the dialog box in Netbeans, then adding several methods to find and select values in the list, such as “SelectLanguage(String)”. That way whenever I wanted to, I could populate the dialog box with pre-existing data, in this case, the language and font data that had been selected previously. This is important, of course, to provide a smooth user experience.

Then the nasty null pointer errors started. Basically because of the logic/flow problem I described above. The logic for populating from pre-existing data, and the logic to modify itself based on user input, was too difficult to reconcile. When I tried to populate language, the size box wouldn’t be populated yet, so I couldn’t preview sample text for the new language. If I tried to populate the size box first, this would also trigger a preview event which would crash. The workaround in Kongzi Beta-4 was to include a preview button as shown in the above screenshot. Then I was technically excused from having to do anything. But just because I put a button on it doesn’t mean it wasn’t a giant kludge. For Beta-5 I wanted something smoother. I wanted to use the same logic at all times, the same entry points, and I didn’t want a preview button. I wanted selection events to populate everything.

The key to my final solution was in realizing that when I sent commands to the lists, such as fontList.setSelectedIndex(i), I was going to trigger events which would send me back into the auto-population and auto-selection methods. This is how it had to be, to avoid cutting and pasting code, making a terrible mess. Yes, I wanted to follow “accepted practices” of reusing the same code which auto-populated the lists to accept events and propagate their own data to other lists. Doesn’t everyone?

The first idea I had was checking for null pointers and then skipping over those lines of code. I rejected this almost immediately because of the difficulty it would present to doing any sort of error checking. I would in essence be assuming that any time I encountered a null pointer, I knew why it was there; and that was simply untrue. To write proper code, I would then have to write a second check to determine if the null pointer was there because there was a bug, or simply because the dialog wasn’t fully populated yet.

Or, as an aside, populated properly. I saw the potential for sloppy logic to start creeping in, caused by my abuse of checking for null pointers. In horror, I imagined several cases where entire blocks of code would never execute because they would always be called at a time when null pointers were there. I imagined terrifying cases where a population function would be called four, five, or more times, each time getting sent back with a null pointer, until the dialog was finally ready to accept the input. I recoiled from checking for null pointers, and resolved to find a better way.”

After staring into the monitor for a while, I came up with the idea of using boolean flags to keep track of what procedure I was in. The solution worked like a charm. I created several class-wide variables such as “boolean populatingFontList”. Any time a method dialog was performing an operation on a list where the selection would change as an unintended consequence, I simply set “updatingFontList” or “updatingSelectLanguage” (or whatever) to true. Then, at the beginning of that function (and any other appropriate place) I would put in a clause which prevented anything bad from happening. Usually something like “if (updatingFonts) return;” at the beginning of a troublesome function.

populatingSelectLanguage = true;
populatingSelectLanguage = false;

Then when the program fires off it’s little events as a result of you removing whatever item was selected, you wont get an error because the font list isn’t populated yet. And so forth.

Kongzi Ressurection

You may not know this, but after the last blog post (about Kongzi) back in January 2008, a series of unfortunate events pushed me farther and farther away from developing Kongzi.

I’d like to list them here to help ease my mind. And why, because I’ve decided to focus on finally finishing this promising project.

For one, after I had completely removed all the netbeans auto-gui code, I figured out how to turn off reflection in the gui generator. It all came crashing down. “Shit,” I thought, “I just wasted several days of work”. What was worse is that I would have to redo all the forms because although I had a recent backup I was spending so much time on the project every day that it felt inconceivable to me to go to an old backup. Version Control. Yeah I know, I tried that. It’s a pain in the ass. I don’t want to comment on that. I’ve tried many version control programs for unix, windows, whatever – none of them appealed to me.


I text edited the original files and put back the IDE tags I had removed. So I wasted about a week on that whole adventure. But I finished it and resumed working on the project. Then I did something really dumb, I tried to install a version control system. Version Control systems are great – for large, multiuser projects. For something like this it is a TOTAL waste of time. Backups would have been better. So I lost all my work because the version system wasn’t installed properly, or I typed the wrong flag, or whatever. Poof. You know, I had tried to use version control systems before, really. I am not a novice user by any means. But this was the last straw. I actually had a system up and going which backed everything up for me. But losing all my code.. For fuck sakes – and I do not swear in vain – if I am going to have to back it up anyways I will simply not waste my time with a VCS of any kind.

So you know what I did, I did it all over again.

This is late January now. The program was going exceptionally well. I had all the features I had before. Then I did something which taught me a lesson. I started working on the licensing aspect of the program and I got bogged down. I didn’t really want to work on the licensing and the licensing aspect was boring. Slowly the code started to break in places because it had to be slightly redesigned to work with the licensing code I had written. So I lost interest. This is February now and I posted about how I felt but I didn’t say why I had been losing interest.

A few months later I had a motorcycle accident and I couldn’t type or write for a week or two so that was a problem as well. So by this point I was also into guitar and videogames for a while – well I had always been into games like Hitman, Halflife, Max Payne and so on and that sort of occupied my time. That and work. So I had totally given up on the project.

Now, get this. For some reason I seem to have lost my backups of Kongzi.

I don’t mean all my backups. I mean the “recent” backups from February. I’d just as soon snip out all the licensing code and work on the main project a little more but I can’t. So here I am. What am I gonna do.

First I have to justify why I want to do this. Oddly enough although I am working more than I ever have, I see many ways in which I could use Kongzi at work to help me teach English. Especially now that you can get a mini laptop for under $300. What a deal! Or perhaps it could run on one of those phones with windows mobile or a Palm (if they even make those anymore) and so on. I have a lot of ideas. I always did.

I mean, they sell those little electronic dictionaries. I could use that. But with Kongzi I could tailor it to the needs of an English Teacher. I could sell it as a package – a mini laptop and software. I’d make a lot of money like that. Lol. Or something.

So here’s what I did.

1. I pulled up all my old backups. Dec 17th. Dec 30th. January 3rd.
“Aww crap,” I said to myself. I lost a lot of work. Over a week and a half of amazing stuff.

2. I identified the Dec 30th backup as the day before I gutted the GUI code.

3. I put the Jan 3rd backup and the Dec 30th backup into the latest netbeans (installing, which, was an adventure all it’s own but there really is nothing better.. time has certainly shown who won the recent IDE wars)

4. I started bringing the Dec 30th backup “up to speed” with the Jan 3rd backup, minus all the form removal code. File by file. This will serve many purposes least of all refamiliarizing myself with the code.

When I am done, thank god, I also have those extremely convenient screenshots of what I was doing with Kongzi at the time I gave it up, so it should be trivial to redo the ten or so days of work I lost. And given more than half that time was spent on the irrelevant licensinc code… I am actually pretty excited about this now.

All things considered I could have Kongzi NeoBeta ready to accept new code by early October.

By Halloween I should have more work done on Kongzi than ever. By Halloween I expect to start spending most of my time working on the dictionary. By the end of the year I expect I could be completely finished this with a real live distributable CD.

Hmm. Let’s reintegrate that code and look at the screenshots of Beta-4 first 😦

Kongzi Beta News

So much work has gone into Kongzi Beta-3 I almost want to call it Beta-4. But I’ve decided to hold off just a little while longer until the Memory Game is done. Yeah, Memory Game. I don’t know a single program which has that capability – Kongzi might be the first. Check out the new Mix ‘n Match Quiz type i’ve designed. It’s similar to one of Stackz’ features:

Kongzi Beta-3 Quiz MenuKongzi Beta-3 Mix ‘n Match Quiz

Pretty cool huh? Yeah I thought so too. It’s drawn attention to the fact that I need to let the user configure his own fonts; especially because CERG Chinese/Bitstream Cyberbit don’t appear to support Japanese characters; that’s inexcusable for a program purporting to support any language natively. So that will be added in Beta-4, and Beta-4 will begin right after I finish the memory game (which is about 25% done).

Kongzi Beta-3 Flashcard Quiz

I’ve also done a lot of work on the new “Flashcard Quiz” system – which is very similar to how Stackz or Anki does quizzing. It starts by presenting a character, and you can select if you either know it or not. Or you can press space to reveal more information like phonetic or definition. I’ve allowed you to use the mouse or keyboard here – left click = known, right click = unknown. Middle button reveal information. It’s fun and fast for breaking in a new dictionary; props to Louise Brenner for convincing me to do this. I still have to take another look at Anki though. Although it’s rather limited in some ways and crashes a lot, it looks amazing and seems very user friendly – far more so than even Stackz, which is a commercial program. That being said once I got to learn Stackz it was just as fun and fast as Anki or any other program.

Also in Beta-4 I’m thinking of adding internationalization support. This would be important because the program can also be used to study English using the reverse quiz option:

Kongzi Beta-3 Configure Quiz 2

Reverse quiz is explained fully in the user manual (I haven’t uploaded the latest version yet, however). For the uninitiated, it means that if the quiz is, say, a definition based quiz, instead of the (hanzi or hiragana or whatever) appearing as the question, it will appear as the answer; and the definition will be used as the question. How cool is that?

This will allow me to beta test the program in some of the local cram schools. This feels like it could be very powerful for me; where I work there are some computers and the kids are encouraged to play English “learning” games on them like spelling games, whatever. Hell I might even get my first sales locally (I was imagining getting them on the internet). So yeah localization support is inevitable in Beta-4, I would think.

But when am I gonna let you guys taste the rainbow? I honestly don’t know. I don’t want to release a product with sucks because I’m going to be charging money for this, and first impressions count alot in this market. It’s definately almost ready though. It’s fun to use! And I feel much more secure releasing it now that I’ve removed all that netbeans actionmap garbage – it shrinks, obfuscates and optimizes quite nicely now.

I am considering making some UI changes too, like making the dialogs internal to a frame and maximizing the frame. The UI seems a little weird in that the main window never changes. Why is it there? To hold a jmenu? Hmm, a little redesign might go a long way in that department. Windows users aren’t used to this style; I think they would expect a full-screen application like msword or something, even if it didn’t have a lot of features. Maybe I will redesign it graphically similar to glGo or CGoban 2/3. Those kind of graphic menus are interesting and can look very professional.

Ehh well i’ll keep posting updates – and please do contact me if you want to beta test this software. These kongzi pages get a lot of hits (many times what my old tai chi blog would get) but far fewer comments (than the tai chi blog). I guess that’s the nature of this market.

Netbeans 6 Form Designer is Broken

I’ve been using Netbeans 6 (and previous versions) for several reasons but recently my loyalty suffered a massive blow. Simply put I had a run in with the netbeans form designer. You know, that gui builder tool they have. Don’t get me wrong it WORKS, kind of, but what happened after I tried to compress the code for distribution was a nightmare.

Netbeans 6 uses a horribly broken design paradigm for buttons. This is extended on to subclasses and related classes of buttons, such as menu items in a jmenu. What they do is they use some kind of weird reflection technique – for absolutely no reason. Seriously. What makes it worse is that they use inner classes to declare actionlisteners for things like valuechanged on a jtree or list. This is a real mind job because there is no real difference between this and declaring inner classes in the exact same way and NOT using actionmap.

In fact it could be argued that the reflection/actionmap/@action crap is inefficient from a profiling standpoint compared to using inner classes to call methods.

I mean heck – if you are gonna declare anonymous inner classes to call a function for something like a value change on a jtree why the hell would you jump through fifty hoops to use reflection to call a button handler or menu item handler? It doesn’t make any sense. It’s a bloody greyed out collapsed uneditable code block. Why not make it easy on people who will use the code with real world applications? You know like yGuard or ProGuard?

I’m currently in the process of breaking my code away from crappy Netbeans 6 form designer.

I was also pissed off how the form designer locked my code into using netbeans 6. Seriously that jdesktop stuff is GARBAGE. There is no reason why you need it. None. You have .form files for god’s sake, put any data you need in there and keep it out of my lib directory.

But now I don’t need .form files anymore. Oh, yes, I will use them to design and prototype, but the final product won’t use them.

And I swear I’m going to try out eclipse later on and I know my code will drop in compile (or should) because it won’t be using any IDE-specific libraries (!).

I miss kawa. I really do. Life was simpler.