groovy
  1. groovy
  2. GROOVY-2725

Semicolon required for certain generics declarations

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.4
    • Fix Version/s: 1.6-beta-1, 1.5.7
    • Component/s: parser-antlr
    • Labels:
      None
    • Number of attachments :
      0

      Description

      According to this thread:
      http://markmail.org/message/us25dkia37qif75f

      It seems that sometimes a semi-colon is required after a generics declaration with type coercion.
      The semi shouldn't be needed.

       import java.util.concurrent.atomic.AtomicInteger
      
       public class ThreadId
       {
        // Atomic integer containing the next thread ID to be assigned
        private static final AtomicInteger nextId = new AtomicInteger(0)
      
        // Thread local variable containing each thread's ID
        private static final ThreadLocal<Integer> threadId = [
                        initialValue: { return nextId.getAndIncrement() }
                        ] as ThreadLocal<Integer>;
       // The Semi-colon at the end of the prior line seems to be required.
      
      
        // Returns the current thread's unique ID, assigning it if necessary
        public static int get()
        {
            System.out.println( "Thread ID: " + threadId.get());
            return threadId.get();
        }
      
      
        public static void main( String[] args )
        {
            1.upto(3) {
                Thread.start { new ThreadId().get(); }
      
      
            }
        }
      
       }
      

        Activity

        Hide
        blackdrag blackdrag added a comment -

        this issue sure is puzzling.. I tried to fix it by adding several workarounds, but it seems the only thing that will be accepted after "] as ThreadLocal<Integer>" is the end of the class.

        Show
        blackdrag blackdrag added a comment - this issue sure is puzzling.. I tried to fix it by adding several workarounds, but it seems the only thing that will be accepted after "] as ThreadLocal<Integer>" is the end of the class.
        Hide
        blackdrag blackdrag added a comment -

        ok, looks like the grammar matches the nls after >, meaning it fails to recognize the command end.

        Show
        blackdrag blackdrag added a comment - ok, looks like the grammar matches the nls after >, meaning it fails to recognize the command end.
        Hide
        blackdrag blackdrag added a comment -

        found the right nls. fixed now

        Show
        blackdrag blackdrag added a comment - found the right nls. fixed now

          People

          • Assignee:
            blackdrag blackdrag
            Reporter:
            Guillaume Laforge
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: