Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

[Maarten Boekhold]

Hi Jochen,

 

There is a language server under development at https://github.com/prominic/groovy-language-server.

 

Maarten



From: "Jochen Theodorou" 
I actually would love to look into a language
server implementation and use that for different IDEs then. But things
like joint compilation may not be solved by this.
 

 

Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

[MG]

@IntelliJ's build system: We use IntelliJ Groovy build, and have very 
vanilla requirements with regards to building our projects (basically 
it's just a larger number of interdependent modules with a bunch of 
artifacts), but alas even that does not work without a hitch: The 
"build-repeatedly-magically-fails"-problem I described here a while ago 
has (after years) thankfully disappeared, just to be replaced by a more 
benign one, where any change in one of a couple of our central Groovy 
modules makes the regular minimal rebuild fail, and we always have to 
rebuild the failing module in its entirety in that case. We can only 
live with it since those modules are relatively stable.*


Also Intellisense in the IntelliJ version we are currently using 
(2019.3.1) gets confused after a short while, and will mark correct code 
as invalid (as a weird workaround, one can comment out the "invalid" 
part of the line, and when commenting it back in, IntelliJ will be back 
on track most of the time).*


Which brings me to:
@"Another thing that comes to mind, JetBrains produces Kotlin, and 
Kotlin competes with Groovy - figure that one out!"
Alas, yes. As I have said here back when the discussion about Gradle 
Groovy vs Kotlin happened, there is an obvious conflict of interests 
here  - ideally you would want your IDE supplier to be as language 
agnostic as possible, which, due to the introduction of and ongoing 
investment in Kotlin, for Jetbrains is no longer the case.
I am still giving them the benefit of the doubt, but thinking back, 
IntelliJ Groovy support used to be top notch, and nowadays it is 
incomplete and suffers from quite a bit of problems. Hmmm...


In any case, even though the Groovy ecosystem is large & strong, in the 
end we are small fry, since it seems obvious to me their actual goal is 
not to replace Groovy, but over time to replace Java.
Then the #1 IDE and the #1 JVM language would come from one company in 
Prague. Not my dream scenario, for sure, after Java and the JVM 
landscape finally made big strides to being completely open source & 
much more community driven... (if I wanted MS (i.e. Visual Studio** & 
C#), I would not have returned to the JVM world from .NET in 2008)


Cheers,
mg

*None of that can be fixed by clearing the IntelliJ caches btw, we do 
that on a regular basis.
**Ironically enough, ReSharper by Jetbrains, at least back then, used to 
be the quintessential Visual Studio refactoring plugin back in 2008.




On 11/03/2020 19:36, Blake McBride wrote:

Hi MG,

The issues I've had with IntelliJ/JetBrains are general. IntelliJ is 
probably the best IDE out there but rather than make it even better 
they seem comfortable just staying a notch above the competition.  I 
guess they don't have to do better.


I've had issues with IntelliJ that are utterly and clearly wrong but 
they say it is a "feature".


Other times I spend hours trying to get IntelliJ to do something that 
ends up hidden deep in the bowels of IntelliJ rather than putting them 
where someone would look for them. This causes hours of wasted time, 
immense frustration, and needless contact with their support.


While their support is very responsive, they're too quick to 
dismiss nearly every issue.


Often a clear bug is discovered but their attitude is that not enough 
people use that feature so we're not going to fix it.  This attitude 
has been a big problem and might also be a factor in the Groovy issue.


Another thing that comes to mind, JetBrains produces Kotlin, and 
Kotlin competes with Groovy - figure that one out!


I've always thought that NetBeans was the most intuitive IDE.  Anytime 
I want to do something I guess at where it is and - boom - there it 
is!  I also see they're really making an effort to upgrade it.  I'll 
be watching them.


IntelliJ, like most build systems, has a convention over configuration 
attitude.  While this works really really well when you are building a 
conventional app, with either, when you try to drift the 
slightest from the convention (with good reason!) a five-minute setup 
can turn into weeks and constant headaches!!  In order to get around 
IntelliJ's and other build system's (Maven, Gradle, etc.) conventions, 
I ended up writing my own build system.  Problem is, I still need an 
IDE for developing and debugging.  I try not to use them for builds.


With regard to eclipse, personally, I've never worked with a worse IDE 
than eclipse.  eclipse:


1. the most unintuitive IDE I've ever used
2. the most buggy IDE I've ever used
3. the most out-of-date IDE I've ever used
4. the least supported IDE I've ever used

I've had a lot better luck with NetBeans!

A number of years ago I embarked, with a team, on a large Java 
project.  We started with eclipse.  We had endless memory issues and 
crashes.  We then switched to NetBeans and used it without 
incident for years.  I eventually switched to IntelliJ because of a 
promised feature.  I spent a lot of time moving this 

Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

[MG]

Hi Blake,

thanks for sharing your experience, I am also not the biggest Eclipse 
fan, though I found it not too bad as a Java IDE a while back.


It is funny that you should mention Netbeans - I had nearly forgotten 
about it*, but I actually had the same as experience as you did with 
Netbeans: It was very intuitive, besides Java (and C++) had great 
Javascript support out of the box (whereas Eclipse sucked at this, 
whatever plugin I tried), and in general the fact that it did not put 
you in plugin hell and was not based on a "generic editor for 
everything" base appealed to me. Alas Groovy support was severly 
outdated/lacking a few years back when I evaluated our IDE options - 
does anyone have any recent experiences on what the status of Netbeans 
is with regards to Groovy support ?


Cheers,
mg

*Partially because other (Java only) teams in my organization are using 
Eclipse, and it is always like "Why do you guys need IntelliJ then ?" - 
to which the answer of course used to be "Because it has unparalleled 
Groovy support"



On 11/03/2020 19:36, Blake McBride wrote:

Hi MG,

The issues I've had with IntelliJ/JetBrains are general. IntelliJ is 
probably the best IDE out there but rather than make it even better 
they seem comfortable just staying a notch above the competition.  I 
guess they don't have to do better.


I've had issues with IntelliJ that are utterly and clearly wrong but 
they say it is a "feature".


Other times I spend hours trying to get IntelliJ to do something that 
ends up hidden deep in the bowels of IntelliJ rather than putting them 
where someone would look for them. This causes hours of wasted time, 
immense frustration, and needless contact with their support.


While their support is very responsive, they're too quick to 
dismiss nearly every issue.


Often a clear bug is discovered but their attitude is that not enough 
people use that feature so we're not going to fix it.  This attitude 
has been a big problem and might also be a factor in the Groovy issue.


Another thing that comes to mind, JetBrains produces Kotlin, and 
Kotlin competes with Groovy - figure that one out!


I've always thought that NetBeans was the most intuitive IDE.  Anytime 
I want to do something I guess at where it is and - boom - there it 
is!  I also see they're really making an effort to upgrade it.  I'll 
be watching them.


IntelliJ, like most build systems, has a convention over configuration 
attitude.  While this works really really well when you are building a 
conventional app, with either, when you try to drift the 
slightest from the convention (with good reason!) a five-minute setup 
can turn into weeks and constant headaches!!  In order to get around 
IntelliJ's and other build system's (Maven, Gradle, etc.) conventions, 
I ended up writing my own build system.  Problem is, I still need an 
IDE for developing and debugging.  I try not to use them for builds.


With regard to eclipse, personally, I've never worked with a worse IDE 
than eclipse.  eclipse:


1. the most unintuitive IDE I've ever used
2. the most buggy IDE I've ever used
3. the most out-of-date IDE I've ever used
4. the least supported IDE I've ever used

I've had a lot better luck with NetBeans!

A number of years ago I embarked, with a team, on a large Java 
project.  We started with eclipse.  We had endless memory issues and 
crashes.  We then switched to NetBeans and used it without 
incident for years.  I eventually switched to IntelliJ because of a 
promised feature.  I spent a lot of time moving this project (10,000 
classes!) to IntelliJ only to find that the promised feature is 
extremely buggy.  When I reported the problems JetBrains told me that 
not enough people used the feature and they are no longer supporting it.


While IntelliJ's support of Kotlin will no doubt remain first-class, 
my inclination is that Groovy will experience declining support by 
JetBrains for the above reasons.  Moving forward, you may have better 
luck with NetBeans.


[rant over]

Thanks.

Blake

On Wed, Mar 11, 2020 at 12:33 PM MG > wrote:


Hi Blake,

first of all thank you, and all who voted since my post, for
taking the time, appreciated.

Second: Is your IntelliJ/Jetbrains experience directly tied to
Groovy or to issues in general ? The guy responsible for Groovy in
IntelliJ, Daniil Ovchinnikov, seems to need community created,
upvoted child tasks:
see for instance his comment on the "Support for Groovy 3 syntax"
issue on  5 Dec 2018 17:07:
"@Pradeep Bhardwaj don't worry, the work is in progress. Most of
Groovy 3 features are already supported, please see child tasks
and vote for some (or all) of them."

In any case upvoting is the only thing we can easily do. If this
has no effect, my team will have to look into the Eclipse option
again - great, after we convinced management that paying for
IntelliJ was the way to go :-/
mg

Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

[Blake McBride]

In an effort to solve my build problems I initially tried to create my own
build system but it turned into a nightmare.  Not wanting to devote the
time it would take to get working, I abandoned it.  I later came up with an
idea (that I'm sure isn't new) of a way to create a really simple build
system.  It only took me a few days to write and it works perfectly.  I am
now using it in production.  It's super easy to understand, does only what
needs to be done (minimal builds), and supports downloading and caching of
remote libraries and installing, configuring, and kicking off a development
web server.  It also works in Linux, Mac & Windows!

The code is in the "builder" directory of
https://github.com/blakemcbride/Kiss
It also includes the "bld" shell script.
I am considering re-writing it to make it a generic build system if there
is interest.

Blake

On Wed, Mar 11, 2020 at 4:33 PM Jochen Theodorou  wrote:

> On 11.03.20 19:36, Blake McBride wrote:
>
> [...]

But writing your own build system?
> That goes a bit too far I think.
> [...]
>
> bye Jochen
>

Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

[Jochen Theodorou]

On 11.03.20 19:36, Blake McBride wrote:
[...]

I've always thought that NetBeans was the most intuitive IDE.  Anytime I
want to do something I guess at where it is and - boom - there it is!  I
also see they're really making an effort to upgrade it.  I'll be
watching them.


Always had that with Eclipse - mostly from before it became unusable due
to CPU and memory requirements.


IntelliJ, like most build systems, has a convention over configuration
attitude.  While this works really really well when you are building a
conventional app, with either, when you try to drift the slightest from
the convention (with good reason!) a five-minute setup can turn into
weeks and constant headaches!!  In order to get around IntelliJ's and
other build system's (Maven, Gradle, etc.) conventions, I ended up
writing my own build system.  Problem is, I still need an IDE for
developing and debugging.  I try not to use them for builds.


in one project we had a task in our build to create the project
definition files, which was directly manipulating the XML ;) And yes, it
was a constant source of problems... but it was either that or IntelliJ
not being able to recognize our build setup properly... so much happened
in Intellij since then (2 years ago). But writing your own build system?
That goes a bit too far I think.


With regard to eclipse, personally, I've never worked with a worse IDE
than eclipse.  eclipse:

1. the most unintuitive IDE I've ever used
2. the most buggy IDE I've ever used
3. the most out-of-date IDE I've ever used
4. the least supported IDE I've ever used

I've had a lot better luck with NetBeans!


Eclipse had good times, these days not so much. I worked with Eclipse
mostly around 10 years ago. Back then NetBeans was lacking so many
features. But 10 years is a long time.

And Netbeans is now Apache Netbeans. That is actually a reason to
embrace it quite a bit. I actually would love to look into a language
server implementation and use that for different IDEs then. But things
like joint compilation may not be solved by this.
[...]

bye Jochen

Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

[Blake McBride]

Hi MG,

The issues I've had with IntelliJ/JetBrains are general.  IntelliJ is
probably the best IDE out there but rather than make it even better they
seem comfortable just staying a notch above the competition.  I guess they
don't have to do better.

I've had issues with IntelliJ that are utterly and clearly wrong but they
say it is a "feature".

Other times I spend hours trying to get IntelliJ to do something that ends
up hidden deep in the bowels of IntelliJ rather than putting them where
someone would look for them.  This causes hours of wasted time,
immense frustration, and needless contact with their support.

While their support is very responsive, they're too quick to dismiss nearly
every issue.

Often a clear bug is discovered but their attitude is that not enough
people use that feature so we're not going to fix it.  This attitude has
been a big problem and might also be a factor in the Groovy issue.

Another thing that comes to mind, JetBrains produces Kotlin, and Kotlin
competes with Groovy - figure that one out!

I've always thought that NetBeans was the most intuitive IDE.  Anytime I
want to do something I guess at where it is and - boom - there it is!  I
also see they're really making an effort to upgrade it.  I'll be watching
them.

IntelliJ, like most build systems, has a convention over configuration
attitude.  While this works really really well when you are building a
conventional app, with either, when you try to drift the slightest from the
convention (with good reason!) a five-minute setup can turn into weeks and
constant headaches!!  In order to get around IntelliJ's and other build
system's (Maven, Gradle, etc.) conventions, I ended up writing my own build
system.  Problem is, I still need an IDE for developing and debugging.  I
try not to use them for builds.

With regard to eclipse, personally, I've never worked with a worse IDE than
eclipse.  eclipse:

1. the most unintuitive IDE I've ever used
2. the most buggy IDE I've ever used
3. the most out-of-date IDE I've ever used
4. the least supported IDE I've ever used

I've had a lot better luck with NetBeans!

A number of years ago I embarked, with a team, on a large Java project.  We
started with eclipse.  We had endless memory issues and crashes.  We then
switched to NetBeans and used it without incident for years.  I eventually
switched to IntelliJ because of a promised feature.  I spent a lot of time
moving this project (10,000 classes!) to IntelliJ only to find that the
promised feature is extremely buggy.  When I reported the problems
JetBrains told me that not enough people used the feature and they are no
longer supporting it.

While IntelliJ's support of Kotlin will no doubt remain first-class, my
inclination is that Groovy will experience declining support by JetBrains
for the above reasons.  Moving forward, you may have better luck with
NetBeans.

[rant over]

Thanks.

Blake

On Wed, Mar 11, 2020 at 12:33 PM MG  wrote:

> Hi Blake,
>
> first of all thank you, and all who voted since my post, for taking the
> time, appreciated.
>
> Second: Is your IntelliJ/Jetbrains experience directly tied to Groovy or
> to issues in general ? The guy responsible for Groovy in IntelliJ, Daniil
> Ovchinnikov, seems to need community created, upvoted child tasks:
> see for instance his comment on the "Support for Groovy 3 syntax" issue
> on  5 Dec 2018 17:07:
> "@Pradeep Bhardwaj don't worry, the work is in progress. Most of Groovy 3
> features are already supported, please see child tasks and vote for some
> (or all) of them."
>
> In any case upvoting is the only thing we can easily do. If this has no
> effect, my team will have to look into the Eclipse option again - great,
> after we convinced management that paying for IntelliJ was the way to go :-/
> mg
>
>
> On 11/03/2020 17:50, Blake McBride wrote:
>
> Although I will vote up the Groovy issue you detail, being a long-time
> IntelliJ user, I can tell you first hand that upvoting an issue at
> JetBrains has no effect I am aware of.  I have seen critical issues get
> hundreds of votes and remain untouched for years.  They do what, when, and
> how they like.
>
> On Wed, Mar 11, 2020 at 11:27 AM MG  wrote:
>
>> Hi guys,
>>
>> up to this point, the first issue I created two days ago (see previous
>> post for link) has gotten zero votes - if no one is voting for these
>> issues, then it makes no sense for me to put them up, so please do not
>> only vote for the umbrella issue (which just got vote 37 - still
>> incredibly low given the large number of Groovy users out there), but
>> for each individual issue as well.
>>
>> Consider to not only vote for the features you yourself would
>> immediately use - all of these features were included after some
>> discussion, because they were considederd to make Groovy a better
>> language, and some things need time to establish themselves, but there
>> is no chance of that happening, if the most prevalent Groovy IDE marks
>> the code as invalid and 

Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

[MG]

Hi Blake,

first of all thank you, and all who voted since my post, for taking the 
time, appreciated.


Second: Is your IntelliJ/Jetbrains experience directly tied to Groovy or 
to issues in general ? The guy responsible for Groovy in IntelliJ, 
Daniil Ovchinnikov, seems to need community created, upvoted child tasks:
see for instance his comment on the "Support for Groovy 3 syntax" issue 
on  5 Dec 2018 17:07:
"@Pradeep Bhardwaj don't worry, the work is in progress. Most of Groovy 
3 features are already supported, please see child tasks and vote for 
some (or all) of them."


In any case upvoting is the only thing we can easily do. If this has no 
effect, my team will have to look into the Eclipse option again - great, 
after we convinced management that paying for IntelliJ was the way to go :-/

mg


On 11/03/2020 17:50, Blake McBride wrote:
Although I will vote up the Groovy issue you detail, being a long-time 
IntelliJ user, I can tell you first hand that upvoting an issue at 
JetBrains has no effect I am aware of.  I have seen critical issues 
get hundreds of votes and remain untouched for years.  They do what, 
when, and how they like.


On Wed, Mar 11, 2020 at 11:27 AM MG > wrote:


Hi guys,

up to this point, the first issue I created two days ago (see
previous
post for link) has gotten zero votes - if no one is voting for these
issues, then it makes no sense for me to put them up, so please do
not
only vote for the umbrella issue (which just got vote 37 - still
incredibly low given the large number of Groovy users out there), but
for each individual issue as well.

Consider to not only vote for the features you yourself would
immediately use - all of these features were included after some
discussion, because they were considederd to make Groovy a better
language, and some things need time to establish themselves, but
there
is no chance of that happening, if the most prevalent Groovy IDE
marks
the code as invalid and accordingly offers no
Intellisense/refactoring/etc support*.

Cheers,
mg

*I keep wondering what people new to Groovy think, if they try to
use a
feature introduced nearly 2 years ago, but their IDE marks it as
invalid
code...

Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

[Blake McBride]

Although I will vote up the Groovy issue you detail, being a long-time
IntelliJ user, I can tell you first hand that upvoting an issue at
JetBrains has no effect I am aware of.  I have seen critical issues get
hundreds of votes and remain untouched for years.  They do what, when, and
how they like.

On Wed, Mar 11, 2020 at 11:27 AM MG  wrote:

> Hi guys,
>
> up to this point, the first issue I created two days ago (see previous
> post for link) has gotten zero votes - if no one is voting for these
> issues, then it makes no sense for me to put them up, so please do not
> only vote for the umbrella issue (which just got vote 37 - still
> incredibly low given the large number of Groovy users out there), but
> for each individual issue as well.
>
> Consider to not only vote for the features you yourself would
> immediately use - all of these features were included after some
> discussion, because they were considederd to make Groovy a better
> language, and some things need time to establish themselves, but there
> is no chance of that happening, if the most prevalent Groovy IDE marks
> the code as invalid and accordingly offers no
> Intellisense/refactoring/etc support*.
>
> Cheers,
> mg
>
> *I keep wondering what people new to Groovy think, if they try to use a
> feature introduced nearly 2 years ago, but their IDE marks it as invalid
> code...
>
>
>
>
>
>