The reality is that one particular Java runtime has been deprecated: the one that Apple write themselves. Java as a language will still be available, only it won’t be Apple that writes it and possibly it might be an optional download.

The confusion is because up until now there has really been only one Java runtime on the Mac, which Apple wrote themselves using code licensed from Sun. Now Apple has chosen to discontinue their own particular runtime, but this doesn’t mean that there won’t be any Java at all.

There are already alternatives, in particular the OpenJDK and SoyLatte variants; a little rough in places possibly, but they definitely work. Undoubtably in time they will improve and others will appear, including possibly an Oracle one.

Obviously it would have been nice to have the deprecation notice and an endorsement of another runtime made at the same time, but given how long it will be until the current runtime becomes unsupported, I’m not terribly concerned.

Also, whether such a future Java release has a native visual appearance is not of virtal importance. While the Apple Java team has made enormous efforts to get it to look and feel native, it takes quite a bit of work to create an application that looks seamless. The very first version of SQLEditor was a Java Swing application and although it looked fairly good, it was taking too much time making things match exactly. Switching it to a native cocoa application made my life much easier (but killed off any immediate hopes of a Windows version)

I think most people accept that Java Swing apps don’t look native and will accept that the visual appearance will differ.If you want a truly native feeling Java app in the future you should look at SWT or better Rococoa, not Swing.

What is important is that future Java runtimes don’t require X11 for Swing. But I’ve seen good progress by several projects towards this goal and I’m not worried about it either.

Ideally of course, Apple would release their Java Runtime as open source, but whether they are in a position to do that with respect to licensing is unclear.

Having seen the deprecation notice last week and been somewhat concerned, I’m now fairly confident about the future of Java on the Mac,

1.6 is something that I’ve been working on now for a long time, it is essentially (the unreleased) version 1.5 with improvements and updates. In particular it contains a SQL parser that was written using ANTLR and a new JNI based system for using JDBC drivers with support for Java 6 JDBC drivers.

It’s also the first release version of SQLEditor that is compatible with Snow Leopard. SQLEditor 1.4.7 and earlier had an unusual architecture. When I originally started writing SQLEditor, it was a Java application with a Swing user interface. After some development it seemed clear that java swing was proving limited in some ways. I rewrote the user interface layer in Cocoa, leaving the model layer in Java and using Cocoa Java to connect the two parts together. The application development continued and new versions were released. Eventually though, Apple decided that Cocoa Java was not the future and decided to deprecate it.

Work began immediately on rewriting the crucial components of SQLEditor, although there were some issues.

The first was the model code. Every object in an SQLEditor document is represented by an object and all of the code for these objects was written in Java. All of the object code was rewritten and tested against the earlier versions to check that it still worked. It was very important that files from previous versions continued to work (and as far as I know all of them so far do). New code was written to read and write the SQLEditor document xml format.

The second major issue was that the database interface used JDBC drivers, which are written in Java. Native code would use ODBC drivers. Although similar this might mean that users wouldn’t be able to use existing arrangements to access databases.

Eventually code was written to bridge between SQLEditor native code and the JDBC drivers using the Java Native Interface (JNI).

The other crucial problem was the SQL parser. This is used if you paste SQL code into SQLEditor or if you import a file. The SQL parser was written using JavaCC, a parser generator that is written in and produces Java code. Several parser generators were looked at to replace JavaCC and eventually ANTLR was chosen.

A new SQL parser was written and tested during 2009 in ANTLR and is included in SQLEditor 1.6. The new parser is completely rewritten compared to the one that existed in SQLEditor 1.4.7 and no code is shared between them.

A major step in developing the new parser was to port all of the SQL test cases from Java (in 1.4.7) to objective C (in 1.6). These automated unit tests are run against the parser to ensure that the new parser behaves correctly compared to both the 1.4.7 parser and the assorted SQL standards.

It is still something of a work in progress though, there are things it doesn’t support and it’s still being actively worked on. One particular thing that makes this somewhat harder than it might otherwise be is that it must accept SQL in several different dialects, not just a single standard.

SQLEditor 1.6 also included user interface improvements and various performance fixes.

Overall it’s an improved program, although I do wish that it had been released sooner.

Thanks to everyone using SQLEditor for your patience and also for trying the beta versions.

Unfortunately there were a couple of bugs that slipped through relating to clicking objects.

These are going to be fixed in a point release that should appear soon.

The new version is available from the automatic update system or download here:

Download

3.9MB dmg File Change Log Product Notes Expires 21st January 2009

There are some things that may need to be improved, but I’m fairly happy with the first revision of this.

Diagram showing compound foreign key

The compound foreign key object is a new table level object that you can add from the Object menu just like a field or index. Then you drag from the foreign key to the target table. Finally you use the inspector to create pairs of columns to link together.

When importing from a database SQLEditor will try to create field-to-field links on foreign keys with only 1 pair of columns unless you tell it otherwise. (There is a new preference to do this)

Support is fairly complete, SQL parsing, database import, database export and SQL export are all available so it should work fairly well. I think the only thing it doesn’t do is auto-create indexes, so you may need to do this by hand on referenced columns (for those databases that need this)

There is naturally a new inspector palette to go with the table object.

Compound foreign key inspector

This allows you to add pairs of columns using the + button at the bottom. Choose your columns using the little popup menus.

The whole thing is completely new, so please send in your thoughts to the usual address.

Download SQLEditor 1.4.4b1

(or enable the “Check for beta versions” preference and then use the check for updates feature)

http://dittverk.no/mac/files/tag-editor.php

And SQLEditor is on this list

SQLEditor 1.4b2 is now available, which is pretty much bug fixing against 1.4b1.

There were several issues with 1.4b1 including an annoying bug that would sometimes delete foreign key connectors when you deleted an unrelated table.

There are some fixes for other bugs which turned up and some improvements to undo/redo, to make it more stable when you undo or redo lots of things, one after the other.

I’ve also moved SQLEditor to Sparkle. Sparkle replaces an update system that I wrote myself and it should offer better update support as well as a nice html based ‘what’s changed’ window.

SQLEditor also now tells people that it is a beta and exactly when it will expire. It probably should always have done this, but it does it now, which is probably good.

There are also some minor fixes to the live source view, so that it changes with the document sql dialect and appears correctly when reopening existing documents.

[Download] (3.4MB DMG File, changelog)

(It seems to be a blogging day for me?)
Gaming seems to be one of the big things at this year’s WWDC keynote. EA is apparently going to be doing simultaneous releasing of some games this year including Harry Potter. This is interesting because EA is so important in mainstream gaming.

Whether EA will follow Blizzard in putting both games on the same CD (hopefully YES) or have separate releases for the two platforms will be a point to note. Dual platform releases like Blizzard are great because it means that you can buy Mac games at mainstream gaming stores and the titles then get released on budget labels (often with the Mac part still attached). I’ve picked up several of the Blizzard games at my local branch of Game here in Edinburgh this way as impulse purchases.
(Of course where this leaves the Mac Porting development companies is anyone’s guess)

They also had John Carmack doing a demo of 3D stuff which looked interesting, but, since I’m reading a transcript and looking at photos, doesn’t really make as much impact.

The main things I’ve been working on:

1) SQLEditor. Lots of things are being worked on. The user interface is being rewritten to improve speed and increase flexibility, the data layer is being rewritten to switch it to cocoa (instead of java), the JDBC code is being rewritten to make it use JNI instead of cocoa/java and a new crash reporting system based on Google BreakPad is being worked on. There are also some other things too like live source view and assorted bug fixes.
2) HTMLValidator. Also undergoing development. It recently moved across to use Sparkle (yey!) instead of the SQLEditor derived update system (which will also be replaced eventually). The final 1.0 release is due very soon now and several people have set in nice comments.
3) A new idea (still secret)

4) Web site improvements for malcolmhardie.com. Some have been deployed, others are still waiting to be deployed. Although the biggest one which is almost entirely invisible is the rewritten order processing system, which now supports multiple different products and better management features. But only I (and my somewhat-trusted minions) will ever see it.

Then when I’ve not been working I’ve been playing Pikmen on my new gamecube. (Many thanks to Leynos!). I’ve wanted to play this game properly for years and years and it definitely meets and exceeds my expectations.

Although I also played some theme hospital this morning using Parallels 3.0 (new release). It runs really nicely, although since it is an ancient game (1997) this shouldn’t be too surprising. I hope to try out some of my other really old games to see how they perfom under parallels.

http://video.google.com/videoplay?docid=6765603919277760697