Angus Thinks

Category: Writing Software

  • Mac OS X will still have Java in the future.

    There has been lots of stuff written recently about how Java on the Mac has been deprecated.

    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,

  • Apple WWDC videos

    Brilliant work on Apple’s part in releasing all of the WWDC videos to registered developers. In previous years these were only available for a fee (I seem to remember $500), so including them is very nice.

  • Big changes to Mac Developer Program

    Apple have rearranged their Mac developer program so that it now costs only $99 and seems to have only one paid variant rather than the three previously available. (Student, Select, Premier). The online only variant is still available and still free of charge.

    It appears that this is possibly influenced by the amazing success of the iPhone developer program, which is also $99.

    Anything that makes it easier and cheaper for developers to develop applications is probably a good thing. Although obviously you only need this developer program if you need access to pre-releases of Mac OS X and the other benefits it provides. It isn’t now and never has been a required purchase.

    They’re still upgrading the sites as I write this, so I haven’t seen all of the details yet, but definitely looking good.

    [edited to correct information about the free online program]

  • Rails Migrations and Schemas

    • A schema.rb file is typically a ruby script containing a call to the ActiveRecord::Schema.define method.
    • A rails migration is a ruby class which inherits from ActiveRecord::Migration and contains a method called up

    The useful fact that I realized only after doing some ultimately unnecessary work today is that because the schema file contains a method call, it’s actually easier to extract the information from it than with a migration (which needs SQLEditor to figure out a class name and then call the up method)

    Hopefully this new work will appear soon in SQLEditor

  • XCode function popup

    I love the XCode function popup, particularly in Objective C, because I can add #pragma mark comments to divide up the list.

    Unfortunately languages that aren’t C derived don’t offer #pragma, so I missed these little dividers

    Then I noticed that a comment that contained FIXME had appeared in the list too, looking just as if it were a #pragma mark entry

    Looking at the XCode documentation reveals that XCode will also search code comments for a range of keywords and use them to control entries in the function popup. And it will do this for Java, Perl, Python, and Ruby (as well as the C based C, Objective-C and C++).

    This means I can write in other interesting languages and still get my function popup dividers.

    Just prefix the comment line with one of the following:

    • MARK:
    • TODO:
    • FIXME:
    • !!!:
    • ???

    and the remainder of that line will appear in the list.

    There is more in the Apple Xcode tools documentation

    (It looks like there has been some discussion of this already (1,2,3)

  • Reggy for regular expression testing

    Handy new tool I came across today which allows you to test regular expressions and see what they select.

    Reggy

  • Flash CS3 – Trace not producing output?

    Found an odd problem with Flash CS3 today. I was working away and I realised that I wasn’t getting anything in the output window from calls to trace().

    Just a completely empty output panel.

    The answer is simple, make sure Filter Level is set to verbose in the menu on the output panel. If you have it set to None then you won’t get any output.

    I’m not quite sure if this is something that I changed or if it is the default, but it isn’t exactly obvious.

  • XML, UTF-8 and Java

    Apparently, valid UTF-8 strings aren’t necessarily valid XML. You can get a situation where you have valid UTF-8 strings which fail xml parsing.

    Fortunately Mark McLaren offers a solution.

  • HTMLValidator 1.0

    HTMLValidator 1.0 is finally released.

    As I write this, it’s been out since Friday, so I guess I’m a bit late in writing this. HTMLValidator 1.0 is identical to HTMLValidator 1.0b8, except of course that it 1) doesn’t expire and 2) asks for registration.

    The first non-beta release seems to have gone reasonably well. People are downloading it, trying it and some are starting to buy it. (If you’re reading this, then thank you!).

    Oddly enough the most difficult thing about the whole thing was making sure that the order processing system could correctly deal with more than one product. We have a system that interfaces with our payment provider and it handles logging orders and generating serial codes. When it was originally written, HTMLValidator didn’t exist, we sold only one product and there wasn’t really a plan to develop others; So there were several areas that assumed that was only one product. The lesson here is to assume that you’re going to expand and plan accordingly.

    Work has already started on the next release of HTMLValidator. The main areas for improvement are speed and memory usage. Plus there are some improvements to validation that the W3C released in their version 0.80 code release that would be nice to have in HTMLValidator. (Which is of course based on the W3C validator).

    If you want to try HTMLValidator then we have a page that tells you all about it.

    [HTMLValidator]

  • building antlr 2.7.7 on Mac OS X

    It appears that antlr on Mac os x doesn’t like the jikes compiler, at least when I tried building antlr it gave lots of weird compile errors like this:
    Found 2 semantic errors compiling "ANTLRException.java":

    While it would be a good thing to try to fix the actual code, it’s easier to see if the solution is already available.

    The answer came in this posting which suggests renaming jikes before building. Which works, but there is an easier way. Just declare an environment variable before starting the build.


    export JAVAC=javac
    ./configure
    make

    Changing the java compiler that gets used is documented in the configure script.