Double-semicolon in import statements

Alex Buckley alex.buckley at oracle.com
Fri Aug 2 16:07:30 PDT 2013


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");
>>>>     >>   }
>>>>     >> }
>>>>     >>
>>>>
>>>>
>>>
>>
>


More information about the compiler-dev mailing list