Saturday 27 January 2007

Dot equals and the source keyword

A number of comments to yesterday's blog on a dot equals operator for overloading equals() objected to the syntax. As I tried to show, using the most logical syntax of == isn't possible in Java. Or is it?

Source keyword

Howard Lovatt has suggested using a source keyword to identify the version of the Java language that the source code is written in. This would appear before the package statement:

 * Copyright...
source 7;

public class Foo {
  // normal class stuff, but can use Java 7 syntax

The addition of this keyword could allow the radical change of redefining == to === and .equals() to == in Java 7 code. Files with 'source 7' would use the new equals operators, files with source 6 (or no source keyword) would use the old equals operators.

  source 6;  // keyword specifying Java version
  if (person.equals(input)) { ... }  // test by equals()
  if (person == input) { ... }       // test by equality
  source 7;  // keyword specifying Java version
  if (person == input) { ... }   // test by equals()
  if (person === input) { ... }  // test by equality

I'll be honest - this concept seems like a 'technically it would work but its a really bad idea' thing. Redefining == in Java, so it means two different things depending on what the source version is just bound to cause trouble. Thats why yesterday's blog is seeking a new operator to represent equals().

Anyway, I include this blog just to show what is possible with syntax change - not what I actually want.


  1. This is exactly the point: let Java be, and develop a new language. J# or something. Heheheheh...

    You could also say:

    source groovy;
    source java7;

    The multi-language compiler is the future!!

  2. One of the downfalls of this approach is that the JLS would have to define what a java source file means with and without the "source" line... in other words, it would have to describe all supported versions of the language.

  3. This is a question of granularity. Right now you can tell the compiler which compatibility to follow when compiling. A source keyword would hand over the decision and definition to the author of a class. For maintenance, this could be a nightmare, though. And also for people trying to understand the code.

    I'd say we rather need fewer, clear rules and constructs in Java than adding piles of symbols, finally creating a new language called "Jerl". See, for example, the closure proposal. If we'd have closures earlier, we would have saved to introduce a new and partially troublesome "feature" called "Enhanced for Loop".

  4. I very much prefer the per-source file version number (whether by keyword or filename extension). The javac tool already has to deal with multiple revisions. The JLS should be able to refer to old versions of the spec, too.

    Making "==" call ".equals" (with auto null support) and make not-null the default for vars are two important changes that Java should have but can't be done in a backwards compatible fashion.

  5. Oh, and I don't think "===" should exist either in mythical "source 7". Just make a "System.identical()" method or something. Too many easy choices cause confusion. TOOWTDI.

  6. The notion of identifying the specific language used by source code is obviously correct, utterly useful, would help to mitigate new and legacy "suboptimal" language design choices (e.g. autoboxing, type erasure, annotations), and would moot all those sad "not backward compatible" excuses used to stiffle innovation.

    Therefore, logically, an idea of such merit must rejected out of hand and opposed with all available resources.

    Next, you'll propose removing all the deprecated stuff from the JDK. Perish the thought.


Please be aware that by commenting you provide consent to associate your selected profile with your comment. Long comments or those with excessive links may be deleted by Blogger (not me!). All spam will be deleted.