XPages JavaScript mystery meat

When using XPages, I try to build as much as possible in Java, and then use as little JavaScript as possible to glue the Java code into XPages.

The main problem I hit when doing this is ensuring that my Java methods have the right type signatures to get found and called by JavaScript. It’s confusing to call someMethod(true) and find that you get a run-time error saying there’s no Java method someMethod(boolean), even though there is.

So I put together a quick Java class to dump back the types of the objects it was passed, and then fed it everything I could think of from an XPage. Here’s the result.

Standard JavaScript types
Parameter Received as
boolean java.lang.Boolean
number java.lang.Double
null null
string java.lang.String
array java.util.Vector
hash com.ibm.jscript.std.ObjectObject
JSF predefined variables
Parameter Received as
applicationScope com.sun.faces.context.ApplicationMap
cookie com.sun.faces.context.RequestCookieMap
facesContext com.ibm.xsp.domino.context.DominoFacesContext
header com.sun.faces.context.RequestHeaderMap
headerValues com.sun.faces.context.RequestHeaderValuesMap
initParam com.sun.faces.context.InitParameterMap
param com.sun.faces.context.RequestParameterMap
paramValues com.sun.faces.context.RequestParameterValuesMap
requestScope com.sun.faces.context.RequestMap
sessionScope com.sun.faces.context.SessionMap
view com.ibm.xsp.component.UIViewRootEx2
XPages types
Parameter Received as
document data source com.ibm.xsp.model.domino.wrapped.DominoDocument
view data source lotus.domino.local.View
extlib object data source The Java class of your object data source
predefined variable ‘database’ com.ibm.domino.xsp.module.nsf.NSFComponentModule.XPagesDatabase
predefined variable ‘session’ lotus.domino.local.Session
text field control via getComponent com.ibm.xsp.component.xp.XspOutputText or other appropriate class from that package

Note that many of the JSF and XPages variables are accessible directly from Java, so you generally shouldn’t need to pass them as parameters — but I’ll leave that decision to you.

Systemd

[Now updated for 2015!]

Component Status
systemd Replaces init, cron, inetd, udev, locale, acpid, atd.
systemd-journald Replaces syslog, klog.
systemd-logind Replaces getty, login, xdm. (*)
systemd-networkd Replaces ifup, ifdown, tcpwrapper, hostname, dhcpd.
systemd-journal-gatewayd Provides HTTP server for systemd-journal.
systemd-timesync Replaces NTP.
systemd-resolved Replaces resolvconf, bind, powerdns-recursor, dnsmasq.
systemd-automount Replaces autofs.
systemd-readahead No longer supported because everyone who matters has SSDs.
systemd-machined Replaces VirtualBox, VMware. (Coming soon.)
systemctl-cat Replaces cat. Really.
systemd-firewall Replaces iptables.
systemd-journal-remote Replaces logstash/elasticsearch with a new logging protocol over HTTP.
gummiboot To be incorporated, replacing grub.

Also, here come the security vulnerabilities:

…systemd-resolved does not implement any of the hardening recommendations of rfc5452

(*) OK, so it’s a bit more complicated than that. Eventually the plan is to get rid of X11 for Wayland, but currently X11 is still allowed. However, systemd is part of the PAM configuration now, and systemd starts your X session with display manager and window manager. So far login and getty still service legacy non-console ttys.

That Cringely rumor

Robert X. Cringely has predicted mass layoffs at IBM:

To fix its business problems and speed up its “transformation,” next week about 26 percent of IBM’s employees will be getting phone calls from their managers. A few hours later a package will appear on their doorsteps with all the paperwork.

I wouldn’t normally write about this kind of thing, but a lot of news sources have taken the rumor and republished it as if it is fact, and people I know are starting to believe it. Apparently the media are unaware that Cringely has a history of predicting IBM doom.

So, before you get too excited about the current rumor, let’s take a look at a couple of Cringely’s previous predictions. Here’s one from 2007:

The BIG PLAN is to continue until at least half of Global Services, or about 150,000 workers, have been cut from the U.S. division. […] All this is supposed to happen by the end of 2007, by the way.

IBM did not, in fact, cut 150,000 US employees in 2007. IBM had around 117,000 US employees in 2006 and around 121,000 US employees at the end of 2007, so the company didn’t even have 150,000 US employees to cut, let alone 150,000 in Global Services.

Or consider Cringely’s 2012 prediction:

The direct impetus for this column is IBM’s internal plan to grow earnings-per-share (EPS) to $20 by 2015. The primary method for accomplishing this feat, according to the plan, will be by reducing US employee head count by 78 percent in that time frame.

I don’t have numbers, but I am pretty sure IBM did not, in fact, cut US head count by 78% between 2012 and the start of this year. That’s the kind of thing I’d have noticed.

So… When you read stories about IBM, check the source. And if it’s Robert X. Cringely, apply a heaping serving of salt.

(Disclaimer: I have no inside knowledge of what IBM management are planning for 2015. Opinions are mine, not IBM’s.)