Spar - why do we violate Java standards and conventions?

In Spar, we violate a number of standards and conventions of Java. On this page I will try to express a number of valid complaints against our work, and I will try to explain why we feel that we had to do it.

You extend Java; if Spar ever becomes popular, this could fraction the code base into incompatible dialects

Since the point of Spar is to test a number of language constructs of our own invention, we don't see how we can avoid extending the language. We have tried to minimize the impact on Java, and we do not modify the language for the sake of it.

The language extensions that we have chosen were designed to be unintrusive, powerful, and generally useful. We believe that they do not violate the `spirit' of Java, and that the language extensions are valuable additions to the language. Who knows, perhaps Sun agrees with us (or similar proposals from others), and one day extends the language.

Also, there is a compiler option --java that switches off all language extensions. You can also selectively switch off language extensions.

You do not compile to JVM code, making the compiled code non-portable

There are two reasons for this. First, this is not easy to do for a small research group like ours. We have a working compilation path for native code generation that builds on previous work, and retargeting everything to JVM is not easy. Moreover, it is not clear that all the constructs of our intermediate code could easily be expressed in JVM.

Another reason not to compile to JVM, is that I am convinced that using a virtual machine still causes a performance hit. Yes, I know that there are reports that prove that Just In Time compilers can cause performance equal to (or even better than) native code, but there are more than enough reports that suggests that this only applies to specific program areas.

The compiler is quite portable and generates fairly portable C++ code (interfacing to the message passing library of the new platform is probably the most difficult part). In that sense Spar code is portable.

You do not implement all of Java

Implementing all of Java, and all of the supporting classes is a difficult task. Moreover, beyond a certain point Java implementation issues are less important to us than our global research goals. It is likely that implementing all the dark and rarely visited corners of Java will take some time.

At the moment we can only support classes for which we have source code, or classes that we have re-implemented from the specification. We are considering implementing a .class compiler, which would make it easier for us to support arbitrary Java classes.

You do not license the Java compiler from Sun, how can you ever be compatible?

It is true that we do not have a license from Sun for the source of their javac compiler. This is a deliberate choice. The current Sun licence is quite liberal, but since we intend to release the Spar compiler under a GPL license, we cannot be `tainted' with inside knowledge of the Sun java compiler. Therefore, the compiler was implemented from the public language specification in the Java Language Specification. Besides, the structure of our compiler is so vastly different from the Sun one, that having the source code would help us little.

However, we try as much as possible to follow the published standard.

Spar floating point calculations may differ from Java calculations

Since we map floating point calculations directly on C++ floating point calculations, this is probably true. Getting this right would require a lot of effort, would hinder optimization, and would negatively affect some programs.

Moreover, as several people have argued (see e.g. the Borneo project), the current tight specification of Java floating point behavior is detrimental to floating point calculation. This specification requires the compiler to throw away floating point precision only to be compatible with the standard, and encourages the dubious practice of relying of the exact behavior of a floating point calculation.

You use templates to provide generic types

Although using templates for generic types does have some disadvantages, we consider them less significant than the advantages.

The main disadvantage is that templates may cause `code bloat', since for every combination of parameter values that is passed to the generic type a new instance of the template is created. We realize that this may cause problems, but we believe that with responsible use this problem is rarely significant.

The main advantage of templates is that they easily allow a high-performance implementation. Since we are building a compiler for high-performance computing, this is obviously very attractive.

Last modified Sat May 13 15:50:56 2017 UT by Kees van Reeuwijk.