Eclipse Zone is brought to you in partnership with:

I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

What Would You Add to Eclipse 4.0?

03.25.2008
| 22021 views |
  • submit to reddit

Eclipse 4.0 was covered last Wednesday at an interesting presentation during EclipseCon. The core principles behind Eclipse 4.0 will be web enablement, and decreasing complexity.  However, it will be a lot more than just bringing RCP to the web, which the RAP project already does to a certain degree.

There was a debate on the eclipse newsgroups on the leadup to EclipseCon concerning e4, starting with this message. Jeff McAffer provided us with a last word on e4 in his post entitled Reset Required. Here, Jeff points out something very important:

"So the proposal is the real beginning of collaboration, community building and the work"

It's not due for another 2 years, and it's not a proper project just yet. As Mike Milinkovich said "it is theoretical at this point".  But already people are getting quite excited about it, and rightly so. It's the chance to change how desktop applications are perceived. If you've been on the sidelines watching the evolution of Eclipse and feel like adding to it, it's a good time to start committing code and getting involved in the Eclipse community.

If you had the chance to have your say, what would you add to Eclipse for the next major release? With the project still so early in it's incubation phase, now might be the time to shape the future.

Comments

David Qiao replied on Tue, 2008/03/25 - 11:20am

I would wish it can address some of the usability issues instead of adding new features. Eclipse usability is quite inferior to IntelliJ IDEA. To name a fews,

  1. Why I have to press F5 to refresh when a file is changed outside IDE? IntelliJ handles it automatically.
  2. Can I type in the expression on fly during so that I can quickly inspect several variables or expressions in the same inspection popup window?
  3. Why it doesn't switch back to Java perspective automatically when I stop debugging?
  4. Can I just single click instead of double click on the right margin area to set a BP? I don't know anything else I want to do when I click on it except setting a BP.
  5. Can it prompt me to import automatically when I used a class that is not in the import list?
  6. Still slow compare to IntelliJ where I open the same project on both IDEs.

Those are really small things but they are annoying. If you are IntelliJ users as well, you will know those I listed are exactly what IntelliJ does. It could be I missed some settings in Eclipse but regardless those should be default settings if so.

 

James Sugrue replied on Tue, 2008/03/25 - 11:34am in response to: David Qiao

Some interesting points in there David

I think switching back to Java perspective automatically is counter-intuitive.
It depends on what you want to do next, but chances are you're going to make some changes to a class that's open in an editor and run the debug session again. But then, that's just my use of the IDE.

But I agree on point 1 - it would be nice if it autorefreshed files changed outside the IDE, and maybe prompting the automatic import would be good (Ctrl-Space will autocomplete and import however).

David Qiao replied on Tue, 2008/03/25 - 11:43am

I guess I should add IntelliJ switches automatically to debug perspective when starting debug, v.s. Eclipse only switches when it reaches a BP. The reason I think it should switch automatically is because I have a bigger editor area for editing in Java perspective. As you said, you will edit the file when stopping debugg. That's why I want use my big editor area.

Stephen Strenn replied on Tue, 2008/03/25 - 11:55am in response to: David Qiao

+1 for David's suggestions! 

 

Point number 1 can be addressed via Window | Preferences | Workspace | Refresh Automatically. 

Padraig Butler replied on Tue, 2008/03/25 - 12:04pm

Once you select a working set, that working set is used everywhere by default, (ie. search, resource lookup, etc,etc) instead of having to select it again when you search or use some other feature

Chris Noe replied on Tue, 2008/03/25 - 12:47pm

Here's a feature that I have been wanting for a long time, and have never seen in any debugger:

The ability to do value searches on all or portions of the current object context, as a powerful way to explore what is stored where. In other words, I would like to be able to select "this", or any of the currently active instance variables in the Variables view, and then perform a (depth first) recursive search for a specified value. (One would probably have to specfiy the type or base type along with the value: String, Number, etc.)

This would have been handy again recently when I was plumbing the JSF object model looking for how things hang together. Instead I ended up expanding and collapsing looking for this and that for hours.

Nirav replied on Tue, 2008/03/25 - 1:07pm in response to: David Qiao

David,

For your point 1, you can set the workbench preference from Window->Preferences to do auto refresh resources. Doing that manually sucks though.

For your point 2, check out 'scrapbook page', you can type in expressions and this is not any new feature.

For your point 4, There can be plenty of markers on left margin, like quick fix, break point properties etc.

For your point 5, Eclipse is smartest when it comes to auto import, Save already does auto-import etc. in Europa

For your point 6. How slow is Eclipse than IntelliJ Idea? Eclipse comes with no optimized VM params for mem-usage, if you put in high heap initially depending on your workspace it will be lot more faster.

 

Hope that makes a fair comparision.

Nirav Thaker

Charles Simpson replied on Tue, 2008/03/25 - 1:02pm

I would like to have the ability to automatically create an Eclipse Monkey script for some things that must be done manually now. Adding a "Script This" button on a dialog or on the final dialog of a multi-dialog wizard would be very nice.

Nirav replied on Tue, 2008/03/25 - 1:05pm

I would prefer, hot templates and ability to add new and manipulate existing refactoring. Hope this makes in E4. Also, scripting macros would be wonderful!

Raveman Ravemanus replied on Tue, 2008/03/25 - 1:14pm in response to: Charles Simpson

i think stronger integration with eclipse monkey would be great, plus eclipse monkey should have Spring like templates to make it easier to use(i tried once to create wizard, but ... it wasnt easy), also better Abstract Syntax Tree(now to get for example source of method main you have to do it manually).

Also default best vm params would be great.

David Qiao replied on Tue, 2008/03/25 - 1:40pm in response to: Nirav

I am sure there are some tricks and hints somewhere I don't know.

For #1, that's better. It should be default.

For #2, it is strange that I have to save the scrapbook page somewhere as a file. I just want an "editable" inspection window. Or at least makes expression window having auto-competion feature and I can type in directly in the window without popping up another edit expression dialog.

For #4, It is the same thing in IntelliJ but IntelliJ expands the right margin to allow you to click. It reminds me another issue is sometimes BP icon is hidden behind the marker makes it harder to see.

For #5, not about auto-import; it is auto-prompt. It will save an extra click or exact key. Many of us use those Java IDEs all day long. Even saving just one extra click or key matters.

For #6, it is just my feeling when using Eclipse comparing with IntelliJ. I have no hard data to support it. My feeling is code editor is slower and switching to different tool window is slower.

Eric Anderton replied on Tue, 2008/03/25 - 1:44pm

"If you had the chance to have your say, what would you add to Eclipse for the next major release?"

One thing comes to mind:  Deeper, fuller and more complete online documentation, geared twoard plugin authors.

Basically this stems from trying to develop an RCP while using the Common Navigator framework.  I've been all over EclipseZone, eclipse.org and the rest, yet I have yet to see a comprehensive guide to what the common eclipse framework command id's are, or how to best bind and override them.  I've also had to delve into the source for various eclipse packages where the javadoc was inadequate or just plain vague - I shudder to think how early I'd have given up if it were closed source.

Also, if there were some way to radically decrease the memory footprint of Eclipse itself, that would be a killer feature in my book.

Raphael Valyi replied on Tue, 2008/03/25 - 3:20pm

I would definitely improve the package management system. I think it's way easier to install stuff and not having conficts on say Debian rather than Eclipse, weird isn't ?. I don't really know which one is faulty there. May be third party plugins repositories are too hardely discovered or may be the community should find ways to make it more clear when a plugin isn't compettive anymore, what's the best alternative then rather than create unneded outdated dependencies.

Also SWT performance on Linux sucks compared to Windows. Still Eclipse has a lot of good stuff for a free developmet stack! 

Marcello Teodori replied on Tue, 2008/03/25 - 7:59pm

Usability should be improved in lots of areas, popup menus have far too many items and plugins tend to add too many useless menus or interface duplication cluttering the overall system. Most of all if the plugin system has always been praised, it's impossible to say the same about its management UI, with all the restarts just to disable and uninstall things and the difference between features and plugins which I hope will be definitely archived whith osgi. Most of all I would really prefer a less-is-more approach, the minimal install is still too big for my tastes and I wish all the time I could safely remove things I don't need.

David Lim replied on Tue, 2008/03/25 - 8:07pm in response to: David Qiao

For suggestion 1, I work with a combination of command line and Eclipse so I actually prefer that Eclipse don't manually refresh. It's just the way I work, to not have to manually copy changes to another file first while I do some diff with older revisions.

Suggestion 5 better not be a default "feature". It's annoying to get prompted for an import while I'm typing. I know I'm typing the correct name (and if I don't I use autocomplete) so I'd rather it don't bug me for an import while I'm still in typing mode.

Vijay Aravamudhan replied on Tue, 2008/03/25 - 11:15pm

A few suggestions:

1) Most of the eclipse mailing lists are being used by both users and plugin writers. I would like the lists to be separated by the audience.

2) There are still many project-specific settings that are not stored in the .project/.classpath/.settings folders - some are stored still in binary format in various plugin-specific preferences. Please clean these up

3) There are tools which can convert an Eclipse project to an IntelliJ project - but not the other way around. If #2 is done so that all project-specific settings are in one file (preferably xml), writing such plugins for conversion will be much easier.

4) Please fix the links folder to allow relative paths (I know that there are a few bugs logged and I already keep tabs on them). Once this is done, the bundled downloads on the eclipse site can use this functionality to install to different directories keeping individual features separate (eg mylyn with eclipse would be installed into separate locations and linked so that the user can update individually). This could easily be done with something like izpack or openinstaller.

5) Update manager should be more streamlined. It should also cleanup old plugins for which newer versions are present - based on whether there is any strict dependency to the older version. 

Vijay Aravamudhan replied on Tue, 2008/03/25 - 11:24pm

Also:

1) There are a LOT of plugins which provide good functionality. But the quality of the code might not be too great. It would be good if there is a "mentoring" program from the core Eclipse community to help the plugin authors get "on track". This will ensure that knowledge about writing good code in the Eclipse-way is propagated to a wider community.

2) There is a lot of code in the core Eclipse plugins which were never refactored to use the latest-and-greatest paradigms. Please clean these up - a lot of plugin develoeprs use this same code as reference when they write their own plugins, thus expounding old/inefficient architectures/paradigms rather than using whats best at the time.

Just my $0.02 

James Sugrue replied on Wed, 2008/03/26 - 1:28am

Keep those ideas coming in - a lot of these can be covered in a 3.4/3.5 release rather than needing to wait for the next major release.

The comment about lack of documentation is interesting. If there's anything you'd like documented/explained better, please let us know and we'll try and cover it in EclipseZone.

 

James Sugrue replied on Wed, 2008/03/26 - 9:30am

There's some more information on e4 over on this article : http://www.adtmag.com/article.aspx?id=22310

 

Axel Rauschmayer replied on Wed, 2008/03/26 - 5:55pm

I've blogged [1,2] about how I would like to see Eclipse being improved (I'm making concrete suggestions in the blog posts):
  • For plugin developers: Make the Eclipse code (and config) base easier to discover and handle.
  • For Eclipse users: Make code easier to browse and edit.
[1] rauschma.blogspot.com/2008/03/eclipse-4-wishes-simplification-first.html
[2] rauschma.blogspot.com/2008/03/improving-code-browsing-in-eclipse.html

What I don't understand is how Eclipse can profit from being based on web technologies. Sure, supporting web developers in the Eclipse IDE is great, but why should the IDE itself be web-based? Or do they want to turn the RCP into something like GWT? Then RAP is not a good role model; it is too fat server-wise and not fat enough client-wise. When it comes to future web apps, my guess would be that both server and client will be coded in ECMAScript4. It is an incredibly powerful language that I'd love to see hosted on the JVM (probable, given Rhino) and supported by Eclipse.

Marcos Silva Pereira replied on Wed, 2008/03/26 - 11:33pm

1. Modules. If I could create modules like I in IDEA, my workspace would be so much more organized.

2. Interoperability with other IDEs: NetBeans have a Eclipse Importer. IDEA has a Eclipse Importer. Eclipse could have a import for projects from other IDEs. 

Kind Regards

Zviki Cohen replied on Thu, 2008/03/27 - 4:17am

Martin Sveden replied on Thu, 2008/03/27 - 7:04am

In Eclipse, for auto-import, try ctrl+shift+o, it adds needed imports and removes unused ones. And, if you start typing a classname and press ctrl+spacebar you'll get suggestions for completion and if the class you choose wasn't imported it will be. Easy.

Nils Kilden-pedersen replied on Thu, 2008/03/27 - 11:07am

Word wrap.

Zviki Cohen replied on Thu, 2008/03/27 - 11:42am

@Martin - you can do it even simpler by using Save Actions. That way, the "organize imports" will happen automatically when you save. See my post about it.

 Also, another cool tip, you can type an abbreviated name of the class and use auto-complete to get the full name as well. It is very cool. For example, support you have a class name MyClassWithLongName, you can just type MCWLN, hit ctrl+space, and magic will happen. It looks for the classes the same way as the "Open Type" box does. So, if you're looking for ArrayList you can type ArrLi, ctrl-space, and get the full name.

 

Pete Cox replied on Thu, 2008/03/27 - 6:16pm in response to: Raphael Valyi

On the subject of package integration, it'd be nice if the eclipse download was split up into dependant packages.

e.g. The latest NeatBeans download, advertised by Geertjan recently, for ubuntu hardy plays nicer in terms of referencing libraries as standard dpkg dependencies.

Eclipse on the other hand bundles ant/lucene/tomcat/junit and possibly others one already has installed on one's system within a great big download.

So every time there's a new revision, tens of megabytes need to be downloaded.

I'd prefer to install plugin modules, that shared libs, via synaptic than some poxy IDE specific mechanism. Why have 4 version of ant/junit and other cruft on one's machine?

Maybe a google summer of code idea there for pluggable backends!

Pete Cox replied on Thu, 2008/03/27 - 6:26pm in response to: Pete Cox

Oops, they seemed to have fixed that in the latest packages!

More incentive to upgrade! :)

Roman Mastor replied on Fri, 2008/03/28 - 5:28pm

I really like Eclipse and I am still discovering new Features after 1 year of developing. But what really sucks is that you can't switch from one editor to the next via an *easy* shortcut like you are used to in most editors like kate, gedit using ALT + 1|2|3|... It's such a basic thing you have to do, switching from one editor to the next - why the hell does it have to be so complicated?

Roman Mastor replied on Fri, 2008/03/28 - 5:32pm

Oh' and maybe more themes would be nice as well :-) And in package explorer you should have more sorting options, like "sort files by name and not by ending" so you can have these together: BasePage.java BasePage.html

Johan Compagner replied on Fri, 2008/03/28 - 6:29pm in response to: Roman Mastor

Most of you should really use the key combination CTRL-SHIFT-L a few times when you have a perspective/editor open and see what is all possible.

for example editor management: CTRL-F6 (forward CTRL-SHIFT-F6 backwards) or CTRL-E (type beginning of the filename in the editor.)

i dont know directly how to switch to editor 1 or 2 if you are at 5, But that only make sense to the open editors you see i guess so that is what 5 or 8 from the 20+ you can have open? In that case CTRL-E is your friend

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.