20140213 (Thursday, 13 February 2014)

Still problems with Java applets

Gerd cannot run test-eidreader after their upgrade to 7u51, he gets:

uncaught exception: Liveconnect call for Applet ID 1 is not allowed in this JVM instance

Google then leads me to a page LiveConnect changes in 7u45, of which I understand only fragments, and which has comments like:

  • “Adding Caller-Allowable-Codebase: * to the JAR’s manifest file isn’t making the error go away. Any ideas?”

  • “Please keep ‘improving’ the applet experience Oracle, each time you ‘improve’ things it makes it easier for me to justify removing applets from our solution. This ‘fix’ seems incredibly poorly thought out, badly/untested and yet another nail in the applet/webstart coffin.”

  • “Oracle is really making it difficult for end users to run Java applets. The last couple of years have been a slow but steady death for applets.”

All this sounds very frightening. Yes of course users are frustrated when everything is changing and unstable. And yes of course we don’t know Oracle’s motivations for these changes. But there is still hope that Oracle are just struggling, that they will manage to get it stable one day. Java applets continue to be the best implementation of a platform-independent environment for web applications. So stop moaning and continue to swim.

So I invited Gerd to run a next test: let’s try with a Caller-Allowable-Codebase attribute in my Manifest.txt file:

Caller-Allowable-Codebase: *

(The docs say that “This attribute is not needed if the JAR file for the RIA is in the same location as the JNLP file or HTML page that starts the RIA”, but the comments and our previous experiences indicate that statements of this kind aren’t reliable).

To protect us from problems due to unrecognized caching, I changed the initialization message to:

System.err.println("EIDReader version 20140213 initialized");

I asked Gerd to test this. And then I went to sleep without much hope. I did not test this myself because each test costs me a few minutes (I must log into a virtual client machine, locking my own machine during this time) and when it fails I cannot even see the Java console.

And a few hours later, while I slept, came the unexpected good news: the above was the reason! I worte to Gerd:

Insgesamt würde ich die Situation wie folgt zusammenfassen:

Zum Einlesen der eID-Karten und zum Bereitstellen von editierbaren Dokumenten (zur Zeit nur Lebensläufe, später auch andere Bescheinigungen) braucht Lino eine Technologie namens Java.

Java, eine ursprünglich freie Software, wird seit Jahren durch Oracle (zuvor Sun) benutzt, um ein Monopol aufzubauen. Das macht sich bemerkbar in unzähligen Problemen wegen ständiger Änderungen im Sicherheitsmechanismus. Bei jedem “Upgrade” hat man neue Überraschungen. Unter Experten ist das allgemein bekannt und wird viel bejammert und angeprangert.

Aber rein theoretisch ist Java der richtige Weg, um die o.g. Funktionalitäten zu implementieren. Ob das in der Praxis auch so bleiben wird, kann heute niemand sagen. Auf Oracles Pläne und weltweite Entwicklungen ist unser Einfluss eher gering. Wir halten die Augen offen nach Alternativen, aber uns ist momentan kein vertretbarer Kandidat bekannt.

Deshalb: insgesamt bejahen wir unsere Entscheidung, weiterhin mit Java zu arbeiten. Wir hoffen, dass die problematische Phase in Oracles Implementierung bald vorbei ist und lernen immer besser, wie man solche Probleme möglichst schnell in den Griff kriegt.

I verified that we can exclude side effects due to “changed circumstances” (a usual phenomen when you work with Java) by (1) reproducing myself that it works, (2) removing the line, updating the site and verifying that it fails and (3) restoring the line again and verifying that it works again.

Attestations

docs/tickets/93

When creating an Attestation by double clicking in AttestationsByProject, then the project field gets filled automatically, but we also want to set the owner field to the project.

lino_welfare.migrate now writes a file migrate_from_1_1_10.py, intended to get executed after the real migration. This script renames the .rtf files generated per notes.Note of type “Lebenslauf” so that Lino finds them back now that they are an attestations.Attestation.

Blogging

docs/tickets/88

I stumbled over an article for which I’d like to write a blog entry, mostly in order to find it back when I need it in 3 years or so. I tried to do this on my shiny new FSFE WordPress blog. Here it is. But I perceived it as a pain to do this. Switching between Emacs and the WordPress web interface is a pain. I want to blog in restructuredText because that’s how I am used to write down my thoughts. Oho, Luis Artola had similar problems, and he wrote a tool called restblog Will this be for me?

My first spontaneous reaction: Cool! But I want one single file per day with possibly several posts (possibly published to different blog servers).