Tag Archives: eclipse

Visual Studio 2010 – A bunch of code completion/navigation features I miss from Eclipse

For those of you who don’t know me, I’m a long-time Java developer (although I’ve spent plenty of time playing around with other languages and platforms). I’m also a big believer in developer tools – I create developer tools as part of my day job, and take advantage of tools as part of all the programming I do. Finally, I’m incredibly lazy and I’d spend all day playing video games if I could, so saving time is important to me  – every millisecond I save typing code is a millisecond more I can play World of Warcraft or Gran Turismo 5.

This weekend, I spent a bunch of time playing around with C#, ASP.NET MVC 3, and Visual Studio 2010. There are a lot of compelling things for me about this platform – C# is incredibly close to Java (even looking at IL code, I was surprised at how similar it was to Java bytecode) but has some features we Java developers can only dream about, there is a lot of progress within the whole .NET ecosystem, and the deployment mode of ASP.NET websites has potential to solve some problems I have deploying Java applications.

Overall, my experience making a few small ASP.NET websites this weekend was pretty good. For the purpose of this post, however, I’m going to concentrate on my experiences with Visual Studio’s code editor – specifically, some things I really miss from the JDT in Eclipse. It is important to keep in mind that this isn’t meant to be a comparison of the two tools and a declaration of  which one is better – the scope of my wishes are pretty narrow, and frankly, I don’t care which one is better since they rarely directly compete. It also isn’t meant to be a rant on how much Visual Studio sucks, as I think it is generally a good tool that, like any other tool, has  some things that I wish worked a little differently.

Also, I freely admit that some of my complaints/wishes may be invalid – maybe there is a way to do what I want, maybe what I want to do is stupid, or maybe there is a good reason I can’t do what I want. Feel free to correct me in the comments 🙂

With that rambling preamble out of the way, here are the things that I miss from Eclipse:

1. Open Type

It is really handy to be able to open a class by its name. Open Type.. is a considerably more efficient way to navigate to an arbitrary class than finding it in the project tree and it has saved me countless hours. Here is what it looks like in Eclipse:

A couple of things to note – 1) It can open any type in your workspace, whether it is a class you’ve written, one from a referenced library, or from the JDK. 2) It has pretty smart matching (ie, you can use * liberally or do something like NPE to have it find NullPointerException. 3) It is really fast.

I can’t tell you how much I use this every day. Visual Studio has similar capabilities, so let’s see what it looks like:

Not bad, but there are a few differences:

  • It doesn’t include referenced libraries. Actually, the scope of the navigation was a little tricky to figure out. It would occasionally return an external class, but only if I already had it open in another tab.
  • It also includes member variables and other items. I can see how this would sometimes be useful, but it can get noisy – it would be nice if there were an easy way to filter results.

2. Class Hierarchy

Another handy thing is to be able to quickly view the class hierarchy for any given type. It can be really useful to instantly know stuff like “What are this class’ super types?” or “What known implementations of this interface are there?”. Eclipse has a Type Hierarchy view that you can access by selecting any class name (it doesn’t have to be at the class declaration) and either right-clicking and selecting ‘Open Type Hierarchy’ or simply hitting F4. This opens a nice view of the type hierarchy that looks like this:

Visual Studio does have a type hierarchy viewer, but I couldn’t figure out how to get it to show any arbitrary type – you have to use the tree view to find the particular type you are looking for.

3. Code Complete

Code completion is a lazy developer’s best friend, and I’d heard great things about IntelliSense. My experience was that while it worked in more contexts than in Eclipse, the code complete in C# code felt really sub-optimal. First, let’s compare aut0-completing a method on the string class in both languages. Note: I’ve butchered these a little bit to get them to fit correctly in my blog. In both cases, they look a little better in the actual IDE.

Eclipse:

A couple of things that I want to point out about what you see in the code-complete popup:

  • It shows the full method signature, as well as other info. You see the return type (immediately after the method signature) and which class that method actually comes from (to the right of the return type). If there are overloaded methods, you see all of them.
  • If there are any JavaDocs associated with that method, you’ll see them on the right.
  • The symbol on the far left tells you what kind of method this is – public, protected, or private.

Now, let’s take a look at what a similar situation looks like in Visual Studio:

We get a roughly similar view, but the information is harder to process. Parameter information and the return type is instead located on the right-popout that you only see if you hover your mouse over the auto-complete candidate for a second. Worse, it is poorly formatted and the information doesn’t jump out at you like it does in the Eclipse scenario. Finally, if there are overloaded methods, you can’t see their signatures in this view.

4. Code Complete, Part 2

So, what happens once we hit ‘enter’ on one of those items?

Eclipse:

You’ll note that it not only inserts the rest of the method name, but stubs out the entire call for me with placeholders. As I type in real values for each of the placeholders, I can hit ‘tab’ to go to the next one. It also helpfully shows the parameter types in the tooltip above it. Really useful.

Visual Studio:

This is what it looks like in Visual Studio immediately after hitting ‘enter’. This is not very helpful. Hitting control + space at this point does nothing.

I have to think there is a way to get VS to do something more useful here (let me know if there is!), but really, it shouldn’t take another key combination or other action to get it to do something close to what Eclipse does.

5. Code Complete, Part 3

The scope of IntelliSense seemed really limited, too. For example, I was trying to use the DbContext class from System.Data.Entity. So, I typed DbC and then hit ctl+space, and wasn’t presented with anything useful. In Eclipse, if you were to do something similar, you’d see something like this:

Selecting one of those would cause Eclipse to automatically import the proper package.

Visual Studio clearly knows enough to do this – when I right-click on DbContext, it offers me the option of importing the correct namespace. Why couldn’t it do this as part of the IntelliSense functionality?

6. Sundry

There a ton of little things that annoyed me or felt sub-optimal, but didn’t warrant screenshots or their own section:

  • Eclipse has a feature where you can tell it to automatically put semi-colons and braces at the end of the line when you type them. This saves you having to cursor over or hit ‘end’ to do that (I told you I was lazy!).
  • Code Snippets are pretty cool – Eclipse has a similar feature. I have 2 problems with Visual Studio’s implementation: 1) They aren’t editable or createable through a simple interface in the IDE (that I can tell). 2) They show in the same IntelliSense popup as everything else, yet you hit ‘tab’ instead of ‘enter’ to activate them. Why?
  • It is kind of annoying to have to manually build the project to get certain things to happen. Why can’t it be continuously building like Eclipse Java projects? I realize this occasionally causes problems in Eclipse, but you can turn it off if you want.

Conclusion

Admittedly, when you use a tool for 8 or so hours per day for a number of years, you develop a ton of muscle memory, and using anything else feels really weird. I think, though, that some of the things I’ve pointed out above aren’t just ‘different’ in Eclipse, but are actually better, and it would be nice to see them in Visual Studio. I’m pretty open-minded, though, so if I’m somehow wrong, feel free to let me know via the comments!

Developing with Lift in Eclipse

A few weeks back, I wrote a blog entry lamenting the attitude toward IDEs in the Scala community. A few people told me that the tooling situation was better than I’d implied, so I thought I’d spend a bit of time looking at using Scala (and Lift specifically) in Eclipse. I think the situation is still a ways away from the tooling situation for Java, but it is actually quite good, and I wanted to post a quick tutorial for those interested in developing Lift in Eclipse.

Prerequisites

This post assumes that you already have Scala 2.8 final and Eclipse 3.6 on your system. For Eclipse, I recommend upping the Xmx setting if you haven’t already – I had issues when I had multiple Lift projects imported with Xmx set to 386.

Also, this tutorial is going to use Maven, not SBT. SBT may be a better build tool for Scala projects, but I’m not sure how well it works with m2eclipse – I’m going to play with that more later.

I also assume you know how to install plugins into Eclipse – I will create a more in-depth screencast for doing all of this if there is enough interest.

1. Install m2eclipse

Install m2eclipse using the following URL:

http://m2eclipse.sonatype.org/sites/m2e

If you need full instructions, you can go here:

http://m2eclipse.sonatype.org/installing-m2eclipse.html

2. Install the Scala IDE

Get the Scala IDE for Scala 2.8.0 and Eclipse Helios here:

http://download.scala-ide.org/nightly-update-helios-2.8.0.final

3. Install the m2eclipse-scala plugin

There is a configurer for m2eclipse that will setup Scala projects for you. You can install it using the directions here:

http://github.com/sonatype/m2eclipse-scala

The short version of those instructions:

1. Download the latest jar found at this url:

http://github.com/sonatype/m2eclipse-scala/downloads

2. Copy it to the dropins/ directory in your Eclipse installation

3. Restart Eclipse

4. Create a Lift project from an Archetype

Now you can create a new Lift project from the Archetype – this is effectively the same as running the mvn archetype:generate command that the Lift ‘Getting Started’ guide tells you to.

To do this, go to File > New > Other… > Maven > Maven Project

Follow the wizard until you get to the Select an Archetype screen. In the Catalog drop-down, select the Scala-Tools.org Catalog. A list of archetypes will appear below – you can filter down to just the Lift projects by typing ‘lift’ in the Filter box. Select one of the Scala 2.8/Lift 2.1 archetypes – I selected lift-archetype-basic_2.8.0. Click next and fill in the information (group id, artifact id, and version), and then click ‘Finish’.

m2eclipse will spend a few minutes setting up your project, downloading sources, and configuring it in Eclipse.

5. Import an existing Lift project (optional)

If you already have a Maven-based Lift project, you can import it. Just select File > Import.. > Maven > Existing Maven Projects and then follow the wizard to import your project. It will configure everything for you.

6. What you can do

So, now that you have a Maven-based Lift project in Eclipse, what can you do?

– Code complete, syntax highlighting, and real-time compiler errors are available

– Code navigation works quite well – you can CMD/Control + click a class or method to go right to it. Cmd + O will let you navigate the methods and fields in the current class.

– m2eclipse will download sources for you automatically – this is one of my favorite features. If you navigate to a class in the Scala API or Lift itself, you’ll see a rough decompiled view of the class for a second while m2eclips grabs the sources, then it will refresh with the actual source code. This is a really handy feature! It will also download scaladocs for you.

– You can setup an m2eclipse command to run Jetty within the IDE. Right-click on the web project and select ‘Run as…’ > Maven build… You’ll be presented with a screen for creating a new maven runtime configuration. In the Goals box, add jetty:run, then click ‘Run’. This configuration will be saved, so you can run your project in Jetty anytime you want by using the Run button in the menu bar. You can also do this for the mvn scala:cc command if you want.

7. Final thoughts / Feedback

I think the tooling situation for Scala and Lift is pretty good – much better than when I was doing a lot of Lift work last year. A lot of credit goes to Miles Sabin, David Bernard, and others who have done a lot of work to make this possible.

If this post was helpful, please let me know. I’m also interested to know if people are interested in more in this area, specifically:

1) A screencast showing how to do all of this, and what other features are available when working with Scala/Lift projects in Eclipse.

2) A single Eclipse feature that can tie all of the above features together into one easy-to-install package, along with setting up the m2eclipse Run As.. commands automatically for you.

If either of these interest you, or you have any other ideas, please let me know. You can either leave a comment on this post or email me directly (suresk@gmail.com). You may also follow me on Twitter – @suresk.

IDEs are not about code generation

There’s been a lot of interesting topics on Twitter, the JavaPosse Google Group, and various blogs recently about the “complexity” of the Scala language and whether it will be the next Java. This isn’t meant to be a post ripping on Scala – I respect the hard work from the talented individuals it took to create Scala, and I think it is a delightful language.

However, there is more to a language than the language itself, and I think the tooling situation in Scala leaves much to be desired. This is fixable – Miles Sabin and others are doing some excellent work to improve the tooling situation in Scala. What is more worrisome is the attitude that a lot of people in the Scala community seem to have toward IDEs.

Every week or so, someone pops into the Scala or Lift mailing list and asks about the IDE situation with Scala. They are met with a smattering of helpful replies pointing them to the IntelliJ plugin, the Eclipse plugin, someone’s favorite TextMate bundle or whatever. There are also, inevitably, a handful of people questioning the need for an IDE in the first place – “Scala is such an elegant language, why do you need an IDE?” or “Scala requires no code generation like Java does, so why do you need an IDE?” or “You don’t need anything more than emacs” are some common refrains.

Development environments are very personal, often irrational

I’ve been working on developer tools for the last several years, and one of my most memorable experiences was talking to developers about IDE usage a year or two back. I’m a die-hard Eclipse user, and I was talking to a group of equally die-hard IntelliJ users about what they liked about it. I remember walking away shocked, thinking “What the hell are these guys on? Over half the things they liked about IntelliJ are reasons I quit using it!” I’m sure had I shared my reasons for being an Eclipse enthusiast, they’d be thinking the same thing about me.

One of the biggest lessons I’ve learned over the past few years is that developers are often very passionate about their development setup and are loathe to change it. The best development environment is the one you are most productive in – whether that is Eclipse, Netbeans, IntelliJ, TextMate, vi, emacs, dictating your code to an intern, or writing it on a piece of paper and scanning it in. I’m not arguing that people who are happy writing Scala (or any other language) in emacs are idiots and should use a modern IDE, but I am arguing that there are millions of developers who derive significant productivity benefits from using one and we aren’t interested in stopping just because a new language has nicer syntax.

Not just code generation

A common argument against modern IDEs is that people use them largely for code generation, and thus, languages such as Scala that are generally more elegant and terse don’t really benefit from an IDE. This is way off the mark. Code generation is only a tiny part of IDE usage for most people, and Scala benefits from an IDE almost as much as Java does. Let’s look at some uses for a modern IDE such as IntelliJ or Eclipse:

1. Syntax Highlighting

Yes, most text editors do this perfectly well.

2. Debugging

Being able to debug your code from within the same program you are writing it has a lot of benefits.

3. Real-time compilation information

Being able to immediately see when you’ve done something that the compiler doesn’t approve of is a time-saver, and can be especially helpful when you are learning a new language.

4. Auto Complete

Is this a form of code generation? Maybe, but I’d argue it goes well beyond simply saving you a few keystrokes. For one, autocomplete functionality can be pretty useful when you can’t quite recall what the method name is, what parameters it requires, or what it returns – a nice language can’t help you avoid this, this is a problem of being able to instantly recall details about potentially thousands of classes in hundreds of libraries. Second, autocomplete in Eclipse (and other IDEs, I assume) can show you JavaDoc information inline, saving you a context switch out to your browser to view them.

5. Getting useful information about the code you are working with

What calls this method? Where is this variable referenced? What classes implement this interface? What does this class’ inheritance tree look like? All of these are pretty useful things to know, and IDEs make them trivial to discover.

6. Code navigation

Ctl+o in Eclipse opens up a list of methods in the current class, ctl+o again changes the scope to all of its parents – this makes it trivial to navigate to a specific method. Ctl+clicking on a class or method takes me directly to it.

7. Easy access to sources

Being able to jump directly to the source of a library is often useful as well, and this works quite well in current IDEs. M2eclipse will automatically download sources for Maven-based projects, which makes this even easier.

8. Refactoring

One of the benefits of statically typed languages such as Scala is that you can refactor your code with a high level of confidence that you haven’t horribly broken something. IDEs make this task even easier.

9. Version Control integration

It is also nice to be able to interact with a version control system directly from your IDE, without having to switch to another program to checkin your changes, perform merges, get new code, etc.

Final Thoughts

You’ll notice that of the uses for an IDE I’ve pointed out above (which are not a comprehensive list by any means), at least half of them are especially useful for someone learning a new language or framework. Yes, I know Scala has a REPL that is quite useful for when you are initially learning and playing around with the language, but I think an IDE is incredibly helpful for that phase when you’ve been playing with the language for a month or so and are now trying to do something productive with it – the instant feedback and wealth of information that an IDE can provide is incredibly valuable during that time.

This wasn’t intended to be a mean-spirited post and I hope it didn’t come across that way. I’m just trying to point out that IDEs are not crutches for hack programmers who want a tool to write code for them – IDEs are incredibly useful, even for Scala.

JDK 6 update 21 kind of breaks Eclipse on Windows

If you recently upgraded to JDK 6 update 21 on Windows and are noticing lots of Eclipse problems, I probably know why (and can show you how to fix it).

First, some background. The HotSpot VM (Sun’s implementation) has a concept known as the Permanent Generation, or PermGen for short. Its main purpose is to confound users and it is rumored to be going away in future releases of HotSpot. By default, the VM allocates 64 MB for the PermGen space, which is often enough. However, Eclipse installations with a lot of plugins tend to need a lot more.

Because Eclipse is meant to work on multiple JVMs, the stock eclipse.ini doesn’t directly set the PermGen size, it has a line that looks like this:

–launcher.XXMaxPermSize
256m

That will tell the Eclipse launcher to set the perm size, if it is running on the HotSpot VM. Unfortunately, it appears this quit working with update 21 – a quick check with VisualVM showed that this flag wasn’t working and no matter what you set it to, your VM would have only 64MB of PermGen space.

It appears that the cause of this is that with update 21, the vendor flag was changed to Oracle, which broke Eclipse’s VM detection code. Thus, the flag is never being passed through to the VM. It appears as though this only happens on Windows and only when running the Sun (sorry, I’ll never call it Oracle) JVM.

Fortunately, it is easy to fix. Simply add this flag to the -vmargs section of your eclipse.ini (it should be at or near the bottom):

-XX:MaxPermSize=256M

That will directly set the PermGen size and should fix any PermGen errors you were running into.

Who knows what else changing the vendor flag broke?