Improve support for BigDecimal and BigInteger

[jeacott1]

Hi, I'm working on a legacy project full of code as below.
afaict this code should compile.

class SomeClass  {
    private static final BigDecimal bd = 1
...

but greclipse gives me
Type mismatch: cannot convert from int to BigDecimal SomeClass .groovy ... Java Problem

here's an ancient groovy ref showing a fix for this issue.
https://issues.apache.org/jira/browse/GROOVY-1141

why doesn't greclipse accept this as valid?

[eric-milles]

Can you provide more details and a larger sample? I am seeing no issue declaring BigDecimal and BigInteger constants. This is Groovy 2.5 in dynamic mode.

class Issue1289 {
  public static final BigDecimal bd = 1.0
  public static final BigInteger bi = 123
}

And referencing them from some Java source:

public class Temporary {
  public static void main(String[] args) {
    System.err.println(Issue1289.bd);
  }
}

[jeacott1]

@eric-milles I've been hunting this issue for a while, and I think I found it in a dependency that requires groovy 1.4. seems to blow everything up. I created a new project without all the detritis and I dont get this problem. so please ignore this. there's something else at play here.
thank you.

[eric-milles]

I did find a couple small issues with BigDecimal and BigInteger when experimenting with possible recreation scenarios. I will make a small fix and then close this issue. Thanks for raising this issue; it is good to see stuff that is iffy in real-world projects.

[jeacott1]

@eric-milles thanks!
fyi, whenever I encounter this BigDecimal issue, the error list never makes it to the eclipse problems tab anymore.
The only other real issue I have is that the ast processing locks up my ide for ages every time I make a change, and none of the ast activity shows up in the progress tab so I cant shut it down.

Cheers.

[eric-milles]

Is this occurring after updating to the latest snapshot build? Is there anything logged to the Error Log view or the Groovy Event Console in the Console view? You would need to open the event console before opening your source file(s). If not, you could also use the jvisualvm or flight recorder to capture a thread dump when the IDE appears to be locked up. If you could reduce to a very small project that still recreates, I might be able to take a deeper look on my end.

[jeacott1]

@eric-milles I have not noticed this issue previously, but I've also pulled in more modules that I haven't previously worked with (~200k lines of groovy, ~150k SLOC-P) so I cant say whether its related to the latest version or not - probably not. I am sure that its related to the time it takes to process all this groovy though. I have other modules with far less groovy and they've never particularly shown up the lock up issue, but I've never seen exceptions that don't make it to the problems view before. the exception swallowing seems to be related to missing dependencies in transiently dependent modules in the ide. after I fixed those the view seems to be populating again.
The groovy event console shows all the issues but does stop reporting occasionally whilst the ide is still clearly busy doing idk what.
while the ide is unresponsive (even after I've cancelled all the build events I can - in the progress view, there isnt always an option that relates to the build but when there is and I cancel its like hitting cancel in some windows dialogs, you just wait anyway), the groovy event view is just an endless stream of logs like the following with no way to stop it:

AST Transforms : 09:07:27 Local transform org.codehaus.groovy.transform.StaticTypesTransformation applied to ...
AST Transforms : 09:07:27 Local transform org.codehaus.groovy.transform.sc.StaticCompileTransformation applied to ...
AST Transforms : 09:07:27 Local transform org.codehaus.groovy.transform.StaticTypesTransformation applied to ...
AST Transforms : 09:07:27 Local transform org.codehaus.groovy.transform.StaticTypesTransformation applied to ...
AST Transforms : 09:07:27 Local transform org.codehaus.groovy.transform.StaticTypesTransformation applied to ...
AST Transforms : 09:07:27 Local transform org.codehaus.groovy.transform.StaticTypesTransformation applied to ...

If I've made a couple of edits and saved in rapid succession to a pom file, I can be waiting 20 minutes until I can interact with the ide again. Even after I'm allowed to interact again, the groovy event stream is still streaming strongly with events as above. If I click the 'close console' button at that point it doesnt have any effect effect. If I click the 'clear console' option it takes a few seconds and then refreshes. the speed of the event log is somewhat faster too. the progress view has just a single event stating 'reloading...', but clicking 'cancel operation' on this remaining option does nothing practical. when I tried this thismorning it took a further 10 minutes for the stream of ast events to eventually stop.
I've had to disable the automatic build option and just use the ide as an editor. its much faster for me to run the build from the cmd line and inspect the logs for errors.

Cheers.

[eric-milles]

Can't really say too much about that. I thought you were referring to a problem that the BigInteger stuff was running into. If you have new conditions that are exposing a new issue, feel free to open a new ticket. I can't say how long it should take to build since I don't know how many cross-dependencies you have.

I have used GDT with large sized projects and there should be no loss of UI responsiveness greater than one second. When these types of issues have come up previously, they were often loops in the compiler that were slow to converge often to do with complex generics.

[jeacott1]

@eric-milles ok, will do. I had thought the BigInteger stuff was related to the error reporting, but I think its just s symptom of things perhaps you already fixed. fyi, it takes the cmd line compiler in maven 15 seconds to compile that code, so its likely something related to the eclipse integration.