Double-semicolon in import statements

[Michel Trudeau]

Please note that Eclipse got it right here.  Meaning, an empty semicolon is only allowed after the last import stmt.

And IntelliJ got it wrong, but behaves slightly differently than Javac/Netbeans.

Michel

On Aug 2, 2013, at 5:01 PM, Jeremy Manson <jeremymanson at google.com> wrote:

That was why I asked - my assumption was that something like this is going to be present in a *lot* of Java code, which would then need to be fixed.

OTOH, Martin and I just searched a very large code base, and there were a vanishingly small number of these (this may be because eclipse treats the double semicolon as an error).  There were far, far more instances of classes that of accessed the private fields of superclasses.  Also, it doesn't seem to be present in any JDK code. Perhaps it isn't as big a problem as one might imagine.

Jeremy


On Fri, Aug 2, 2013 at 4:07 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
Another factor in determining whether to change the JLS or javac is the extent of the mis-implementation.

Here's an example. Jeremy had the insight to try an extra semicolon after an import declaration other than the last one, and javac accepted it. Suppose he'd also tried an extra semicolon after the package declaration, and that javac accepted it too. We would then have to accept that real-world code probably has more stray semicolons than we imagined, since javac has been allowing them all this time. That makes it harder to change javac to ban them, since it would spark a round of bug reports that have no good outcome for anyone. And so, I'd be more inclined than usual to change the JLS to accommodate javac.

Sadly, as of JDK8b98, I can report that javac accepts extra semicolons after the package declaration. I would be interested in other locations anyone might find, but right now, it's looking like JLS 7.3 will have to change.

Alex


On 8/2/2013 2:04 PM, Jonathan Gibbons wrote:
True,

FWIW, if we change javac such that the set of programs accepted by javac
is changed, we have an process (currently Oracle internal) to get
approval for such a change.   So, we would not simply change javac on a
whim to meet the spec; we would at least have other eyes looking at the
behavioral change to determine if it is "acceptable".

-- Jon


On 08/02/2013 02:00 PM, John Spicer wrote:

On Aug 2, 2013, at 4:45 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:

In general, it is better/simpler to change javac to conform to the
spec. (Except when it is not.)

Well, you sure can't argue with that statement  :-)

It is unfortunate that, in the example given, if the user swaps what
look like import declarations with a redundant semicolon the code
changes from being invalid to valid (or vice-versa if the code began
in the other sequence).

John.


-- Jon

On 08/02/2013 11:36 AM, Jeremy Manson wrote:
Just out of my own curiosity, who decides whether to change the spec
or javac?

Jeremy


On Fri, Aug 2, 2013 at 10:25 AM, John Spicer <jhs at edg.com
<mailto:jhs at edg.com>> wrote:


    On Aug 2, 2013, at 12:57 PM, Alex Buckley
    <alex.buckley at oracle.com <mailto:alex.buckley at oracle.com>> wrote:

    > Nope, the production is:
    >
    > CompilationUnit:
    >  PackageDeclarationopt ImportDeclarationsopt TypeDeclarationsopt
    >
    > So that's a javac bug. (And a reason for minimizing undue
    flexibility in the language in the first place.)

    I'm generally happier to ban things like extra semicolons, but
    it seems to me that "import x.y;;" should be allowed regardless
    of what follows.

    FWIW, out front end does give the appropriate error, the rules
    just seem odd to me.

    John.

    >
    > Alex
    >
    > On 8/1/2013 12:59 PM, Jeremy Manson wrote:
    >> Alex,
    >>
    >> What about the following, which also compiles?  Can you
    >> have ImportDeclaration TypeDeclaration ImportDeclaration?
    >>
    >> import java.util.HashMap;;
    >> import java.util.LinkedList;
    >>
    >> public class Semicolon {
    >>   public static void main(String[] args) {
    >>      System.out.println("This program should not compile");
    >>   }
    >> }
    >>







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130802/94a2598f/attachment.html