Archive

Archive for September, 2015

Windows-like keyboard shortcuts in Linux Eclipse

I have worked with Windows as my main development platform since Windows 3.1 and the keyboard shortcuts are hardwired by now. Unfortunately Microsoft has failed utterly. In my opinion Windows 7 is the pinnacle from a usability standpoint, Windows 8 was a disaster and Windows 10 is not that much of an improvement. It is time to move on, in particular as Microsoft seems determined to spy on customers.

Java is cross-platform, so I can use Linux. It works well and bash is great, but the keyboard shortcuts are plain wrong. Fortunately there is a solution. For example, to expand a treeview in Eclipse StackOverflow recommends this for GTK 2:


binding "gtk-binding-tree-view" {
    bind "j"        { "move-cursor" (display-lines, 1) }
    bind "k"        { "move-cursor" (display-lines, -1) }
    bind "h"        { "expand-collapse-cursor-row" (1,0,0) }
    bind "l"        { "expand-collapse-cursor-row" (1,1,0) }
    bind "o"        { "move-cursor" (pages, 1) }
    bind "u"        { "move-cursor" (pages, -1) }
    bind "g"        { "move-cursor" (buffer-ends, -1) }
    bind "y"        { "move-cursor" (buffer-ends, 1) }
    bind "p"        { "select-cursor-parent" () }
    bind "Left"     { "expand-collapse-cursor-row" (0,0,0) }
    bind "Right"    { "expand-collapse-cursor-row" (0,1,0) }
    bind "semicolon" { "expand-collapse-cursor-row" (0,1,1) }
    bind "slash"    { "start-interactive-search" () }
}
class "GtkTreeView" binding "gtk-binding-tree-view"

And this for GTK 3:


@binding-set MyTreeViewBinding {
    bind "Left"     { "select-cursor-parent" ()
                      "expand-collapse-cursor-row" (0,0,0) };
    bind "Right"    { "expand-collapse-cursor-row" (0,1,0) };
}
GtkTreeView {
    gtk-key-bindings: MyTreeViewBinding;
}

With Ubuntu the files to edit are found below /usr/share/themes.

Advertisements
Categories: Java, Linux, Windows

Beware of ActiveMQ with JDBC persistence

ActiveMQ (and Red Hat’s AMQ derivative) is gaining ground. Many companies that need high availability already have highly available databases, so it makes sense to use ActiveMQ in a master/slave configuration with a JDBC message store. A bit slower than KahaDB or LevelDB, but simple to configure and very safe. Or is it? Well, it depends.

ActiveMQ really has two different message stores: one for normal messages and one for scheduled messages. For normal persistent messages it is possible to use KahaDB, LevelDB or JDBC. For scheduled messages there are only two alternatives: KahaDB and in-memory. So, if you have a highly available master/slave configuration with a JDBC backend for normal messages, all scheduled messages will be lost when the master dies, as they are stored in the local file system or in memory.

Scheduled messages are seldom used, so perhaps this is trivial? Unfortunately not. Most applications want to redeliver failed messages a few times before relegating them to a DLQ. ActiveMQ supports redelivery, but under the hoods it is implemented using scheduled messages. In other words all messages waiting for redelivery are lost at failover unless the job scheduler store is highly available, which means a highly available KahaDB store. Installations that use JDBC don’t do HA KahaDB.

In other words, take care when using ActiveMQ or AMQ with a JDBC backend! Normal messages are safe, but some are likely to be lost at failover. Is that acceptable?

A documentation bug has been filed for this.

Categories: Java