[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-vision] Include JVM based languages in the Vision statement?
|
Hey Lars,
I got the feedback from Andy, reflecting on the past years of doing AspectJ and Groovy integration for Eclipse. Here are his thoughts and experiences. I think they provide quite valuable input.
Cheers,
-Martin
Thoughts from Andy:
=================
Just to say my opinions aren’t really any different given the latest public knowledge about groovy/grails and pivotal. If we were starting again with Groovy-Eclipse I’d try to go the black box route. In fact I’d probably do this for any eclipse integration going forward. Patching JDT and Groovy itself to bring them closer together is just too much of a maintenance job and problems (in this case mostly on the groovy side) occur because the groovy architecture isn’t designed to have this done to it. I’d rather call-out to groovyc to do whatever stuff it wants to do and then build what I needed in eclipse to understand what it had done. Much more like how groovyc is used in the wild (maven/gradle) and so more likely to behave the same (and similar to the IntelliJ model). That doesn’t mean you don’t need some smarts in eclipse - e.g. a recoverable parser to offer sensible content assist/navigation - but at least that would be decoupled from the compiler actually used to build the code. So when the latest compiler version comes out, you can use it with the tools immediately to at least build your code even if the eclipse integration hasn’t been updated to support that version.
I see this problem with Eclipse and JDT itself now. Other IDEs supports Java8 overnight (at least from a compilation point of view) because they delegate to javac. JDT in Eclipse 4.4 is still not finished with respect to Java 8 and our internal users are leaving Eclipse because of the bugs. The ones I’m aware of are fixed in Mars but that is some ways down the road - why is there not a fast route to get compiler fixes out to developers? Am I mistaken or are the only routes the twice yearly service refreshes? I can turn around a fully tested AspectJ fix in about 2 hours. When my users found a bug in the inferencing system in 4.4 I discovered it was fixed in 4.5 - I was a little embarrassed to tell them they had to wait months to get the fix in an official version. Why would they wait?
Concerning groovy, the patches to JDT core for groovy integration are mostly not suitable for inclusion in JDT without a significant amount of work. There are a handful where I’d say, yes, just a bit of tweaking and that could go in, but many of these things are very specific to groovy and would not necessarily make the next language easier to support, they’d just be making the groovy integration easier and JDT more complicated. The core architecture to the changes is still as described here https://spring.io/blog/2009/07/30/a-groovier-eclipse-experience/ - where you allow other compilers to participate in the JDT parse/resolve/compile steps. Without trying to use that model with another couple of languages I don’t know whether it’d be a suitable way to integrate them but it is a maintenance headache if both sides (JDT and the target language) are not onboard. It is hard to justify opening up JDT (core) when supporting the Java case is already extremely complicated and any opening up is going to increase complexity and probably decrease performance of Java compilation. Having been involved in adding some of the recent Java8 features to Eclipse, I can’t imagine the mind bending complexity if it was an even more complex codebase due to being more open to other languages - but that is just my opinion. It is one thing to get a language integration ‘working', it is quite another to polish it up suitable for inclusion in JDT given the number of users that would impact. For some reason at this point I’m reminded of the long standing bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=36939 which is 12 years old this year and that got nowhere. I think that is one of the bugs that causes AspectJ to still be used to weave eclipse so that AJDT can work although I haven’t looked at that weaving for a few years. Starting afresh, maybe that is another case where I’d call out to aspectj to do its work rather than tightly integrate it into eclipse.
Dani mentioned:
>>> - There is also something like a fork: a few years ago we've uploaded JDT Core to e4 (http://git.eclipse.org/c/e4/org.eclipse.jdt.core.git/) when people raised the voice that they want to work/help opening up JDT for Java-like languages (see bug 415563) - the number of commits in that repository is - guess what - zero.
I deliberately never spoke up on that bug at the time as I knew I wouldn’t have the cycles to do anything (I think I did get commit rights on that e4 thing though).
If people do have spare cycles, I’d rather see time spent sorting out eclipse as an IDE than spending time with other language integrations. If you unnecessarily complicate JDT you will only slow down Java 9 integration. If language integrations are necessary, I’d also steer clear of tight integrations where you (as the eclipse developer) have to do *all* the work, they just lead to maintenance headaches.
Really, to summarize:
- the groovy-eclipse changes as they are need a lot of work before they could go into JDT and it isn’t clear they’d make it easier to integrate other languages.
- the weaving adjustments we make for AJDT, they are possibly more suitable for opening up JDT but that 12year old bug that represents one such change has never gone anywhere, making it difficult to justify further investment.
- Two service refreshes of eclipse a year is far too slow a dev cycle. It worked 5years ago but is too infrequent now. How can developers get important JDT fixes faster? (By all means I might be wrong and there is some way to get them I’m not aware of, if there is then let me know!) I don’t want to tell my users to upgrade to a milestone of the next version, they don’t need all that change, they just need the latest supported fixes for one component.
- Maybe spend a little less time worrying about poor jobs of integrating other languages and sort out what is there now. Why can’t a project have multiple class paths (one per source folder)? Most of the pain I see is with mapping build system structures onto eclipse projects, it is another reason my guys are leaving eclipse behind.
If I had a choice as what language to sort out next (and the time), I’d be doing JS - probably abandon JSDT and look at something like tern/eclipse (which has issues of its own right now). With much less tight integrations into eclipse you can get the benefits of others working in the same space but who aren’t necessarily working directly on eclipse. For example, as tern is developed (maybe the inferencing engine is made smarter) the experience in eclipse gets better. Whereas building the inferencing engine directly in eclipse - you have to maintain that yourself.
Just my random thoughts, sorry if it is a bit rant-isn :) Just had these things on my mind for a while.
Andy
===========
> Am 12.01.2015 um 21:32 schrieb Lars Vogel <lars.vogel@xxxxxxxxxxx>:
>
> Hi Martin,
>
> did you had the chance to discuss the plans for Groovy@Eclipse with Andy?
>
> There is also a new Gradle for Eclipse tooling proposal https://projects.eclipse.org/proposals/eclipse-plug-ins-gradle. Do you know if that is based on the Privotal Gradle tooling or completely new?
>
> Best regards, Lars
>
> On Thu, Nov 27, 2014 at 2:46 PM, Martin Lippert <mlippert@xxxxxxxxx> wrote:
> Hey Lars,
>
> > Martin, as Pivotal employee, you might have close connections to Andy Clement from the Groovy tooling. I think Andy is the lead, but I'm not sure.
>
> Andy is the lead of the small tooling team here at Pivotal that I am part of, so he is actually by boss… :-)
>
> > If you have a connection, can you figure out if the Groovy tooling team would be willing to provide Gerrit reviews for their modifications in JDT core? Also if your Gradle tools team has certain requirements it would be good to know them.
>
> I can try to figure that out, sure. Since the AJDT weaving modifications to JDT, the Groovy-Eclipse JDT-based compiler and the Gradle tooling is all done by the same group (our tooling team), it should be pretty easy to get connected to them… :-)
>
> I will raise that in our next team call and probably our meetings that we are going to have in 1,5 weeks from now.
>
> Cheers,
> -Martin
>
>
>
>
> >
> > Best regards, Lars
> >
> >
> > On Wed, Nov 26, 2014 at 6:26 PM, Daniel Megert <daniel_megert@xxxxxxxxxx> wrote:
> > > If I understood Dani correctly that this would require additional resources, e.g., if Groovy wants improved support the Groovy developer would have to get involved as the JDT team does not have the resources to
> > > solve that alone.
> >
> > Almost. I said, that if parties are interest to do this then they have to *do* this. We've made attempts before, and I'll just repeat them here:
> > - A first attempt was made in 2005: http://www.eclipse.org/org/langsymp/, but when it came to do real work, there was silence.
> > - There is also something like a fork: a few years ago we've uploaded JDT Core to e4 (http://git.eclipse.org/c/e4/org.eclipse.jdt.core.git/) when people raised the voice that they want to work/help opening up JDT for Java-like languages (see bug 415563) - the number of commits in that repository is - guess what - zero.
> >
> > Dani
> >
> >
> >
> > From: Lars Vogel <lars.vogel@xxxxxxxxxxx>
> > To: For discussion regarding the future of the platform <platform-vision@xxxxxxxxxxx>
> > Date: 26.11.2014 18:19
> > Subject: [platform-vision] Include JVM based languages in the Vision statement?
> > Sent by: platform-vision-bounces@xxxxxxxxxxx
> >
> >
> >
> > Hi,
> >
> > one topic we discussed in the last weeks call was that we might want to include support for alternative JVM based languages into the vision.
> >
> > So our statement could become (for example):
> >
> > -----------
> > In the shorter term, the Eclipse platform and related projects needs additional focus and resources on meeting the expectations of Java developers in particular. Quality, performance, out-of-the-box experience, Maven, Gradle and JVM based languages support, and close affiliation with new Java releases are all part of the solution.
> > ----------------
> >
> > I think that would be a good signal for alternative JVM languages.
> >
> > If I understood Dani correctly that this would require additional resources, e.g., if Groovy wants improved support the Groovy developer would have to get involved as the JDT team does not have the resources to solve that alone.
> >
> > [Dani please correct me if that does not reflect our statement correctly.]
> >
> > What do the others on this list think about this suggestion? +1, 0 or -1 for this suggestion?
> >
> > Best regards, Lars
> >
> > --
> > Geschäftsführer
> >
> > vogella GmbH
> >
> > Haindaalwisch 17a, 22395 Hamburg
> > Amtsgericht Hamburg: HRB 127058
> > Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> > USt-IdNr.: DE284122352
> > Fax (032) 221739404, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com_______________________________________________
> > platform-vision mailing list
> > platform-vision@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/platform-vision
> >
> >
> > _______________________________________________
> > platform-vision mailing list
> > platform-vision@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/platform-vision
> >
> >
> >
> >
> > --
> > Geschäftsführer
> >
> > vogella GmbH
> >
> > Haindaalwisch 17a, 22395 Hamburg
> > Amtsgericht Hamburg: HRB 127058
> > Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> > USt-IdNr.: DE284122352
> > Fax (032) 221739404, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
> > _______________________________________________
> > platform-vision mailing list
> > platform-vision@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/platform-vision
>
> _______________________________________________
> platform-vision mailing list
> platform-vision@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-vision
>
>
>
> --
> Geschäftsführer
>
> vogella GmbH
>
> Haindaalwisch 17a, 22395 Hamburg
> Amtsgericht Hamburg: HRB 127058
> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> USt-IdNr.: DE284122352
> Fax (032) 221739404, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
> _______________________________________________
> platform-vision mailing list
> platform-vision@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-vision
