Product Version = NetBeans IDE 8.2 (Build 201609300101)
Operating System = Windows 10 version 10.0 running on amd64
Java; VM; Vendor = 1.8.0_131
Runtime = Java HotSpot(TM) 64-Bit Server VM 25.131-b11

Reproducibility: Happens every time

STEPS:
  * Create and edit any simple groovy class
  * Make sure to keep the Groovy code close to Java as you can (for reasons that become obvious)
  * Navigate around the Groovy code with Navigation shortcuts, etc
  * The experience is little better than editing plain text to be frank
  * Syntax analysis is EXTREMELY slow
  * Code completion is both slow and ineffective
  * Look at Netbeans options in case there is some Groovy support option to turn-on -- There is Nothing, one panel with a few choices -- Disappointing

  Rename the class file to ".Java"
  * Rename from "xxx.groovy" to "xxx.java"
  * By and large the SAME file will parse Very Quickly without errors, if you are not using many groovy features
  * Navigation is speed and effectiveness is top-notch
  * Code completion and syntax checking perform well
  * Small matters such as missing include headers, missing exception declarations are (now) highlighted

I don't thing this should be acceptable to the Netbeans project


ACTUAL:

  * This experience is not isolated.
  * Frankly Netbeans would server users better if it just treats Groovy code as if it iwere Java
  * Event the errors that would show for Groovy constructs would be work it in the time saved over discovering compile and minor issues the hard-way by running the groovy script
  * Furthermore things like debugging for Groovy is 3rd class.  Ruby and PHP have better debug support.
  * While it may be too much to ask that support be Groovy is as least as good as java, it should be good-enough -- 
  * At least a par with other main languages: PHP, Ruby, Kotlin, Scala, C++ -- To date it fails the mark.
  * This is frustrating because as the simple example shows, when the same file is renamed to Java -- Everything is there available to work.


EXPECTED:

  * Groovy to have direct support at least matching other main stream languages: C++, Java, Kotlin
  * Support hover show contents and other modern debugging facilities
  * If the editor checking cannot do the job add a Groovy lint option or something.

  Why this is IMPORTANT

These days we are using Gradle for all our builds and gradle files are Groovy files too. The Android builds rely on this.  Plugins and libraries are Groovy code.

As well we have found the Spock test framework to be the best fit for making high quality test suits -- Spock is groovy base.

Groovy is NOW an important part of the ecology.  If the tooling will not or cannot then alternatives that do support Groovy better become the preferred choice