Java 8

I just finished reading Java SE 8 for the Really Impatient by Cay S. Horstmann. I'd recommend it as an introduction to Java 8 features. I've also read Cay's Scala for the Impatient, and used his Core Java books for reference. No doubt there will be other Java 8 books arriving soon. Pragmatic Programmers has Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions in beta. And Manning has Java 8 Lambdas in Action in Early Access. But unless I'm in a rush to learn about something, I don't usually go for beta or early access versions because I'd rather wait and read the final product.

Java 8 has seemed so far in the future that I haven't been thinking about it much. But I see it's supposed to be released in March, which isn't really that far off.

If I was starting a JVM project from scratch, I'd probably lean towards Scala. But for maintaining and improving the jSuneido Java code, I'm looking forward to Java 8, especially lambdas.

The current release version of Eclipse doesn't support Java 8, but there are early access releases available. Presumably support will be included in the next version of Eclipse. Intellij also has early support for Java 8.

Netbeans may be the best bet right now. Version 7.4 has Java 8 support, and the beta for Netbeans 8 is available.

jSuneido Network Bug

Our installations run a scheduler as a client. (On jSuneido this could probably just be a thread on the server, but cSuneido is single threaded.)

On Windows, when we shut down the server, the scheduler will exit. On Linux the scheduler would hang.

I narrowed it down to a simple test case (on OS X, which seemed to behave like Linux)

1. start the server
2. start a client REPL
3. from the client,execute: ServerEval("Exit")
4. server exits
5. client hangs (on Linux but not on Windows)

Strangely, if you killed the server (with Ctrl+C) then the client would get an exception instead of hanging.

I assumed that the client was blocking when it tried to read the response from the ServerEval (which never came because the server had terminated). And that on Linux, for some reason, it didn't recognize the socket was closed when it was blocked reading, although that didn't make a lot of sense.

I ran the client in the debugger and when it was hung, I paused it to see where it was. Sure enough it was in the socket read.

I searched the web trying to find anything related. There wasn't much, which was surprising. Most problems like this are documented by someone. 

But I did notice some of the code examples were checking the return value from channel.read and I wasn't. The documentation said read returns -1 when "the channel has reached end-of-stream". That didn't sound like channel closed to me, but it seemed like I should be checking it anyway.

And that was the problem. It wasn't actually blocking on the read, the read was returning -1, but I was looping until I read all the data, and that's what was hanging it.

To verify, I restored the code, made it hang, and checked the CPU usage - sure enough the client Java was at 100% (because it was in a tight loop calling channel.read over and over).

I'm still not sure why killing the server behaves differently from exiting normally. I guess the socket gets closed differently. (i.e. gracefully or not)

In hindsight it seems like an obvious bug in my code (not checking the return value). I think what threw me off was that it worked fine in Windows. Java is usually pretty good at hiding operating system differences, but not in this case.

Building cSuneido with Visual Studio 2013

It's not that long ago since I switched to building cSuneido with VS 2012, but after listening to some Channel 9 podcasts about enhancements to the C++ compiler I figured I should give the new version a try.

Note: Confusingly, Visual Studio 2013 = Visual C++ version 12 - off by one error :-)

The version I'm using is the free Visual Studio Express 2013 for Windows Desktop.

I started a new solution and projects rather than convert / update the existing ones so I wouldn't bring over any undesired garbage. Of course, starting from scratch meant running into some of the same errors as other times, but at least it's a little fresher in my mind this time.

One advantage of VS 2013 is that it came with support for building XP compatible applications. Originally they didn't have this in VS 2012 and it was added later (probably after the outcry from developers). I'd prefer to drop support for XP but we still have a lot of customers running it. We're working on getting them to upgrade.

I fixed a few more warnings in the code that the new compiler found, but other than that it went pretty smoothly.

I haven't measured the speed of the resulting executable, but from running the tests etc. it doesn't seem like there's significant difference.

Assuming we don't find any problems we'll switch to using this version for our customers.

As usual, the code changes and the Visual Studio solution and projects are in version control on SourceForge. If you try building it, let me know how it goes.

A User Interface Detail

I recently read Microinteractions. (recommended) It gives lots of small examples of user interface/experience, many from Little Big Details. Which made me think of one detail from Suneido.

In Suneido's IDE, the LibraryView code editor has tabs, like a lot of editors and IDE's and other software like browsers. Suneido uses the Windows tab control - pretty standard.

The Windows tab control lets you put an icon on the tab, again, nothing new.

We also have a right-click context menu on the tab with the usual option for closing the tab. But that's awkward if you want to close multiple tabs. I wanted a "close" button on the tabs, like you see in a lot of places, eg. Chrome

But the Windows tab control doesn't have an easy way to do that (AFAIK), so I "cheated" and just switched the icon when you moused over the tab. (Note: You still have to click on the actual close button, clicking anywhere else on the tab just selects it.)

Although I did it that way for expediency, it turned out to have a few nice benefits. One is that the close button doesn't take up space on every tab. Eclipse only shows the close button on the current selected tab, but it still reserves the space for it on all the other tabs:

But the benefit that I really like is that you can close a series of contiguous tabs by repeatedly clicking the close button of the leftmost one without moving the mouse. Whereas when the close button is on the right hand side of variable length tabs, you have to move the mouse to a new position after closing each tab. Chrome has mostly fixed length tabs, but they shrink/expand when required which still throws off the positioning. Admittedly, in some cases you could use the right-click context menu to close all the tabs, or close all except the current one. But this is simpler and also works to close N contiguous tabs by simply clicking N times in the same spot.

The downside of not always showing the close button is that it's not as discover-able. But in this case I don't think that's a big deal.

Obviously this is a pretty minor issue, but it surprises me that other tab controls (AFAIK) haven't used this approach.