[
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?
|
I agree a lot with Andy's comments here.
Over the years and especially the later ones I'm more and more thinking
that for eclipse to continue to be useful and stay relevant it needs to
open up more external integration. Not everything can be done by java
osgi developed plugins. It just don't scale.
I believe CDT actually has many of these components for handling using
external tools better - like running external compilers, get the output
and turn into error markers. I know it won't be the *same* behavior as a
fully embedded JDT based compiler but it would at least allow for using
Java 9 *sooner* rather than later.
About JSDT then i'm reaching the same conclusion and we are actually
already on JBoss Tools side integrating with tern and instead of killing
JSDT we are looking at transmorphing JSDT so it can work with tern since
JSDT facets and other configuration is fine - its just the Javascript
language implementation that sucks - thus opening it up to allow tern to
do that will make a big difference. It is not a free lunch though since
tern does have its own share of issues when it comes to handling larger
projects.
/max
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
_______________________________________________
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
/max
http://about.me/maxandersen