Re: [jdt-dev] [ide-dev] JDT rants

[Carsten Reckord <reckord@xxxxxxxx>]

Hi all,

 

All in all, given Mickael’s disclaimer about the rant, I think we didn’t do so bad. I certainly expected much worse… A few comments:

 

*Go to type*

I was actually about to ask a question of my own regarding Open Type.

 

But first, regarding his criticism about search phrases: Yes, IntelliJ allows to throw pretty much anything into its search box and you get a result – not just CamelCase notation or wildcards. Which can be nice, but can also be rather annoying, depending on how you use it and what your expectations are. I basically see two usage modes that can be at odds if not designed carefully (the same goes for code completion by the way):

1. Lookup/Search: I have a vague recollection of a type, but don’t know exactly. In that case, a completely relaxed interpretation of my search pattern is certainly helpful – if matches are ranked well. In his example, “testhan” will get me a match for “TestEventHandler”, and pretty fast as well, which is nice.
2. Quick navigation: I know exactly where I want to go, and want to get there in as few strokes as possible. Going with the articles example, when I type something like “TEHan”, I expect to get matches to exactly that CamelCase pattern and nothing else (or at least other matches only after those). I could see a benefit in also supporting “tehan” to get to his "TestEventHandler", if it’s all lower-case. IntelliJ fails really big here in my opinion – using a different example: Doing “Open Type” with “PCL” offers me “PluginClassloader” _before_ “PropertyChangeListener”, which is certainly not what I want.

 

The thing where I really agree with him is the “Open Type” vs “Open Resource” case. And I’d like to extend this to the “Open Type” vs “Open Type” case, if I have support for more than one language in my IDE. In an ideal world, there would only be a single “Open Type” dialog with symbols from all contributing languages, and either a smooth back-and-forth with the “Open Resource” dialog as suggested, or even integrate that as well (with some smart ranking/sorting).

 

This brings me to my initially mentioned question: I use perspectives pretty extensively, and I often face the problem that JDT’s “Open Type” (and other JDT actions) is not available in many of them, if I don’t happen to already have a Java editor open. This is because the whole JavaActionSet from JDT is bound to certain views and editor types, which often don’t exist in my non-coding perspectives, and so the whole action set is disabled. Is there a config option to tell Eclipse that I want this action set (or select actions) enabled _always_?

 

*Variable inspection*

I’ve never seen the problem he’s describing and am pretty happy with both the Variables view and Ctrl+Shift+I for inspecting variables and expressions in the code editor. The only issue I occasionally experience in that regard is that some actions sometimes get disabled briefly, probably when Eclipse is evaluating potential context changes, e.g. when hitting a breakpoint and activating editors and such as a consequence. In such cases, it can be a bit annoying when Ctrl+Shift+I or Ctrl+Shift+T  suddenly insert an “I” or “T” into the active editor instead…

 

*Step into selection*

It sounds like he’s running into a situation similar to the recent “Debugging unbearably slow in specific situation” discussion on jdt-dev. Not sure if it’s the same as in that thread, but I see this happening when stepping over methods with some sort of intense inner loops, especially stuff like IO or XML parsing. Stepping suddenly is orders of magnitude slower than running to the next breakpoint. My hotfix in these cases is usually to suspend the thread and add a breakpoint or use run to line inside the method where I want to stop next. I never thought about reporting this as a bug, because I always filed this under “JVM debugger limitations”…

 

*Shortcuts*

• He apparently didn’t get that the “run tests” shortcut has two strokes, not one. I.e. you don’t type “Alt+Shift+X+T” – which would be a finger breaker-, but “Alt+Shift+X” for “Run”, then “T” for Test. I guess those young whippersnappers don’t get the Emacs exposure that people used to ;P Or we do a bad job of presenting  this…
• “Run as Junit Test” does work from the Package Explorer, but only if you expand the file node “MyTest.java” and run it on the class node “MyTest” underneath. It – and other actions expecting a type - should probably be made to work on the file as well, taking the first (or first public) class inside.
• It’s the search theme again on the Keys preference page. “Run Test” should probably match “Run * Test”…
• Regarding  the command scope: I completely get where we’re coming from technically. But I also completely get where he’s coming from regarding user presentation and complexity. Can we maybe hide this by default and only offer it to resolve binding conflicts?
• This also ties into the “Open Type” vs “Open Type” remark from above a bit – I think we’re currently using scopes in a lot of places to create mutually exclusive handlers where instead contributing to a common handler in some way would make more sense (e.g. contribute a provider for Java types to a common “Open Type”). I imagine that that would get rid of a lot of the worst conflict cases, and would also improve consistency, because there’d just be one action per user function, for all scopes, instead of several ones with possibly different bindings and/or enablement issues…
• Side note: On the “Keys” page, “Copy command” and look at the copy: It doesn’t show its scope in the table until assigned a binding. And it’s pretty hard to figure out how to get rid of the copy again. “Restore Command” does it, but that’s less than intuitive…

 

 

Carsten Reckord

Lead Software Architect & co-founder

 

--

+49 (0)69 2475666-33 | reckord@xxxxxxxx | www.yatta.de

Yatta Solutions GmbH · Mainzer Landstraße 50 · 60325 Frankfurt a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director Johannes Jacop

 

From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On Behalf Of Mickael Istria
Sent: Wednesday, February 14, 2018 10:25 AM
To: Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>; Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Subject: [ide-dev] JDT rants

 

Hi all,

See http://twocentsonsoftware.blogspot.fr/2018/02/eclipse-vs-intellij-empirical-rant.html about a few rants about JDT UX.
All those points are really valid, please just make sure when you read it to bypass the nasty tone against the Eclipse IDE, and focus on the actual needs of this typical users and how Eclipse IDE (mostly JDT here) fails at optimizing the user satisfaction. Do you happen to know whether some of this concerns are already tracked in bugzilla?

Cheers,

--

Mickael Istria

Eclipse IDE developer, at Red Hat Developers community

Elected Committer Representative at the Eclipse Foundation board of directors