RatJava

Old Fortran weenies like me still remember with fondness (or loathing) RatFor. For those who don’t remember Fortran, you have to understand that it was the first compiled programming language. Consequently it made a lot of mistakes and had major design flaws. For instance, you couldn’t put anything except a line number or a comment marker in the first six characters of each line. That was a relic of its design for punched cards. (Remember those? Probably not if you’re under 40.) These design flaws weren’t trivial or academic problems. Spaceships could crash when you replaced a comma with a period, though the program would still compile.

RatFor was a 1970s era effort to clean up the language. It was an alternate syntax designed around the then hot-idea of structured programming. (OOP hadn’t escaped academia yet.) For instance, it added while loops and got rid of GOTO. It cleaned up the syntax by letting you write >= instead of .GE.. (Some of the early computers that Fortran ran on didn’t have lower case letters, much less angle brackets in their native character sets.) However, RatFor was compiled (more accurately preprocessed) to standard Fortran code, after which it used the same optimizers and libraries that standard Fortran did. That meant it was fully interoperable and could play in a world where not everyone was rational.

Fortran’s not the only language where this happens. For instance, JRuby is a way of writing Java code the Java VM in Ruby. That’s great if you like Ruby, but what if you actually like Java and just want to make it a little more rational? Well, as it so happens I just got an invitation to a Sun event on Monday where I expect Sun to finally pull the trigger and open source Java. Great. Let’s fork!

Well, not quite; but maybe we can finally clean up some of the little annoyances in the Java language, while still maintaining full compatibility with the Java VM and Java libraries; simply by making a few modifications to javac. (Of course, if I was really on the ball I would have suggested doing this with jikes years ago.)

Now remember. What follows are purely syntax sugar changes. We’re not going to change the libraries, and we’re not going to change the VM. We’re going to compile to real Java byte code that’s fully interoperable with existing programs without adding any extra classes that aren’t part of the standard library. That severely limits what we can do. Nonetheless there are some interesting possibilities here.

No semicolons

Why put semicolons at the end of every line? How many statements do you actually write that extend across multiple lines. Wouldn’t it make sense to make the unusual case (a multiline statement) require the special character? I suggest a backslash.

Downside: this will be tricky to integrate with for loops

Require braces for multiline statements

Smart developers have known for years that braceless multiline statements are bug prone. The problem is that the indentation can be actively misleading and cause bugs during code evolution and maintenance. For example, suppose you start with this if statement:

  if (x > 3)
    doSomething(x);
  // continue with rest of program...

The problem is sooner or later you or someone else is going to need add a line to that if statement, and you’ll end up with something like this:

  if (x > 3)
    y = x - 3;
    doSomething(x);

More often that you’d think, they forget to add the braces. The code will still compile, and on some paths it may even work correctly, but there’s a real bug here and it’s one that’s hard to spot because the indentation is actively contrary to what the code is really doing.

In fact, this was known well before Java was invented, including inside Sun. Consequently, it’s a bit of a shock that Java still allows this. It’s time to get rid of these.

switch-case statements

Have you ever written a switch statement that didn’t break after every case? I mean, one that wasn’t a bug? I actually have, but only when returning from each case. In practice, almost every other kind of breakless case is a bug, and those that aren’t are confusing. In particular, any algorithm that depends on case fall through is very surprising and hard to understand. Let’s make breaking after each case the default.

switch types

The switch statement is also too closely tied to the underlying representation. Because it compiles to one of two types of byte code instructions, it can only switch on ints or types castable to int. But why? Very often I find myself writing a big if-else block like this one just to pull out one case from a String, or other non-int type:

if (s.equals("foo")) {
 //...
}
else if (s.equals("bar") {
 //...
}
else if (s.equals("baz") {
 //...
}
else if (s.equals("yum") {
 //...
}
else {
 //...
}

This could be more obviously written as a switch statement. We’d just need to recognize the different type, and compile it to different byte code instructions.

Ban tabs

Tab characters are evil. They consistently much up source code and make it look awful as it’s moved from platform to platform, machine to machine, editor to editor, and even from editor to printer. They are a technology designed for typewriters. Is it any surprise they cause problems for computers?

The solution’s simple: forbid them. Any tab character appearing in a RatJava file will be a syntax error.

Multiline string literals

One of the most annoying things about writing HTML and XML code from a Java program is the constant need to use \n and + to create multiline string literals. For example, here’s a chunk of code that writes some HTML:

  out.write("<html>\n");
  out.write("<head>\n");
  out.write("<title>Mesathelioma</title>\n");
  out.write("</head><body>\n");
  out.write("<h1>Mesathelioma</h1>\n");

Let’s write it like this instead:

  out.write("<html>
  <head>
    <title>Mesathelioma</title>
  </head>
  <body>
  <h1>Mesathelioma</h1>";

Much cleaner. Much simpler. Much easier to read and maintain.

Make final the default

As John Ousterhout wrote in 1998:

Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse.

Inheritance is a powerful tool, but it takes extra work. Most estimates are that it takes about three times as much work to design a class for inheritance as one that’s not extensible. It requires a lot more thought and a lot more documentation as to exactly what subclasses can and cannot change. Given that most programmers don’t ever think about inheritance when designing classes, extensibility shouldn’t be the default.

Methods should only be allowed to be overridden if explicitly marked as such. This would indicate that the class designer has thought about what it means to override that method, and explicitly chosen to allow it.

Make UTF-8 the default and only encoding

In 2006, there’s little-to-no reason to choose any other encoding besides UTF-8. I’ve previously explained why this is true in the context of XML. However, unlike XML, Java doesn’t have embedded encoding identifiers. That makes it even more important to pick a standard encoding and stick to it. UTF-8 is the only sensible choice.

Anyway, that’s my fork plan. What do you want to change?

43 Responses to “RatJava”

  1. John Cowan Says:

    You’ll take away my hard tabs over my cold, dead copy of the “ex” editor.

    I think multiline strings are too error-prone. I’d rather have XML literals (compiled into code that sets up XOM objects, probably through a factory interface) instead.

    I think you will get howls from everywhere outside North America (and some places inside) if you don’t allow native encodings as well as UTF-8.

    Otherwise it all sounds good, if a bit too conservative. “Make no little plans; they have no power to fire men’s blood.”

  2. Curt Cox Says:

    It’s easy to come up with lots of really useful Java “skins”:
    1) defaults of “final” and “private”
    2) simple closures
    3) explicit boxing
    4) array notation for maps and lists
    5) operator overloading
    6) property support
    7) mathematical notation
    8) scientific notation (units)
    9) financial notation (currency)
    10) keywords in other languages
    11) EVIL instead of tab
    http://groups.google.com/group/javaposse/browse_frm/thread/38f92a3dd7eb2b01/0cd8c5552c4b0951?lnk=gst&q=theta&rnum=1&hl=en#0cd8c5552c4b0951

  3. Eric Jablow Says:

    Your string switch is typoed:

    if (s.equals(“foo”) {

    }

    needs a second close parenthesis after the “foo”. Unfortunately, this switch on a command string really should be done using something like a Map. It’s too bad that building simple operator objects is so clumsy in Java:

    Map commands = new HashMap();
    commands.put(“foo”, new FooCommand());
    commands.put(“bar”, new BarCommand());

    // Later…
    commands.get(commandString).execute();

  4. John Roth Says:

    Consider toolset compatability. Put in some kind of a header so that it’s easy for tools to recongnize which version of Java is being used.

    I think you’re going to get a lot of pushback on tabs versus spaces, just from the experiance of the Python community where significant indentation makes it a much more sensitive issue. The plan for Python 3.0 (as far as I understand it) is for the compiler to accept one or the other, but not both in the same file. That fixes the indentation problem in a way that doesn’t raise quite so many screams of rage.

    I like multi-line strings, but your example doesn’t hack it. Consider how Python does it: two strings in a row are concatinated by the compiler without the need for an operator. There’s also a special pair of brackets that encloses a multi-line string.

    John Roth

  5. cubiclegrrl Says:

    Now, now: I’m not even 39 and even *I* can remember punch cards, ol’ timer. Mom used to bring them home from work and we’d color on the backs! ;-)

    Amen to the curly-braces, though! We just had that issue over the weekend while I was trying to debug someone else’s code. (I was thoroughly brainwashed in school, the other developer is self-taught.)

  6. Charles Oliver Nutter Says:

    Semicolons: Semis actually make parsing a heckuvalot easier. Without semis, you have to make all sorts of ugly guesses for multiline statements, like ensuring that the + comes on the first line of a break, not the second. The backslash…maybe. It kinda smells.
    Multiline strings: They’re not bad…maybe the backslash should be used here? It’s already used to escape special characters…why not newlines (like for shell scripts and the like)?
    Braces required: GOOD. I make this official policy all the time. I would be willing to bend if there was the capability of using Ruby’s statement modifiers, as in “do something if (x == 5);” which is much more explicit than the single-line if we have now.
    switch with no fallthrough: probably good…I have a tendency to use it, though I probably shouldn’t.
    switch on other types: there certainly could be a “slow switch” that allows switching on other types, but the primary point of a switch is that it’s using numeric types to create a fast jump table.
    Tabs out: GOOD
    Final by default: C# went that way…but I think they’re wrong. I think we should be trending toward languages that are MORE open, not less. We need to trust our programmers rather than rap them on the knuckles 50 times in a day for doing the wrong thing.

    I’m also very interested in adding dynlang capabilities, but that’s outside the scope of this discussion :)

  7. Armin Haaf Says:

    I would include the possibility to reference methods and fields, e.g as in javadoc

    Method sizeMethod = ArrayList#size();

    Today many frameworks using reflection and often in testcases we need access to fields. It is anoying to go through String names which cannot refactored easy and cannot expanded by IDE.

  8. Guy Rixon Says:

    Instead of multi-line string literals as the default, how about literals as currently used in Java plus extra support for “here documents” as in Perl, bash etc.

  9. Brad Huffman Says:

    I hate NullPointerException, so a “nonnull” keyword would be nice for variables, parameters and return signatures.

  10. Augusto Sellhorn Says:

    There’s a JSR (305) for adding a non null annotation (@NonNull) that seems to do the trick;
    http://jcp.org/en/jsr/detail?id=305

  11. Jochen Bedersdorfer Says:

    Semicolons are fine in my book. They give you a visual clue that a statement has ended. I’m ok with that.

    No TABs? I think this problem was solved once and for all with Ctrl-Shift-F on Eclipse platforms (and a similar keystroke on Netbeans).

    I’d like to see methods being treated as first-class-citizens.
    It would be nice if you could reference them with a special syntax and, for example, use them wherever an interface type is needed. Behind the scenes an interface adapter is created which delegates the interface methods to the given method. This could work out-of-the-box for interfaces with one defined method.
    This change would simplify various code segments:

    button.addActionListener(this.getClass().okPressed(ActionEvent));
    
    which would translate to
    button.addActionListener(new ActionListeners() {
       public void actionPerformed(ActionEvent ae) {
         this.okPressed(ae);
       }
    });
    // or a generic helper class in side com.sun.

    Proposed Syntax for addressing methods:
    .getClass().(*)

    Other uses:
    new Thread(this.getClass().runIt()).start();

    instead of

    new Thead(new Runnable() { public void run() { runIt(); }}).start();

  12. Jochen Bedersdorfer Says:

    Darn, all my > and < have been stripped away.
    Proposed syntax was:
    [reference].getClass().([Formal parameters]*)

  13. Ed Davies Says:

    Spaceships could crash when you replaced a comma with a period:

    How about an overloaded function which takes one or two parameters?

    Complex f = new Complex(3.14159);
    Complex f = new Complex(3,14159);

    First creates a complex with a zero imaginary part as the author
    probably intended. Second creates a rather unlikely complex number.

    Easy mistake for a non-English European language speaker to make.

    Maybe RatJava should insist on a space after commas as list
    separators.

  14. Ed Davies Says:

    Require braces for multiline statements:

    I’d rather get rid of all braces and rely on the indentation to
    indicate the structure. As you point out, the indentation is a
    very strong cue to the program structure. Braces are just
    clutter – something Java’s not entirely short of.

    My concern with this is the muddle over the size of tabs, 4 or
    8 positions or whatever. (Personally, I think the tab size
    should be a parameter to the text MIME types, like the character
    encoding but that’s another discussion). Then you go on to
    ban tabs, so that’s OK.

  15. Augusto Sellhorn Says:

    Anybody download javac yet?

    Compiles fairly quick, which was surprising to me. Here’s a tutorial to get it to build easily from netbeans;
    http://nb-openjdk.netbeans.org/get-and-build.html

    I also tried compiling it with make under cygwin, but that’s not working for me. Ant works of course.

  16. nigel Says:

    I love these discussions – it’s amazing how if many of them were implemented (one statement per line as default), lose braces, switch on non integral data types then you’ve reinvented Visual Basic!

  17. Franky Dickson Says:

    1) In a heartbeat, introduce a new primitive type… date! Java has long ignored the foul-up that is the Calendar object for too long. In the interim I’d fix both Date and Calendar, they are both responsible for many heartaches (though I’ll acknowledge sometimes introduced by junior programmers)

    2) Fix generics. Type Erasure is nice and all, but you do need its meta information in the class file.

  18. Ed Davies Says:

    Sorry Franky, your first suggestion breaks the rules: “What follows are purely syntax sugar changes. We’re not going to change the libraries, and we’re not going to change the VM.”

    OTOH, yes; Java date handling is a complete catastrophe and desperately needs fixing.

  19. Ed Gu Says:

    Some zillion years ago I implemented a primitive type “complex” …
    by just working on the compiler side. So, something similiar might
    be possible with “date”.

    go and see
    http://www.ipd.uka.de/JavaParty/cj/

    wow, the web site is still there …

  20. Barend Garvelink Says:

    It would be nice if you could reference them with a special syntax and, for example, use them wherever an interface type is needed. Behind the scenes an interface adapter is created which delegates the interface methods to the given method. This could work out-of-the-box for interfaces with one defined method.

    The delegate/event keywords in C# do just this (the compiler generates a full-blown Observer designpattern underneath). It’s a nice feature; basically a compiler-checked function pointer.

    I’d definately like to have multiline strings.

    In a heartbeat, introduce a new primitive type… date!

    Date/time maths is way too complex for a primitive type (by that I mean there are far more desirable operations than there are operators). Besides, why re-invent the wheel? Joda-Time is truly excellent and could be made a mandatory replacement for the java.util.Calendar mess. Java would instantly go from having one of the worst date/time libraries in computing, to having one of the best.

  21. Tom Hawtin Says:

    Getting rid of semicolons good. Why not braces too? This is one case where Python makes an awful lot of sense.

  22. Christian Schlichtherle Says:

    The real good thing about open sourcing java is that now everyone can roll their own and will hopefully not trigger Sun anymore to pollute a clean design with mostly bad ideas like these.

  23. Daniel Serodio Says:

    What would the EOL character for multiline strings be? \\r ? \\n ? \\r\\n ? Why? I’d rather see the EOL character explicitly.
    wrt final: That would make creating mock objects for testing much harder! See http://blogs.objectmentor.com/ArticleS.MichaelFeathers.ItsTimeToDeprecateFinal

  24. Gili Says:

    It’s funny but I actually disagree with every single one of the your points, except two. It’s funnier still because I agree Java could use cleanup as you mention. My objections to your suggestions are as follows:

    1) While multi-line Java statements are the exception to the rule, I hate the *nix style of placing slashes at the end of a line to mean it spans to the next line. They simply make the code harder to read. I feel semicolons are actually the lesser evil here.

    2) People who require braces for one-line for statements and other one-liners piss me off :) If you use an IDE (and most people do) there is absolutely no way you will make this mistake because IDEs provide code auto-format and brace matching to avoid this very problem. Requiring braces reduces readability in my view. If you really want to fix this problem on the compiler level, force users to indent for single-line for statements.

    3) Making “break” default for switch statements… I actually agree with this point.

    4) switch types… I agree with this point.

    5) I disagree with baning tabs because many people on my team use indentation of size 4 and some even of size 8 which makes it impossible for me to read. If we were forced to use spaces we’d all have to agree on a single value. If, on the other hand, we all use tabs, each one of us can map the tab to a different number of spaces. If anything the problem with tabs is that most editors default to an indent of 8 which is just insane.

    6) Multi-line string literals seem nice on the surface but I bet you will run into silly problems whereby you have an invisible character at the end of a line which gets sent to the screen or file and you won’t notice it because you don’t have a quote delimiting the end of the line. Still, I would agree with this suggestion if IDEs make sure to highlight invisible characters at the end of each line for a multiline string (to avoid the aforementioned problem).

    7) I disagree that extensibility shouldn’t be the default. If anything I hate having to ask the original developer for permission to extend a given method because the turn-around time between my request and his next release usually ranges into months. I think making extensibility the default is the lesser evil here. Making final the default makes a lot of sense if you’re developing an operating system or a JDK where you absolutely cannot break backwards compatibility, but the vast majority of programmers simply do not work on such mammoth projects so why the exception to the rule the default behavior?

    8) Making UTF-8 the default is a baaaaaaaaaaaaaaaaaaaad idea. Why? Ever share code with a Japanese or Indian team? There is nothing worse than variables names and comments written in characters you can’t even type on your keyboard! It is just insane :) Readability goes right out the window.

  25. Osvaldo Doederlein Says:

    Require braces: Argh! I’ll rather copy Haskell and Python, where indentation == scope, and braces are never required. It’s more elegant, much cleaner, and forces developers to take care with formatting and indentation. Besides, modern IDEs/editors are so good in automating and validating code that you gotta be a vi/notepad-diehard to make the kinds of mistakes that are prevented by mandatory braces.

    Banning tabs: Disagree too. Tabs are great because they make indentation flexible. I like indentation to be 4 spaces, I hate it both shorter (messes up code) or longer (wastes spaces, I don’t have a 30″ monitor). With tabs I can see the code they way I like it, and all other developers in my team too. Indenting with spaces produces either a mess (each developer uses his preferred spacing) or dictatorship (the team leader mandates the size he likes). The arguments against tabs are also a relic from the era of primitive code editors. BTW, I wrote a simple but very neat utility that processes any text file and fixes its usage of tabs, forcing use of tabs at indentation positions (before first non-blank) but forbiding tabs elsewhere (after first non-blank). I’m trying to find some time to convert this into plugins for NetBeans and Eclipse, since none of the auto-formatters out there (including IDEs’ and even Jalopy) does exactly what I want.

  26. kirk Says:

    Isn’t it nice to know that now we can play with Java we can all have some fun changing the language to suite our personal tastes.

    It’s funny but I actually disagree with every single one of the your points, except two. It’s funnier still because I agree Java could use cleanup as you mention. My objections to your suggestions are as follows:

    1) The multi-line suggestion is interesting and while Charles has pointed out that this would make the job of the compiler more difficult…. I don’t really care all that much. On code readability I’m just not convinced that it would help all that much. The detractor is that just as the semi-colon is helpful to the compiler, it is just as helpful to the reader and that I do care about.

    2) I’m neutral on the brace issue. I personally don’t add them but when I do add stuff to an if statement I automatically add braces so it doesn’t seem like it should be that big a deal. However going to an indentation scheme sounds both interesting and potentially fragile. Maybe a nice one to experiement with.

    3) Making “break” default for switch statements… I think you’d want to do a code survey to see what the usual case is. If the majority of case statements end with break than +1 and lets add a fallthrough keyword. Otherwise -1.

    4) Switch and if are functional replacements for polymorphisum. We need to use them in Java because we have functional artifacts left-over from the C crowd (that couldn’t live without them for some unknown reason ;-)). The suggestion is; if you are finding a need for switch when using objects than there is most likely some polymorphic behavior that you’ve missed out on in your design. Unfortunately Swing forces this if (action.equals(“somestring”)) …. type of coding on you and if you really look at it, there could be a more effective use of polymorphisum (in most cases using a double dispatch) to ease the pain. Just as it was a much better solution to educate rather than continue to teach people how to use goto, it would be much better to educate with better design patterns than continue to teach people how to use switch (and to a lessor degree if-then-else).

    5) Tabs are a pain and lets face it, a relic of typewritters. Unless I’m word processing….. I don’t want to see them cos yeah.. sometimes I do perform quick edits in VI.

    6) Multi-line string literals seem ok.

    7) I echo the view of others that extensibility shouldn’t be the default. In fact I would argue that you could have your UTF-8 Strings and other implementations of String very very easily if java.lang.String wasn’t final. In this regards, the use of private is also damaging. IMHO protected should be the default and I’d almost consider removing the keyword final from the langauge. Things should be extensible and to use final and private for purposes of preventing others from extending is simply mothering.

    Some changes that I’d like to see. Autoboxing is either confusing (your code does unexpected things) or broken (eg == may or may not work as expected depending on which numbers you are using and we don’t have a reverse mapping from or 0 and null). Lets get rid of it. Smalltalk uses something known as immediate direct objects. These things look like objects in the langauge but are actually compiled to primitives. This goes a long way to normalizing and simplfying the language. It is also a great example of how information hiding allows us to easily change the implementation. You can’t overflow a number in Smalltalk because one it does get to big, the primitive gets replaced with the equivelent of a BigInteger (mutable of course). For those that may consider this to be a potential performance problem, I will always argue for correctness over performance. In this case I would argue that it is actually helpful to performance as it allows the underlying system to choose the most appropriate type for me. Currently I am forced to use BigInteger if I’m worried about overflow *even if it doesn’t occur*.

    Isn’t it odd how are different programming backgrounds have left us wanting those things that we are familiar with put into Java wither or not they belong.

  27. Christoph Says:

    Just a thought:

    Why not building Python 3000 on top of the JVM? Why not starting a debate with the Python-community about that? If Python 3000 will use the JVM instead of its own Python-VM there would be an alternative program-language that has lots of the demanded features that Java (TM) should have.

  28. Felipe Gaucho Says:

    you mean: ignore the culture of millions of programmers and force them to re-learn to type. I guess it could become a TYPO festival :))

  29. Stephen Colebourne Says:

    Some I agree with (require braces) and some I don’t (no semicolons, final by default).

    Switch on Strings may be gaining ground (Josh Bloch mentioned it recently). It can be achieved efficiently too by a compiler. The human codes a switch based on strings, the compiler creates an int-based bytecode switch based on the hashCode of the strings. Simple and fast. But requires that the strings are constants (which seems reasonable).

    Multiline string literals are better with a dedicated syntax:
    String multiline = “”"
    first line
    second line
    “”";

  30. Peter Reilly Says:

    I have made a blog entry about multi-line string literals:
    http://peter-reilly.blogspot.com/2006/11/multiline-strings-in-java-part-2.html
    To sum up.
    python’s multiline “”" and raw string handling is great and it
    is *very* *very* easy to add this to javac. – the diff file
    is only 205 lines long.

  31. Marcus Says:

    This could be an interesting project as a full pre-processor for Java. As many people have mentioned, I like some of your suggestions, and dislike others.

    As far as implementation, it may be possible to define certain preprocessing steps that would be used by a custom javac. For example, I may like muti-line literals, but not the lack of semi-colons. So, I could have a javac.properties file (or something) that would define what syntactic-sugar I want. The default would be to have nothing different from main-line java.

    I like the idea of multi-line strings, but I agree with Stephen Colebourne above that multi-line string should have their own syntax. For example, C# uses @”multi-line
    string
    goes here”;

    The only downside to this type of project is the lack of support you’d get from IDE’s that are so important in the java world… but it would be nice to see some sort of “blessed” preprocessing.

  32. Michael Says:

    >> Require braces for multiline statements

    OMG…absolutely!! People that are too lazy to put a brace for a single line block after a control structure or at least set up their IDE to automatically put one in annoy the hell out of me.

    As soon as you don’t put that brace at some point in the future a bug will occur because someone won’t notice that they need to add one when they add to the code.

    I actually have IntelliJ setup so it will add the braces around a single line block after a control structure during a code reformat…so a ctrl-alt-l defeats all the evil doers that didn’t add them originally!

  33. Philippe Lhoste Says:

    I agree with some statements, not with others, of course…
    - I often break my lines in two or more, because I like (and people at my job too…) long identifiers, but I don’t like having lines longer than 80 chars (or make it 120, 132, whatever).
    - I have the personal policy to add almost systematically braces, although sometime I omit them when I do a simple break or return. But sometime I regret these exceptions (adding debug code, for example…).
    - switch: I find it obsolete… It was good in C times were it was optimized by compilers, but it is probably not very useful in other languages. I mean, as somebody else pointed out, your switch type example calls for replacing it with a Map or similar structure. Of course, having functions (or methods) as first class citizens would help a lot, and would avoid aberrations like anonymous classes.
    Beside, even if I agree that break being more often used, it should be the default, you forgot a quite common case of fall-through: case ‘A’: case ‘B’: case ‘C’: doSomething(); break;
    In a redesign of a switch, one should extend the syntax to multiple values (as in Pascal): case ‘A’, ‘B’, ‘C’: and case ‘A’-'Z’:
    - Tabs. I disagree, I use only them, except at job where they chose spaces (by 3). Spaces are prone to error (if people type them all (!), they can miscount them). And I find annoying to have to move space by space where I can skip n char pos at once. And as somebody else pointed out, they are far more flexible.
    The worse case is the mix of tabs and spaces, of course (a tab to skip 8 chars, 4 spaces otherwise…).
    - Multiline strings: agree, the best syntax is Perl’s Here-Doc (also used in PHP). No ambiguity with regular strings.
    Strings are a kludge in Java: that’s a class with special status, the only one allowed to overload an operator, but in a shy way: why didn’t they overloaded the ==, instead of using the ugly equals? At least for the most common case of case-sensitive comparison.
    And the choice of \ as escape char is an horror when writing Windows paths (OK, should avoid it…) and regular expressions! At least, when designing the latest, they could have replaced backslash with another symbol.
    - UTF-8: I agree that’s a more sensible choice than UTF-16.

  34. jim d Says:

    Elliotte – some quick comments

    1)I love it!!! – especially the multi-line strings. This is by far my biggest pet peeve w/ the Java syntax. Creating long string literals in java feels like I’m trudging through mud.

    2)I’m all for UTF-8, But let’s actually *use* unicode. Take multi-line strings for example. Why not delimit them w/ the  ¶Pilcrow Sign (aka “paragraph” symbol). That would be more succinct and also save programmers from escaping double quotes all the time.

    That’s just the tip of the iceberg. How about using the actual math glyphs instead of the operator literals we use now? Or using the box-printing characters for formatting comments? There’s tons of opportunities to improve readability by using symbols that are more descriptive and tie to real-world concepts.

  35. Just grin and bear it… - RatJava 2.0 Says:

    [...] I have a number of pet peeves that I wish sun would just put straight into java, and a couple of others that can’t easily be done because they’d break backwards compatibility. Certainly not enough to warrant a fork, but while we’re procrastinating, let’s certainly NOT implement the ideas set forth here. [...]

  36. Eugene Kaganovich Says:

    I want OUT params.

  37. Casper Says:

    [RANT ON]
    I say fork Java and it can’t happen soon enough, listed in order of least horriblility:

    The VM:
    Since the JVM is now a multi-language thing, lets call it VM. In general it has gotten up to a good speed by now, but it is still a memmory hawk beyond anything else in the industry. SUN must have half a dusin marketing departments, consistancy please, now you adopted JSE 6.0 do not refer to it as java.version 1.6.0 – and no, you can not call it Java 2.

    The Syntax:
    As proposed by this blog entry, there are so many nifty things that could be done by thinking a little rather than copying the construct from C++. A lot less verbosity thanks, and more dynamic/flexible such that we can program into the language (idioms), not just on the language (patterns).

    The API:
    By far the worst. Date is broken, Calandar which was suppose to fix this is also broken and so are 100+ more general purpose classes. There’s really too much wrong here that I get a headache from thinking about it.
    [/RANT ON]

  38. boroko Says:

    Sometimes I want to handle a few exceptions the same way, so I would like this syntax added:

    try {
    blah
    }
    catch(ThisException, ThatException, MyException, YourException as Exception){
    blah;
    }
    catch(Exception e) {
    }

  39. Simon Says:

    I agree with:

    1. Multi-line string literals. What is the problem with implementing “if you find an unescaped-double-quote-character then everything up to the next unescaped-double-quote-character is one String literal”? Graphical IDEs will color the text appropriately so that you can see what is in your string literal.

    2. Allowing any Object to work as a switch case. There could be two variants:
    a) the current int-based version for ints and enums, and
    b) a generified Object-based version using equals for Objects.

    3. Making “final” the default extensibility option. I pair this with making “private” the default visibilty. In other words, you cannot see it or alter it unless I explicitly allow it. This is at odds with Gili (“turn-around time between my request and his next release usually ranges into months”) but the other developer has to maintain the integrity of their code for all users and “just say no” is the most conservative default.

  40. Pinner Blinn Says:

    No semicolons — thumbs down on this one. Long statements are a fact of life with long descriptive names, casts, and nestings. I see many statements that become more readable broken across multiple lines. I particularly like multi-line method calls, e.g.,

    SomeLongClassName output = someLongObjectName.methodCall(argument1,
    argument2,
    argument3);

    Backslashing multi-line statements? Insanely less readable.

    Require braces for multiline statements — Braces create compound statements by grouping the contained staements. You want to require them in cases where there is only one contained statement? Trivially helpful as a coding style but the existing definition of a “statement” is consistent. Emacs auto-indent catches any such coding errors easily.

    switch-case statements — I disagree. A trivial change, but it would undermine a lot of existing, well-thought-out code.

    switch types — I’m neutral on this one. (But how about allowing non-booleans as if-arguments? What’s wrong with C-style rules?)

    Ban tabs — I agree. Emacs auto-tabs for the java-mode, but allows untabification for saved code.

    Multiline string literals — Does this dovetail with your multiline issue? I think the current way (literal “\n”) is clearer. Perhaps it would help to introduce some new kind of bracketing for your multi-line Strings. BTW you seem to be missing some backslashes and a closing parenthesis in your examples.

  41. Pinner Blinn Says:

    Hey! My multi-line method call got mucked by wraparound. Should be like:

    Myclass output = obj. methcall(arg1,
    arg2,
    arg3);

    That is, args alligned vertically.

  42. Pinner Blinn Says:

    Hey again! Killed by whitespace suppression! Oh well, as described; not as rendered.

  43. Michael Agroskin Says:

    C# implements everything you just described plus much more. If you could just use C# compiler…

    Btw, Java bytecodes and Java VM are both misnomers. There are no Java VM but just VM produced by Sun, IBM, MSFT, Mono or whatever vendor, plus multiple compilers targeting particular VMs. Naming everything (language and VM) “Java” was just a marketing ploy by Sun.

    In .NET universe, there are virtual machines (produced by MSFT or Mono), there are core libraries, and there are multiple (20+ last time I checked) compilers produced by various vendors. Everything from Assembly to Perl.

Leave a Reply