Nashorn Thoughts

Recently, we ran a HackDay on Nashorn as part of Devoxx UK.

Nashorn (pronounced NAS-horn, not NASH-horn) is a new implementation of Javascript that will ship with Java 8. It's very cool - all implemented with invokedynamic & passes the ECMAScript spec 100% (no other impl can do this).

It's already landed on OpenJDK 8 mainline & is in most cases, pretty solid. We found a couple of surprising things & minor bugs with it during the HackDay, but nothing major.

On the whole, it's pretty awesome - the Java interop is great, and it's a way of writing Javascript which doesn't feel too clunky.

In fact, I'd really like to start using Nashorn as a teaching aid to do outreach to web programmers who don't know the Java platform at all.

One slight problem is that jjs (the Nashorm shell) isn't actually a very good REPL. In particular, it doesn't handle multi-line cut & paste & has no history.

So, I decided that the simplest way to try to fix that was to use rlwrap (thanks to Richard Warburton for discussion of this point). This is a program which takes a command name (plus args) as arguments, and runs them through the readline library, thereby adding support for history, etc even to programs which don't support them out of the box.

rlwrap is, for example, often used by Oracle DBAs to add history support to sqlplus.

Here, then, is where this tale of woe truly begins.

Mac OS X does not ship rlwrap. In fact, it doesn't even ship the GNU Readline library on which rlwrap strongly depends. Instead, it ships a library which has the same name, but is not fully compatible.

All of this means that rlwrap will not build cleanly from source on OS X.

To fix this, I downloaded GNU Readline & compiled it as a static library (actually 2 static libs - libhistory.a & libreadline.a).

Then I set the include directory of rlwrap to ignore the bogus readline.h in /usr/include & instead use the correct one (contained in the source directory of GNU Readline).

Rerunning make from the rlwrap build directory now correctly compiled all of rlwrap, but the final link still failed (because it was attempting to use the bogus libreadline.dylib which OS X ships).

However, at this point, I could now take the final link command, and modify it - removing the -lreadline switch & instead adding in libreadline.a and libhistory.a as additional object files that just need to be included in the final binary. This results in a semi-statically linked rlwrap which actually works.

With all of this yak-shaving done (& yes, I do know that MacPorts ships an rlwrap, but I have been bitten by MacPorts way too many tines to trust it. I'd rather actually understand what was happening on my system - there are package managers I fully understand. MacPorts is not one of them), we were finally read to go:

rlwrap jjs

Aaaaaand - it fails. Well, it works correctly with history & so forth - but one of the critical features for me (multiline c&p) just doesn't work, even under rlwrap.

So, that's kind of back to the drawing board.

• I'm sure we need a better REPL for interacting with Nashorn. 
• I'm prepared to spend some cycles on it.
• I think I have a decent starter set of use cases for it
• I need some help
• Especially from people who are approaching this from the POV of not knowing the Java platform or the JVM
• Errr, that's it...

So - who wants to help? I think this could be quite a cool little project...

Emacs Redux

Recently, I've discovered myself spending more & more time in Emacs.

This post is really about why that's the case, and how I have Emacs configured, in case it's of interest or use to someone else.

I used to use Emacs a long time ago - back when Perl & C were my primary languages, and dinosaurs still walked the Earth. I largely stopped around 2000, when I started writing a certain amount of Java, and using Eclipse as a primary environment.

These days, I find myself doing a fair amount of work with the OpenJDK codebase. This is a particular pain to write in an IDE. This is because to work properly, the IDE needs to hook a working version of the platform & fully support all of its features.

Now, if I'm working on the platform itself, then that self-consistency and support is not present. So I'm going to get, at best, a bunch of failures around the new features.

So a lot of the typical reasons why IDEs are useful are absent - so basic syntax highlighting is pretty much all we can hope for, and Emacs has pretty good support for that.

In terms of application code, whenever possible I like to write Clojure. These days, there is excellent support in Emacs for Clojure, including the NREPL for a very nice interactive environment.

To get clojure-mode installed, follow the instructions from here. However, the sections about inferior-lisp-mode and slime are obsolete - you should use NREPL instead.

I'm also tending to write articles & other documents in Markdown, which doesn't really need much in the way of WYSIWYG support (although I spent a tiny amount of money on Marked.app for the times when I do want to see what my .md files look like, or export to PDF).

My primary machine is a MacBook Pro, so I use the Emacs from here. I tend not to use package managers for OS X, so I don't use brew or macports.

Finally, I've been pleasantly surprised by many aspects of the modern Emacs experience. The Clojure integration has come a long way & it's now a joy to use. For OpenJDK development, it's almost as good as a full IDE.

However, there are still some rough edges. For example, Emacs doesn't ship with a spellchecker by default, and I have so far been unable to get one working - which is a medium-sized pain when writing Markdown. Instructions on how to get it working in comments would be very welcome.

A Starting Point

So, to ease myself back into writing, I'm going to cheat, and start by repeating some very good advice I heard recently.

This is by Rich Hickey, the inventor of Clojure, and I think it's a near-perfect statement of how I would like mailing list interactions to work (& how I aspire to behave myself).

Thanks Rich - over to you:

"This is just a reminder. While in general our communication here is very good, occasionally it goes astray.

These mailing lists are run by, and for, people who make things. Most messages should have one of these forms:

I made something - here is my contribution
I am trying to use the thing someone made and am having trouble, please help.
I can help you with that thing someone made.
I am trying to make something and am having trouble, please help.
I can help you make something.

They are not the place for opinion pieces and diatribes.

They are not the place for advocacy about what 'ought' to be made. If you think something ought to be made, then make it. Otherwise, respect others peoples' right to choose what they do with their time.

Occasionally, there may be disagreements about how something has been, or will be, made. These disagreements should take the form of technical arguments. To make a technical argument that gets (and gives!) respect:

Keep it short
Stick to the facts
Use logic
Leave people out of it
Avoid rhetorical devices:
        Superfluous or opinion-laden adjectives
        Claims to speak for the community, or that everyone agrees with you.
        Threats of what will happen unless things go your way
        Any flavor of 'the sky is falling'

If you are not the one making something, you should restrict your input to very short technical arguments supporting your position. If someone has already made your point, just +1 it.

Please keep your posts short.

Ignoring these guidelines fails to respect the time and effort of people who make things, which you should care about if you intend to be one.

Thanks,

Rich"

If you've read down this far, please leave me a comment with a link to other good advice you've heard recently.

Still Not Dead

Can't believe how long it's been since I last posted here.

A number of times I have wanted to start blogging again but for one reason or another, haven't managed it.

But let's give it a go - I am still crazily busy, but I do have things to say.

Book Update

I can't believe how busy it's been on the book front recently.

We have a new site live for it: http://bit.ly/a7H67J and Martijn and I have recently been looking at some possible cover designs (will post as soon as they're finalized and we can share).

There's also been a slight title change - we're now working on "The Well-Grounded Java Developer" (with "Covers Java 7" as the subtitle). The reason for that is we want to emphasize that the book is about more than just the Java 7 syntax changes - we're talking about a lot of the other shifts in the Java landscape, about multi-language, and lots of other things.

The links to our first "Green Paper" and other new content should go live soon, and after that - Early Access. It's all quite exciting.

Forthcoming Book

I'm very pleased to announce that my new book "The Well-Grounded Java 7 Developer" will be published by Manning, for release in Spring 2011.

My co-author is Martijn Verburg - his announcement post is here - and we'll be making further posts as we develop this project. It's a concept that we've been developing together since late last year, and we're both really excited about it.

The next big step forward will be when our drafts hit the Manning Early Access Program (MEAP), which should be in a few weeks time - I'll be sure to update with links when we're live.

Now, back to writing chapter 7.

Thoughts on Diaspora / Distributed Social Networks

This post, by Matt Asay, decries Diaspora (the forthcoming Open Source Distributed Social network which seeks to disintermediate FB and other centralised social networks in favour of personal 'seeds' - services which directly connect to each other and aggregate content from services, essentially externalizing the social graph into links between seeds).

He makes some good points, largely that this is a geek toy for geeks (although he misses the obvious corollary that in this game, that's how everything starts, but if Gibson's to be believed, the street finds its own uses for things. Isn't that what happened with Twitter?) and that the technical nous required to set up a seed is going to be too high (which is a problem the scene can solve).

His fundamental fallacy, though, is that ordinary people just don't care about the privacy and safety aspects of their data, and that they value the aggregation of "everything in one place" ie FB.

This simply isn't true. It's not just that survey after survey is coming out showing that the so-called digital native generation do care about their privacy, they just feel that they have no option but to use FB. It's not just that Zuckerpunched has entered the lexicon, to mean being tricked into revealing more information than you intended to.

The basic fallacy "ordinary people value aggregation over privacy" is disproved by looking at people's plans for their birthday (and it's mine next week - send me cake :) ). Most people will have two or three (or even more) separate celebrations for their birthday - there'll be drinks with colleagues after work one evening, there'll be a family meal and a gathering for friends.

Those partitions of the social graph exist for ordinary people, and they represent groups in which ordinary people may well display different aspects of themselves, and it's that which Matt's missing, and it's that which is a huge stumbling block for FB. They don't segregate your data into sets which accurately represent your aspects and groups of connections. They don't, because they can't. I don't mean technically, because of course they could with enough engineering resource. They can't, because they're a slave to the needle now, baby. Monetizing your info is the only thing that's going to keep their VC investors happy, and by now, everyone has such high expectations (4sq turned down 100M - and if that's not the dictionary definition of delusional, I don't know what is) that they have to scrabble to get every last cent out of you, and that means mining all of your information.

Perhaps in a few years, we'll come to look back on the idea that the social graph should be monetized separately by many sites, all of which seek to lock up and treat as proprietary the connections between human beings - perhaps we'll come to see this as a strange passing fancy from which a mature market awakened. One thing seems certain, however - the current situation in which the social graph is replicated imperfectly across dozens or hundreds of sites is incredibly inefficient, and with the 800-pound Facebook gorilla failing to provide a functionality which the overwhelming majority of people want (the ability to manage multiple aspects of your personal graph), then the situation is ripe for upset.