Friday, May 16, 2014

The Tokenizer Tail Wags The Java Syntax Dog

I'd like to register a complaint: the Java rules for package names are stupid.

Why the _ do the folder names, or components, have to be legal Java identifiers? Most probably because the package name is not designed as a syntactical element all by itself. Or even as a lexeme/tokens of its own, but a sequence of tokens. I suppose the Java syntax is designed as a sequence of lexeme/tokens. Probably under the influence of the long tradition of bottom-up syntax grammars, correct me if I am wrong.

And now, with the Java8 designers trying to reclaim some syntactic space from the past mistakes, another keyword is foreshadowed: underscore.

Warning about single underscore identifier

Already annoyed by Eclipse Luna's (4.4M7) treatment of warning about this (and I haven't found a way to turn it off), I just discovered an even more annoying behavior, which put the annoyance count at two bits, which overflowed into this one post. Unfortunately it's unlikely to leave zero in the annoyance column to the right.

This behavior is that Eclipse won't do the "Move Type to New File..." refactoring as long as this 'warning' is available to make a fuss over. No wait, sorry; apparently now it is an 'error'. This makes no sense at all.

And then for the prize: one can't even rename package names. Presumably because the package name is all retarded, with that un-scannable underscore in it. Maybe it'll be better in the next revision.

A workaround is to comment out any package declaration or import that contains a package name with this terrorist underscore in it. Though that is likely to give other errors, of course...

In fairness, there are probably not many that have discovered the awesome power in naming your packages '_'. But I happen to have it as part of a Brilliant System, so this could get really painful if the Java designers would take this bad idea to completion.

As I started out saying, it makes little sense for packages to have to be 'good' Java names anyway. The requirement could be dropped with no forward compatibility problems at all. Sure, backwards compatibility could be a problem, IOW you may want to be warned when you write code that can't be compiled as Java7 code. OTOH, then why not use a Java(N<8 all="" be="" check="" compiler="" it="" java="" ll="" of="" p="" syntax="" then="" to="" your="">
Do class loaders check class names to not contain keywords, and comply to be identifiers? I don't think it checks resources. And why should it check class names beyond some simple sanity checks? That's only added complexity.

And if no other argument convinces you, how about the fact that there exist other languages, and that the JVM is positioned as and adapted to being multi-lingual, aka polyglot? Why should other languages have to put up with this nonsense?


No comments:

Post a Comment