Over a million developers have joined DZone.

Behind The Scenes: The nWire Plug-in

DZone's Guide to

Behind The Scenes: The nWire Plug-in

· Java Zone
Free Resource

Learn how to troubleshoot and diagnose some of the most common performance issues in Java today. Brought to you in partnership with AppDynamics.

Once in a while, a plug-in comes along for Eclipse that showcases the possibilities that are available by integrating with the IDE and making use of the frameworks available. Zviki Cohen is the creator of the nWire plug-in for Eclipse, a tool that does just that. I met up with Zviki to find out more about nWire, and the important process of creating a commercial plug-in for Eclipse. We also discussed his predictions for the future of Eclipse, and the tips that he would give to developers who want to write on top of the Eclipse platform.

Win a Copy Of nWire. Zviki has kindly provided EclipseZone readers the chance to win one of three licences for nWire. To enter, just leave a comment at this article. 



James Sugrue: Hi Zviki, Could you introduce yourself,and tell us a little about your experience as a software developer?

Zviki Cohen: My name is Zviki Cohen, I'm 36, married to Elinor and living in Tel Aviv, Israel. I hold a B.Sc. from the Technion, Israel Institute of Technology. I began programming when I was 10 and, up until this day, developing software is my profession and my passion. My most recent position was with Amdocs (NYSE: DOX), a leading ISV in the field of Telecommunications. I worked as a programmer, a team leader, a systems analyst, a project manager and finally as the chief architect of the Amdocs Self Service platform. For the past 7 years I'm in the Java world. Before that I was working with Microsoft tools.

Sugrue: What is the motivation behind your latest tool, nWire? What does the tool solve?

Cohen: The idea developed as a result of my experience in Amdocs. I worked on a very large system with a complex, tiered architecture. There was a custom dependency injection framework along with J2EE and Struts, which made tracking components in the application a true nightmare. It took about 6 months to fully train a new developer. More than 50% of the work was maintenance. People spent more time figuring out what was going on than actually writing code. I had to find a way to simplify this. The architecture made each component simple to read and understand, but also made it too difficult to see the big picture of how those simple components are connected together to achieve the desired functionality. 

Sugrue: You've released the tool as an Eclipse plugin. Would you consider releasing it in any other format, or for any other IDE?

Cohen: I see great potential in the Eclipse market. Nevertheless, nWire may be offered for other IDEs, including Visual Studio, but it won't happen in 2009. nWire is tightly integrated with Eclipse so porting it to a different platform would mean a massive rewrite. It is also possible to release nWire as a standalone RCP tool, however, with the current feature set, nWire makes more sense when coupled with the IDE. 

Sugrue: How easy do you find developing plugins for Eclipse?

Cohen: It is relatively easy and even fun. There's an advantage to Eclipse plugins: it's all Java and all in the JVM. Unlike web applications and other multi-disciplinary systems, you need one set of tools and skills, end to end. The coding and debugging is straightforward as a result. The APIs are extensive and, once you get the principle, simple to use. Having said that, it does suffer from lack of documentation and examples. 

Sugrue: Can you give us an overview of how nWire is designed "under the hood"?

Cohen: nWire is built from mainly 3 parts, each in its' own plugin:
  • The core engine which mainly handles the repository of components and associations.
  • A front-end which includes the views - navigator and visualizer. It is driven by meta-data which determines the presentation for different types of elements.
  • Analysis plugins which handle the static code analysis for different languages and frameworks. The current offering includes Java analysis which is based on JDT.

The backbone framework is Spring OSGi. I am a big fan of Spring and Dependancy Injection in general. I believe it adds flexibility and removes hard coded dependencies. As a repository I use H2 Database: an incredibly lightweight (single Jar) yet robust database written in Java. If you are looking for an embedded database in Java, you should check it out. I use Apache Lucene for indexing and almost every existing Apache Commons library there is. 
Sugrue: What plugins or projects did you use for inspiration?

Cohen: One earlier source of inspiration was M7 NitroX (which became BEA Workshop, which became Oracle Workshop for WebLogic). It was the best Struts 1.x tool I came across and it would cleverly analyze and present the associations between Java class, Struts action mappings and JSPs. The UI of nWire was partially inspired by Mac OS X: the navigator dynamic column view has some common cues with the Finder column view. It is easier to read and navigate than a traditional tree, especially when the amount of data is overwhelming.

From the technical perspective, I believe that learning from reading code is the safest way to go. I learned a lot from the Eclipse source code and from JDT in particular. The Spring IDE source code was also a great resource for ideas and examples of how to do it right. 

Sugrue: What are the core enabling technologies that you have used?

Cohen: nWire is a fairly standard plugin, so the basics like OSGi and SWT are there. I've used JDT for the Java analysis part. It is extremely robust and it made the work a whole lot easier. 

One particular plugin I've used is Zest. Zest, currently part of GEF, is the Eclipse visualization toolkit. Zest is easy to use. It took me less than a day to get from a model to a running visualization, despite the sparse documentation. A word of caution, though: I found several bugs which made it difficult for me to customize Zest and get it to production quality. Eventually, I fixed my own code and opened defects regarding each of the changes I made (I don't have committer status).

Sugrue: What are the projects that you are most interested in within the Eclipse community?

Cohen: That's a tough question, there's just so much going on. DLTK (Dynamic Languages Tool Kit) is an interesting project and consider this a hint on possible future direction of nWire. There's a lot of interest around dynamic languages so this tool is a key element for making Eclipse the tool of choice for wider target audience. I also keep an open eye on the basics: the platform itself, especially P2, SWT and PDE. 

Sugrue: Can you give some tips on good plugin development?

Cohen: The documentation and examples are OK, but limited. To deal with this:
  • "Use the source" (not an original): have all the sources of all the libraries you use readily available. Don't be afraid to dive into the source: it is usually quicker and more reliable than reading manuals, sifting google search results and waiting for answers on forums.
  • Get good examples: I mentioned the Spring IDE source code earlier. Most of the Eclipse sub-projects are also great to learn from. Connect to the Eclipse CVS and check-out entire projects to get all the details on how to configure the projects correctly.

It takes very little effort to increase your target audience:
  • There is still a big market share using Eclipse 3.3. Throughout my work, I found only a couple of places where I needed 3.4-only APIs and quickly worked around those. Be sure to test your plugin with an Eclipse 3.3 target. 
  • Eclipse is not fully cross-platform, especially not SWT. Yet, the differences are minor. It took me less than a day to set up an Ubuntu machine using VMWare and correct the minor issues I encountered. It was enough to add Ubuntu support to my plugin.

Finally, don't skimp on tools:
  • It is likely that you will need to run several instances of Eclipse: for development, for debugging and another one for reference and testing ideas. Make sure you get a strong machine and at least 4 GB memory. I don't want to start a "holy war", but I find Mac OS X to be a better OS for running Eclipse. 
  • Eclipse is free. But not all tools are. If you come a cross a tool that can save you time: its' ROI will usually be worth it. 

Sugrue: What are your future plans for nWire?

Cohen: The next step is adding support for more languages and frameworks. nWire is designed to be extended and enhanced. Java is the first stop, but not the final destination. The next target is already in the process. It is still early to reveal more details. All I can say is that I'm very excited about it. 

The nWire vision is to create one unified view of all the application components and their associations, regardless of the programming language. Adding more languages and frameworks is an important step towards that vision. nWire will also be open for customizations in the future. You can read more about it here.

The base tools, the navigator and the visualizer, will also be improved. The queue is full of enhancements like: customizable filters, improved graph layout and much more. 

Sugrue: Can we expect any other plugins from your company?

Cohen: The focus is nWire at the moment. Like I said, there is a long roadmap for the product. There are other excellent ideas, but nothing concrete. 

Sugrue: What are your predictions for the future of Eclipse? Will it continue  it's industry dominance?

Cohen: Eclipse will continue to grow. Adoption of online IDEs is still years away, especially in the enterprise: I do hope the main purpose of Eclipse as a desktop IDE will not lose focus. We are seeing decline in desktop application development and the real battle will be on providing a rich web platform. e4 has potential in the enterprise market and a lot will be determined by the quality of the tools and ease of development.

Sugrue: What advice would you give to people who wish to make money from  software, particularly Eclipse plugins?

Cohen: I'm not sure I'm that qualified to answer such a question, yet. For us, developers, the coding is the fun part. The hard work is making money from it: marketing and sales. Do not, for one second, think that you can just write a plugin, list in on EPIC and the money will start pouring in. Either be prepared to do the marketing yourself or get somebody else to do it. I would suggest the Business of Software forum: a great place to start reading and ask questions on the subject. 

As for Eclipse plugins and software development tools: it is a very tough market. It is easy for a developer to get dragged into it, because we feel the pain and we are all bursting with awesome ideas. To demonstrate: name three large company focusing on software development tools. Not that simple. That's why it will be nearly impossible to raise money for such a startup (unless you have "cloud" in the title). Do not let it discourage you: we need more tools and we are very far from the optimal toolset. You just need to start in a different way. I really suggest the following presentation by DHH (from 37signals) for anybody thinking of doing this, there's a link and a short summary in the following blog post.

Understand the needs and benefits around implementing the right monitoring solution for a growing containerized market. Brought to you in partnership with AppDynamics.


Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}