Diagnosing Java code: Walking on a specification wire

To build reliable software, program specifications are critical. It is difficult to diagnose abnormal behavior of software systems without well-defined specifications. But many software systems have poorly defined program specifications. And, to make things worse, many software systems have no specifications at all.

Intuitively, the program specification is a description of the procedural behavior. It can take many forms, but no matter what form it takes, there is a thread that runs through all the instances: there must be some type of system specification because you have to rely on it to determine if the system is working properly.

Specifications can be formalized or loosely defined, depending on the degree of stability and risk of the system being developed, and how easy it is to modify the system after it has been developed.

We will begin our journey by discussing why the specification is important, why it is often overlooked, and how to improve it.

Cost and benefits of balancing accuracy

In the microprocessor design world, systems are deployed in a variety of applications, from personal computers to heavy duty medical and military systems. There is a common, unbreakable rule in this field: the cost of modifying the chip design after deployment is extremely expensive.

It is therefore not surprising that the specification of microprocessors is typically formalized. A formal specification has great benefits because it can be explained and analyzed automatically. In the case of microprocessors, many aspects of the design can be automatically verified and correct.

Software analogy: programming language

In the software world, the most microprocessor-like thing in terms of deployment and risk is the programming language. A popular programming language is used to write countless programs that are used in systems of varying levels of risk.

As with chips, the cost of modifying language design after being put into use is quite expensive, since all existing programs must be modified and recompiled. Therefore, the specification of a programming language is usually quite formal compared to other software systems.

For syntax, this formalization is particularly important. In fact, all modern programming languages have formal definitions of syntax. Most parsers are constructed by using an automated parser generator that reads these grammars and produces a complete parser as output.

Unfortunately, linguistic semantics do not tend to be such a strict rule. This is not because it cannot be done so strictly.

Languages like ML have formal semantics and thus prove many of their laws to verify certain aspects of their correctness (for example, the refinement of their type systems). But a language like ML is a special case. We can determine the two reasons for this.

First, because proving that the specification of a programming language is actually more difficult to manage than hardware design, formal specifications are not needed. In contrast, many languages are prescribed by descriptive writing. These text specifications are sufficient for most people who actually use the language, such as the compiler author. In fact, compiler authors are usually fascinated by less formal specifications because it gives them more room to optimize the program. In addition, there are times when language users are programmers, and most of them appreciate informal specifications because they can easily understand the specification.

The second reason is that many languages are developed by individual developers as "hobbies," and they tend not to specialize in programming languages. Unfortunately, these developers often do not understand the formal system developed to specify the semantics of programming languages.

An example of ambiguous costs

However, the cost of ambiguity or inconsistency in the language specification can be quite expensive, leading to portability, reduced reliability, and even security vulnerabilities. By studying some of the currently widely used languages, you can find out how the relative accuracy of their specifications affects them.

The C + + language specification has many ambiguities, even at the grammatical level. In addition, many parts of the specification become dependent on implementation. The result: C + + programs are often difficult to run as expected on a variety of platforms.

The Python language specification leaves behind a lot of details that are dependent on implementation or undefined. As a result, implementations such as Jython and CPython face enormous challenges in providing the same behavior as the other. If not because the Python language is relatively simple (not derogatory), the problem is even worse.

Although the Java language does not have a formal specification (similar to that of ML), much effort has been devoted to the development of precise informal specifications. The language is usually compiled into bytecode interpreted by the JVM, and the JVM itself has good specifications (although some ambiguities are found in the specification through formal analysis). In addition, the Java APIs are part of the JVM's rules. This gives Java code an unprecedented degree of portability.

We can draw the conclusion that a language specification as accurate as possible is very useful. But even in the world of programming languages, the problems in the specification are the most expensive, with few precise specifications, in part because it is expensive to make a precise specification beforehand.

Many companies find that the cheaper option is to deliver the product first, and then (or probably never) replenish the specification details. Admittedly, it is too expensive to define a precise specification for applications that have a shorter life cycle and a narrower range of deployments. It is sometimes possible that competitors have already delivered the system, and the development team has not yet formalized its system specifications.

In addition, large specifications are rarely updated when user requirements change, and are therefore ignored. But what should the development team do to define their software if the predefined specifications are too expensive?

Before you answer this question, let's consider a common, but indeed the worst, way.