Okay, so this probably doesn't par up to the JFK assassination, those crop circles, or how in the world John Locke can survive a bullet in the chest, but it's starting to really bother me.

I developed jSeamless with the intent of "seamlessly" bringing technologies together to make life easier on the developer. However, I'm starting to realize that the people that make these technologies would rather not see this happen. I never considered that anyone could understand the concepts of what I'm trying to do and actually put in some extra effort to stop me. I figured at worst people would just not care and let it pass by without another look, but that's not what seems to be happening.

First Point - Java.net

Now that jSeamless has become much more stable and has the majority of features necessary to release I thought java.net would be the place to go to get some good advertising. So I filled out a form requesting that jSeamless be featured along with an article I had written hoping to get some additional developer interest in the framework. After a couple weeks I e-mailed the editor and asked about it. The basic summation was that it would be a conflict of interest to post anything on their site about jSeamless since it directly competes with Swing because it uses Flash as the reference implementation. Now, I can understand if the purpose of jSeamless was to only do Flash development, but jSeamless is about abstraction and it just so happens the only currently completed implementation uses Flash content. I was told to send them another e-mail when there's a completed Swing implementation...we'll see how that goes.

Point Two - FlexCoders

I hang out on the FlexCoders Yahoo! Group to find answers to problems I'm having with Flex integration into jSeamless and to find out new extensions that are being written to Flex that I might be able to integrate or derive ideas from for jSeamless. I decided to post a message to the group asking for feedback from the Java developers that are also developing in Flex to get some ideas of what features they would look for in an API like jSeamless. I actually got some really good responses, I messaged back with additional information and then suddenly all the posts disappeared without a trace.

There was no e-mail letting me know I had violated some rule of the group or anything. I know the group is run primarily by people that work at Adobe, so I can only assume it had to do with marketing a framework that could take away revenue from their commercial products.

There actually several other scenarios that have had similar results, but I'm really starting to feel a lot of resistance for this system. I never imagined that I was developing something controversial or even something that would get anything worse than indifference about. This causes some problems since I was hoping to get some support from companies like Adobe or Sun in the long-run, but it would seem they don't really want such a project to succeed.

I guess this doesn't really classify as real conspiracy, but it bugs me so I figured I would share my annoyance with the world. :)

No, in a good way. :)

We've been working through a lot of stress testing at work for jSeamless to prove that it can stand up to an unreasonable load only exceeded by getting "slashdotted. We have faired quite well and we're currently working to get the document released for public "consumption". This will be a really great proof of the stability of jSeamless and put to rest a lot of the fears people have of its viability in a heavy traffic scenario.

I generally post a message in my blog after I've already done it, but this time I'm trying something a bit different and posting the idea as a mechanism to draw it out.

In my jCommon project I have Object Pooling support already, but it's explicitly limited to the pooling itself. While developing Galaxies Beyond I'm finding there are some things that would be useful to support in the pooling that would simplify usability in application. Currently you simply get() for an object from the pool and it will create the object if it doesn't exist and hasn't reached the maximum number of objects allowed for that pool or return an object that is in the pool. This works fine in most scenarios, but for more advanced pooling I need to cleanup after an item has been returned to the pool and perhaps re-init certain things when they are actually pulled from the pool.

...okay, after I got done typing all that it dawned on me that I might have already written this before. Sure enough, ObjectPool in jCommon already has support for all of this. Perhaps this should be changed to "How sad is it when you write so much code you end up re-inventing the same ideas over and over again?", but what's particularly sad is I've done this on various occasions. In fact, I wrote similar functionality for ObjectPooling in jME before I remembered that I had already created the object pooling support in jCommon. What makes it even worse is that the code I wrote was better the first time.

I'm 28 years old and if my memory is this bad now, I can't imagine what I'll be like at 80. In my defense I will state that I write thousands of lines of code a week, so there is a LOT that can be forgotten. :)

Yeah, I've done it again. I'm well known for reinventing the wheel and this is no exception.

As I've previously mentioned I decided to write a Multiplayer Sudoku game that you can compete with other players online playing. Well, I sort of got stuck for a while on the puzzle generation. I hate the idea of hard-coding puzzles and pulling from a list when it is something that could be generated. Yes, I did look around for other APIs to generate puzzles, but they either weren't in Java, were very poorly written, or were tied to a UI (like AWT or Swing). Sure, I could have made one of them work, but I decided that if I teamed up with my Wife I could create an awesome API that I could make open-source and then anyone else venturing for such a solution in the future wouldn't have the hardships I had to deal with.

On that note, I've gotten the actual solution generator written. It works quite well generating a solution in about 200 milliseconds on average. I still have to write the puzzle generator that takes into account difficulty, verification that a solution can be determined logically, and that there is only one solution. However, the majority of code I've already written can be reused for most of it.

I'll be posting a link to the project when it's completed so anyone who wants can use it. It won't be too long after that's done that I'll have it plugged in and usable in my jSeamless Sudoku game.

It's a little odd that I'm creating a Sudoku game at all really...I've never really enjoyed playing them all that much, but I do appreciate the logic of the game. My wife is much more interested in it than I am, so I'll just say I'm doing it for her. ;)

I've been trying to think of some good examples of jSeamless that wouldn't take too much time to write, but would show the power of jSeamless and some of its capabilities. To that end I've started developing a multiplayer Sudoku game. The puzzle is generated and displayed to all connected players. As each person provides a correct number they get points and that field is "solved" on all other player's board as well. If you get a number wrong you lose points. A winner is decided by how whoever had the most correct numbers in that puzzle. I'm creating a whole account management system, scoring system, database logging and statistics, and internal chat. This should be a pretty fun game when it's finished.

Here's an early screenshot:

I have to present a prototype in a couple hours that is really important to my job and the company I work for. I think I'm pretty well prepared, but have been trying to go through any last minute details and bug fixes to make sure nothing breaks horribly well I'm demonstrating it.

It's at a time like this that my brain decides to recall a poem I wrote in the third grade. Now, I'm not really sure how I got there, but now that I have I decided I'd write it down because I still like it. :)

Tomorrow is Today, if Yesterday had never been,
Today is a day that will never come again,
Now is the the time that always will be,
Time is the variable, only the mind can see.

Not bad for a third grader, huh? ;) Well, back on track I'm really excited about this demo as it is the largest application I've developed yet utilizing jSeamless and this demonstration is about getting more buy-in for the product, the framework I've written, and jSeamless from the company I work for. Next week I'll be able to start adding massive new features to jSeamless (I couldn't until this demo was completed for fear I'd screw something up).

Anyway, this will hopefully be a short day for me so I think I'm going to go home and spend the rest of the day with my wife...I love Friday. :)

Adobe Flex 2.01 is a very good framework and it is so much better than practically any other web-based UI framework in existence today, but there are so many bugs in the code and so many restrictions that are very difficult to get around I'm locked into a love and hate relationship with it.

I'm using Flex for the reference implementation of jSeamless and it is going quite well over-all, but I'm finding myself re-writing component after component because of either bugs or lack of features. The good thing about this though is that the entire Flex source code is available within the SDK, so I can see exactly what they are doing and how they are restricting me or causing bugs to occur.

My single biggest complaint about Flex is their complete lack of threading "support". That is not to say it is single-threaded. Quite the contrary. Everything is asynchronous in Flex, but thread-safety is an unknown term to the Flex team I believe. There is no way to synchronize, lock, or maintain good concurrency in the system and many a crash has been due to this. In jSeamless I have a full system I wrote to offer some concept of synchronization and though extremely limited because of ActionScript 3 support not being there, it works pretty well.

I'm about to completely re-write the way Effects are called in the Flex implementation of jSeamless because it is causing errors to occur and also offers no way of disabling effects. I'm a Java developer and writing in ActionScript 3 is really not my idea of a good time, so every line of code increases my frustration.

On the bright side, jSeamless has far exceeded the capabilities of what Flex can do because of its "flexibility" and for that I'm extremely thankful.