[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] JDT rants

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ââ



  • 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?



Mickael Istria

Eclipse IDE developer, at Red Hat Developers community

Elected Committer Representative at the Eclipse Foundation board of directors