Using automated tests takes some getting used to, but once you start you'll never go back. And JUnit is the authority in this area, so yah it's good.

Test suites do take some maintenance: normally if you change the behaviour of a method/class, you only have to update the client code, now you also have to update the tests. But this is trivial compared to the benefits.

With a comprehensive test suite, you're free to make major implementation modifications without fear, and without the need to perform extensive manual testing afterwards (as long as your tests accurately represent how you're using the code in the project itself). This is even more benificial in team development, were developer B can modify developer A's code without fear of breaking the behaviour.

I also use unit tests to help in design: by writing the test case up front, I get a better idea of how the class will probably be used, and what clients may end up doing to try and break it.

There's nothing like the warm fuzzy of changing a thousand lines of code and then having 0 errors in your suite of 500 tests.

Key bindings are all configurable in Eclipse now, too, btw.
(Preferences->Keys)

The new default bindings have been done to better prevent collisions between all the plugins out there.

The 'build' actions have been modified in this release. There's now a 'Clean' action instead of the previous 'Rebuild'.

As a result, 'Build' and 'Build All' are always disabled when you're in autobuild mode, unless you do a 'clean'.

If you're in autobuild, the manual build options are really quite pointless, anyway (I never used them in 2 years of development).

Well other than needing to be Webstarted (hint hint)...

The flickering red outline when you move the cursor over a square is pretty annoying. I'd prefer a clearer (and more steady) indication that it's a valid move.

The AI seems nicely done: quite competetive. I remember writing an Othello player once, and it was certainly a challenge. Did you implement a depth-based search, or does is just follow some standard optimal rules?

All in all, a good job, I'd say.

Probably has more to do with the JIT. AFAIK, the server VM is much more proactive at determining which methods it should JIT compile. Whereas the client VM waits until it actually sees a hotspot before it compiles.

Try moving the code into a method, calling it a couple of times, THEN perform the benchmark. This should give the client VM time to compile the method, if this is indeed what's happening.

Iterator.remove() is safe to call while performing at iteration (that's the reason it exists), so that shouldn't be it.

Do you by chance have another thread playing with the list?

Actually, of primary importantce, it's critically lacking is an active development team

I've used BeanShell in a couple of projects. It's quite nice, except for performance: it's extensive use of reflection to access Java classes ends up creating a lot of small objects (eg. every call must create an object[] to pass the parameters). This causes the GC to kick in too frequently for any chance at realtime performance (if you call a script every frame, anyway). This was under 1.4, so maybe 1.5 has some upgrades that can handle this better, haven't checked.

One other language I looked into (but didn't get a chance to use in practice), was DynamicJava. It has many (though not all) of BeanShells language features, but compiles down to bytecodes, so it's fairly optimal performance-wise. The project seems inactive now (last update was mid-2002), but it appeared stable an feature complete. Plus the source looked fairly clean, so hacking it shouldn't be too scary.  Interpreter is a big bigger (~450k).

Snacks for thought.

Storing them on the client should be fine, and there is a way to keep it secure.

Instead of the client just sending the final result, have it send the entire 'path' of the conversation (I'm assuming you're using an option/menu-based system here). If the client sends every option the user selected, in order, then the server can validate these against it's copy of the conversation: if the client has altered the convo in any way, it'll be quite apparent.

705 fps, Win2K, Althon XP 2200, GeForce 3 (non-MX)

So pretty much like before...but task mgr shows almost exclusively all in kernel time.

Are you challenging the size of my thingy---uh, video card? have at ye!

No, it's a non-MX. After a reboot (been running for over 10 days now, amazing) I got  685fps. Then after dropping my screen res (from 1600x1200 to 1027x768) I was getting ~700fps.

I haven't tuned this thing since I got a new mobo, so susepct I'm missing a setting somewhere, as it seems fill-limited somehow. Hmm, something to play with now.

Morbo

I got 675fps sustained, almost all in kernel time (>90%).

This on an AlthonXP 2200, GeForce3 (+latest denonator), Win2k, Sun JRE 1.4.2,.

I love circles...

You're describing Smalltalk (the original OO language), Cas. The language grammer describes statements as noun-verb pairs. So if you have a string 'name', you can do things like:

name lengthOf - calls the 'lengthOf' method on name
name + name2 - calls the '+' method on name sending name2 as a parameter

Though smalltalk doesn't call them methods: they're events.

It would be interesting to see if one could create a Smalltalk-like language that compiles to bytecodes. Hmm...

There's a setting in Preferences->Java->Organize Imports that allows you to specify how many classes imported from the same package will cause a generic * import instead.

Changing a collection while iterating through its elements is inherenty unsafe, and officially unsupported by all java.util collection objects.  Iterator was created to address just this, as it provides a safe way to remove elements while iterator (unlike enumerator).

I'd guess they tightened up some code in the recent JRE upgrades, and your code as listed should (by spec) result in an exception. So bascially you were relying on undocumented behaviour.

In the latest Milestone build of 3.0 (M6, I believe), there's a compiler option in Preferences->Java->Compiler->JavaDoc to generate errors/warnings for missing javadoc comments (based on visibility). Just turn that on and do a build, all your undocumented members and methods should show up in the Problems view.

Or, rather than making changes to the language, you could use an IDE that manages imports for you. Using Eclipse, for example, I rarely even think about imports anymore (one keystroke adds imports automatically, all I have to do is resolve ambiguities).

This is probably due to 'cache trashing'.

In the single loop case, you're alternating between arrays, which causes a cache fault, forcing it to both save out the changes to the first array, then load up the second. In the two loop case, a single array stays in the cache until it's done with, resulting in less hits to the system memory.

So what you're basically seeing is the difference between direct memory access and cached memory access.

Tribes 2 implemented a network model like this:

http://tork.zenkel.com/uploads/pdf/TribesNetworking.pdf

They broke network data down into different categories and handled each one differently, depending on the application needs. Seemed to work pretty darn good, too.

The platform doesn't contain the Java tools, you need to add the JDT to it, or just download the JDK (which includes the platform, jdt, plus tools for creating eclipse plugins).

No, it's more of a human factors issue. Tests have shown that that human eye can't 'see' at any more than 60Hz, so anything faster is really just information being lost.

In that case, you need a polling behaviour: one that triggers based on time and checks for relevant external events. For example, if you wanted to trigger based on network traffic, I'd setup a behaviour that wakes every 100ms (or whatever resolution you want), and checks for network traffic/queued events, then enables the relevant behaviours from there.

That code doesn't work, because as you mentioned, only a behaviour (or other wakeupcondition) can trigger another. You HAVE to have the behaviour waiting on some condition.

What I did was have a behaviour that ran every frame, and it checked for various conditions that would result in other behaviours being triggered. This because the suite of available WakeupConditions didn't fulfil all my needs.

I spent many an hour trying to find a good solution for this. The only solutions I came up with were: a) run the triggering code from within a behavior itself, or b) use AWT events and use a WakeupOnAWTEvent.

a) doesn't work well for intensive code, and b) can be tricky to make work, as AWT events come from other sources as well. Take your pick

You could use a ViewSpecificGroup (introduced in 1.3). This allows you to control which View(s) a group is rendered to.

It used to be that final would help with inlining, but not since Hotspot 1.3, I believe.  Hotspot is now smart enough to consider a method for inlining as long as no other loaded classes override it (basically, no other variations of the method exist).

Short form: only use final when it makes sense from a design perspective.

Eclipse always loads all the projects it knows about. This usually isn't a problem, since the files themselves are only loaded on demand, so there's no overhead unless they're actually used.

What can get annoying is that you can end up with a lot of projects in the list. To avoid this, you can close the projects (right-click, close), and then filter out all closed projects. Or, if you right-click on the project, there's a 'Go Into' option, which makes that project the root node of the naviagator tree.

Check out the eclipse.org search page, there's tonnes of info on this archvies in the news search.

If you make a change to the scene graph, the screen will automatically be refreshed.

To trigger the change, you use Behaviors, which are objects in the graph that get called when certain events happen: like a certain amount of time passing, or a change in the graph.

A seminar at the last JavaOne covered this situation. There is still a small overhead in the try/catch handling itself, but Cas is right, most of the expense is in filling in the stack trace. A constant throwable should give you better performance.

Eclipse has a nice debugger. Easy to use, plus lots of features I haven't seen in other debuggers. Very configurable views, too.