Another one:  this one failed when I deleted a method, when it tried to compile a file still trying to reference the method. Spectacularly, it caused the compiler to crash, rather than simply report a compile error:

error: java.lang.Error: trying to do lub/glb of typevar ?Q

Error recently received from scala compiler:

error: type mismatch;
found : ?0(in method visit) => ?0(in method visit) where type ?0(in method visit) <: java.io.Serializable
required: (some other)?0(in method visit) => ? where type (some other)?0(in method visit) <: java.io.Serializable
new InOperator[Q, Serializable](expression.getField, expression.getValues.map(x => x))

What?

I generally use Maven; I’ve used Ivy; I’ve used SBT.  I’ve even (long, long ago) checked my dependencies into SCM.  And every single one of them occasionally requires 'rm -rf somecachedirectory' to make them work.

The only thing worse than searching for an answer to a technical problem on the internet and finding only forum posts without answers is searching for an answer to a technical problem on the internet and finding only forum posts you originated, still without answers.

So I’ve also been following Glen Mazza’s X.509 tutorial for JAX-WS, found here.  It has some of the same problems as the other ones.  But this post is about something different.

Glen’s tutorial, and every other tutorial I’ve seen for JAX-WS/Metro and WS-Security, includes configurations in the WSDL for the security engine like this (along with a lot of other policy markup, without explanation; one of my beefs with these is that they don’t actually explain what any of the stuff they’re asking you to do is for):

<sc:KeyStore wspp:visibility="private"
   location="/home/gmazza/workspace/DoubleIt/mykeys/servicestore.jks"
   type="JKS" storepass="sspass" alias="myservicekey" keypass="skpass"/>
<sc:TrustStore wspp:visibility="private" storepass="sspass"
   type="JKS"
   location="/home/gmazza/workspace/DoubleIt/mykeys/servicestore.jks"/>

So I understand this is a “quick and dirty” tutorial, but this is code that is completely unsuited for a production deployment.  Never mind the cleartext passwords which, given that there’s never really a good way to store them, may be excusable.  In no environment I’ve ever heard of would it be possible to hard-code the path to a keystore in a WSDL file and then deploy it to various environments (qa, prod, etc.).  Yet that’s how the tutorial specifies it.

So I’ve got a couple of complaints:

1. I think it’s irresponsible for tutorial writers to take these kind of shortcuts, at least without noting them.  Every tutorial I’ve seen for JAX-WS and WS-Security has been had basically the same structure, and this is apparently what Netbeans generates.
2. I think it’s irresponsible of the Metro/Glassfish team to even allow this kind of configuration.  I found some documents today in the WSIT project mentioning that this configuration option was put in the project to make it quick and easy for developers to get started, and that it wasn’t intended for production use, although no good alternative was mentioned in the document.  And because it exists, every tutorial and document will use it.  And since developers are like lemmings, there are probably sysadmins all over the world silently cursing while hand-editing the production WSDL for the same web-service for the six-hundredth time.

I’ve been recently trying to set up WS-Security on a web-service implementation I’m working on.  To that end, I’ve been trying to find out how to actually implement it.  I won’t say that the standard has failed me (yet), or that the internet has failed me.  I’ve actually found much useful information . . . and maybe I’m almost there.

But . . . there are roadblocks along the way.  There are surprisingly few actually useful resources available on these topics, despite the fact that WS-Security is supposed to be the standard way of securing SOAP web services.  No wonder everyone just adds a username and password to the WSDL data and leaves it at that.  Start with the WS-Security standards themselves.  They say things like (and I quote):

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, ”RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

To which I have to say . . . really?!!!  Do I really need to read RFC 2119 to know what those words mean?  And if that’s the case (because you don’t use the words in a way a normal person can just understand), how do you expect anyone to actually use your standard?

Then there’s the tutorials (of which there are precious few).  To start with, Oracle has manged to make the java.net sites basically unavailable.  (Which is why there’s no quote for this assertion.)  But when you can access them, you find tutorials for using the standard Java JAX-WS framework to do WS-Security that say:

1. You can’t, so replace the entire JVM’s JAX-WS implementation with the Metro one, for which it’s impossible to find the right JAR’s.
2. Once you do that, we can’t explain how to configure it, or what the schema is for the configuration language, or how it works.
3. Instead, use Netbeans to generate the boring, complex XML documents for you.
4. And, by the way, if you do, your application will only work in Glassfish, so good luck if you’re using a different application server.

So I’m stuck reading tutorials written by Glen Mazza, mostly around Apache CXF.  Amazingly, after my experiences so far, these are actually useful.  But . . . they’re only so useful.  I’m staring here, and my experience has been frustrating in various ways.

First, that tutorial actually says to look at two other tutorials he’s written, both of which reference other tutorials, and replace Step X sub-step Y with XYZ, etc.  A more frustrating experience of cut-and-paste I haven’t had in a while.  And when I’m done, things don’t quite work, either because of software version changes between the tutorial post’s writing and now, or environment changes, or because the author got somewhat confused in his writing, as I’ve been in reading.

Be that as it may, I think I’ve finally succeeded in making it work, so I have to hand it to Glen Mazza, since he’s the only one that presented something I could find that was actually useful.

The title of this blog comes from the fact that I believe software code strictly follows the second law of thermodynamics.   Here are a couple of the English-language formulations of that law (from the Wikipedia article):

- In a system, a process that occurs will tend to increase the total entropy of the universe.- It is impossible to convert heat completely into work.- The entropy of the universe tends to a maximum.

The idea of “software entropy,” or that disorder slowly creeps into evolving software code, isn’t new; it’s certainly not my invention.It just strikes me that not only is there such a thing as “software entropy” or “code entropy,” but that such chaos in code is in fact inevitable, much as the second law states that entropy is inevitably increasing in an isolated system.  (And yes, I’m aware that entropy != disorder in a meaningful sense in chemistry or physics; I’m using the word in its popular sense.)I think there are plenty of people in the software industry who can share stories of increasing disorder in a system’s design and code, and I think that much of that disorder occurs despite the best efforts of many bright people to prevent it.  There are even theories and processes which attempt to embrace and manage that disorder, which says something about how prevalent it is in the industry.But I personally think “software entropy” is more than something we need to guard against or manage.One implication the second law, as I understand it, is that when energy or heat moves from a hotter region or object to a cooler one, the net change in entropy of the system is always an increase.  And when work is applied to a system to move heat or energy from a colder region to a hotter one to increase the heat of the hotter one, energy is always “wasted” and there is always a net increase of entropy in the system.I think this is true of software code.  We can attempt, through rigorous standards and processes, application of our most senior staff, careful design, etc. (in other words with a great deal of “work” expended) to reduce the disorder in one application or one region of an application (for example via a rewrite or redesign, or through an extensive refactoring process), this effort always results in a net increase in disorder in other regions of the system.  Either our standards cause unintended problems or consequences, or we’ve pulled senior staff from other projects and those projects suffer, or we stop paying attention to the code of application A to focus on reviewing application B and the code of application A gets worse.So I’m going to writing about software design and construction, and “software entropy” is one of the things I’ll be considering on the way.I’ll leave with the following quotation (also from the WP article) that sometimes seems apt for the software industry:

The tendency for entropy to increase in isolated systems is expressed in the second law of thermodynamics – perhaps the most pessimistic and amoral formulation in all human thought.- Greg Hill and Kerry Thornley, Principia Discordia (1965)

[edit: I corrected a few typos and errors]

I’ve been designing and writing software for various IT departments since 1997, and I’ve spent a lot of that time wondering why the IT industry does what it does, and why the process of designing, writing, and using software seems to be so problematic.

I intend for this blog to be about that process, and about the inevitable disorder that seems to result.