IntelliJ IDEA interview transcript
By request, here's the transcript of my interview on the Java Posse podcast, about IntelliJ IDEA and the Java IDE market in general (Eclipse, NetBeans, etc.):
Java Posse: Hi, and this is Dick Wall, for the Javacast, interviewing Rob Harwood of JetBrains. Today we're going to be talking about IntelliJ IDEA, an alternative IDE to the big boys that are out there, in particular Eclipse and NetBeans, right now. Hello, Rob.
Rob Harwood: Hi there.
JP: Can you tell us a little bit about your background and experience? Are you, or have you been a developer, and what do you do at JetBrains?
RH: Yep. I've been a developer for six years. I had a computer science degree. Around three years ago, I was looking for a better Java IDE, because I was using -- I think it was -- JBuilder at the time, and I wasn't happy with it, and discovered IntelliJ IDEA by JetBrains, and I liked it so much I bought my own copy. Another thing that I should mention is that I was a fan of agile methodologies, and so when I saw IntelliJ IDEA, I was very impressed by it, and I wanted to find the company that made it and try to get a job with them. So that's what I did, and I joined JetBrains as a programmer. I did a little bit of work on IDEA itself, but I mostly did internal projects. And so, then I moved on -- just recently actually, I just moved on to what I would call technical marketing, which is I'm actually more of like an expert user, and I use that knowledge to help educate about IDEA.
JP: You sound like an American, but you're --
RH: No, I'm Canadian.
JP: Oh, Canadian, I apologize. But, you're living out in Prague right now, is that correct?
RH: That's right. Yeah.
JP: Okay, how do you like it out there?
RH: It's great, I like it here. It's a nice change from North America, I'll tell you that. It's a lot more relaxing out here, I would say.
JP: Yeah, I've heard that it's a very beautiful city, actually.
RH: It is, yeah.
JP: So, can you sum up IntelliJ IDEA? Tell us a little bit about what sets it apart from the competition, like Eclipse and NetBeans.
RH: Okay, well, it's a Java IDE. But I think I should give a little bit of history, to kind of set the stage, in case some of your listeners aren't familiar with it. So, around 2000 or 2001, Java IDEs were kind of standard, and Sergey Dmitriev, who is one of the three founders of the company, decided that he wasn't quite happy with the situation. He had previously worked at TogetherJ. And so he wanted to create a new IDE that had much better code search, code navigation, and also something called refactoring, which I hope most of your listeners know about. It's being able to modify code without changing its behaviour, to improve its design. So, in fact, Sergey and two other founders joined together and they finished writing this IDE, and it was the first IDE with the Extract Method refactoring, which is what Martin Fowler calls 'crossing the refactoring Rubicon'. So, it had a little gathering of, kind of, fans, I would say. And in fact it won a Jolt Award one year, and then the next year, I think, it won the Jolt Productivity Award. And so, based on this and its success, other IDEs started to add refactoring and all these other productivity features. So the thing that sets IDEA apart is that it's focused specifically on developer productivity. And I usually say that productivity is achieved, in this case, with intelligent features and usability. And the difference is that IDEs like NetBeans and Eclipse, they actually start out as application platforms, plug-in platforms, and the IDE is kind of like the showcase application for it. So they start out as platforms and build an IDE on top of that, whereas IDEA is the other way around. It starts with the IDE, a heavily integrated IDE, and it builds out modular parts of it as we find ways to do that. So, the motivation is different, and also the architecture is different. Eclipse and NetBeans start from the basis of modularity, and IDEA starts from the basis of integration and adds modularity as it's needed. For instance, for adding plugins for version control systems, and now we have a new Language API for adding support for different scripting languages, and that kind of thing. So we have a modular architecture, but it's not from the modular side. It's not starting from modularity.
JP: Okay. Do you think there are any other major strengths of IDEA worth mentioning at this point at well?
RH: Well, definitely. I haven't really gone into much detail yet. So, I would say the primary things are based around usability and intelligence -- and again this goes back to productivity. We add features when we see that it will add to developer productivity. So, good examples of that are: Code navigation, for navigating your Java classes and XML files, and all that; code assistance, like code completion and generating code like constructors and getters and setters, and things like that; also, especially refactoring, which IDEA has very complete refactoring. There is also a fairly new feature in the last couple of years, is static code analysis, primarily the code inspections and on-the-fly error highlighting, which is something that is not really well known yet, but I think in the coming year or two, people will start to see the advantages of this feature. And also IDEA is heavily integrated for J2EE and web applications, as well as other things, but I mean I could just go on forever, so I think I'll leave that.
JP: Right. What do you think, if anything, the weaknesses are in IDEA?
RH: Well, it depends on your perspective, so I'll pick a couple of perspectives. One is, let's say, performance. It's not a text editor. It's a full-blown IDE. So, in some ways we trade off performance for things like building caches of information so we can do intelligent code searches, and highlighting of errors and potential errors, and that kind of thing. So, in some ways we're trading off raw performance for usability and intelligence. But, on the other hand, we treat performance as a usability feature, so if performance is not good enough, we definitely address that. So what you end up with is a well-performant IDE, but it's not going to be able to handle huge files, like 5 megabyte files, or something like that. It's not a raw text editor.
JP: Okay.
RH: And also the other one that I should mention is extensibility. As I said, we start from integration and we build in modularity as we go along. So, IDEA doesn't have as many plugins as other IDEs, but it does have a lot of built-in features. The other thing is that, because we're building in modularity piece-by-piece as we go, I would have to admit that sometimes the documentation is not that great for the Open API that we have. It can be difficult for someone to get started. However, we're looking into that. We have someone dedicated to working on the documentation, and we have already built -- it's a plugin development kit to help you kick-start your plugin development for IDEA.
JP: Yeah, as a developer, I would say that the documentation is never good enough for anything.
RH: One more thing, just to be fair, I think I should mention, to compare to NetBeans and Eclipse, the two obvious ones are: It's not open source, and it's not free. That would be a weakness, but, you know, it's a trade-off, right?
JP: Right. I think we're going to hit that a little bit later in the interview a little more anyway. Okay, so heading back to the main topic here. I guess the big gorilla in Java IDE space right now has to be Eclipse. Many people seem to think NetBeans is the main competitor to that, albeit somewhat smaller in terms of market share, right now. Why do you think that is, and why do you think that IDEA is not a bigger force in the marketplace right now?
RH: Yeah. So, Eclipse is definitely the gorilla. And by gorilla I'm using the terms coming straight out of Geoffrey Moore's popular books Crossing the Chasm and Inside the Tornado. You can see this in pretty much any industry. You get kind of a breakdown of who's the big heavyweight, and who are the two or three competitors who are providing alternative choices. Usually, the main one is called the gorilla, which is the most popular, the default choice, the one that has the most support from the community. But there's always competitive choices, and these are actually called chimpanzees, in Geoffrey Moore's terminology, or chimps. So, I would have to say, we are the adaptable and intelligent chimp in competition with the 800 pound gorilla. And the reason for that is pretty much that we started out as -- it's like the two guys in the garage kind of story, except this time it was three people in Prague. We started out from pretty much nothing, and all of our marketing, up until recently, let's say, a year or two ago, has been through word of mouth. So, people telling other people that they like it, and get their friends on it, and show it to their friends, and that kind of thing. Whereas, something like Eclipse or NetBeans, which is backed by a large company, they have the capabilities to provide a lot of extra support like extra websites and marketing money and ads in various magazines, and whatever. So, that would be one of the main reasons. The other one obviously is cost. And the third one is obviously open source, the fact that NetBeans and Eclipse are open source. So they have the kind of default attraction to most programmers.
JP: Okay. I think one more possibility, certainly one that I hear spoken about a lot, is a lot of people like Eclipse because of SWT. Now, I'm not going to go into my own views on this particular one, but that does seem to be a draw to the Eclipse platform, is the SWT IDE construction toolkit. Does IDEA have any kind of SWT compatibility, and what do you think of SWT compared to Swing?
RH: Well, I gotta say, this is somewhat of a religious topic, and to be honest, I don't have a lot of experience in GUI development, so I won't really provide my opinion on SWT or Swing. What I can say is what I see from the marketplace. I see SWT as kind of like the C# versus Java. So C# made a big appearance, and had a lot of interesting features, and for a while it was a little bit embarrassing for Java. But the thing is, Java didn't really stand still. Sun updated it to cover the big differences. You know, it's like competition; when you have no competition, things kind of stagnate, right? So, C# is providing competition for Java, and in the same way, SWT is providing competition for Swing. And I think that -- Personally, I think that Swing is so deeply embedded all over the world, and in so many projects, and so deeply embedded in the core JDK that I don't see SWT as -- I think it's probably going to slow down in its popularity, and I think Sun will update Swing to compete more with SWT. For me personally, the advantages of SWT that are promoted, like for instance operating system fidelity, and speed, and all that kind of thing. For me, those aren't that important because it's possible to build good interfaces in both of them. And I think both NetBeans and also IntelliJ IDEA are good examples of that. They both have good interfaces, and, you know, I'm biased, but IntelliJ IDEA blew me away when I first saw it, and it's written entirely in Swing. So, for me the most important thing is usability. Can you build a usable interface with it? And the answer is yes to both of them. So, that's what I think, basically. In terms of IDEA's support for SWT, it's basically a class library, so you can definitely write SWT applications in it, but there's no specific support like a GUI builder or anything like that. We have a GUI builder, but it currently only works with Swing.
JP: Okay. Staying on the UI for a minute, the upcoming -- I don't know if you've seen this, but the upcoming NetBeans 4.2 has a UI builder in it called Matisse, and that's based on something called the Natural Layout Manager. Have you looked at these at all, and do you think that Natural Layout Manager support, similar to NetBeans will be included in a future release of IDEA?
RH: Yeah, in fact, I had heard about it, but I hadn't looked at it until you sent me the questions. So, I did, I looked at the demo. I didn't download it, I didn't try it myself, because again, I'm not really experienced enough to evaluate a GUI builder type of thing. But it appears to me that Matisse seems to be targeting ease of use compared to hand coding code. And I think that's a good idea, because the weakness of Swing, and probably even SWT, again I might not be accurate there but -- I'll just say with Swing then -- the weakness of Swing is that to get a decent UI requires a lot of work, you know, hand coding. That's why people use GUI builders, but the GUI builders recently have mostly been kind of just adjuncts to hand-coding, whereas Matisse seems to be targeting more like a quick, usable GUI builder, in comparison to say VB or some form builder from Microsoft. I think that's good, and I think it's needed. I was quite impressed by the demo. I would say that when we add support for third-party tools, we do it in a pragmatic manner. So, if there's a good use case for adding some feature to IDEA, we add it. And usually that means that there's some customers who are asking for it, and some special integration would significantly increase developer productivity. Also, the tool should be fairly stable, and kind of like a de facto standard, usually. So, if something, some tool, meets those criteria, we'll definitely add it to IDEA. If it doesn't, then we do have an Open API, and someone else, some third party, could add it as well, as a plugin. For example, IDEA comes with JUnit support, because JUnit is the de facto standard for unit testing. We don't have built-in TestNG support, but a few IntelliJ community members, Mark Derricutt and Hani Suleiman, they wrote a plugin for TestNG, which is a competing unit testing framework. Also, IDEA comes with Ant, because that's the de facto standard build tool, but say Maven requires third-party plugins. So, basically what I'm saying is, if there's sufficient support for Matisse from the community and it's a solid tool, et cetera -- I think right now it's a pretty early tool. So, I can't see in the short term that we'll be directly adding support for it. But, you know in the long term, we might. Also, we do have our own GUI builder, and we'll probably be taking 'lessons learned' from Matisse and applying it to our own GUI builder, as well. But I mean, there's nothing stopping us from adding support for Matisse, whether or not that is just the Natural Layout, or whether it's the actual GUI tool itself, it's hard to say.
JP: Okay. As listeners will know, we've had -- in the course of the previous Javacast episodes, we've had some pretty extensive discussions on component-based development versus, I guess, traditional, more editing-based development. I just wondered what yours and JetBrains' stance on the component based development model is. And is it a focus in IDEA? Is it likely to become a focus in IDEA?
RH: I think when I originally heard the Javacast that I had responded to, I was probably a little bit confused about what you meant by component-based development and I think I took the wrong interpretation. What I think, actually, is that, when Brandon says 'component-based development', I think he means a couple of things. I think he means -- there's basically three things. One is pluggability. What's a component? It's almost like a plugin, right? The other one is kind of like the wizard-like functionality or the usability -- you know, providing a tool to help you get past the set-up configuration. The other one is kind of like the big tool that does it all for you. For instance, Sun Java Creator Studio, which is a tool for getting beginners, and experienced folks as well, but basically to provide all this support for you. So, in terms of that, I'll answer three different questions. What is IDEA's focus on all three of those situations? So, again, it comes back to the pluggability, where, yes, we do have an Open API, but that's not our number one priority. Our number one priority is being the best tool for Java and J2EE development. And in that sense, we are not really component-based, and that's what I originally had thought Brandon meant when he was talking about that.
JP: Right.
RH: But, in terms of the other two, which is the usability, you know, being able to click Next, Next, Next, like Brandon was talking about. That is basically a major feature of IDEA, being able to quickly and easily do things like creating a new class, or you know, just anything. We try to build in as much usability as possible in our tool. However it is more for like hand coding, right? So, in terms of the big tool that does everything for you, that's not what IDEA is about. So, our wizards -- I think we only have one or two. We have a project creation wizard, and I think there's another one, but I can't think of what it is. So, we don't really have wizards so much as like dialog panels that help you quickly do something, and it's all keyboard supported, so you quickly do something like extracting a method, or adding a parameter to the method, or something like that. So, in terms of the big tool, that does everything for you, IDEA's not going to become that. But we do have another product called Fabrique, which we're working on, and it's idea is similar to the Sun Java Creator Studio for helping to make web application development easier to do by using a tool, as opposed to something like a framework like Rails or Struts, or something like that, which is supposed to help you in terms of productivity by providing tools for hand-coders. But this one is more for quickly developing using a GUI tool to help you do websites.
JP: Okay. Alright, let's move into some of the more fun stuff, architecture in particular. IDEA has strong support for J2EE and EJBs. Can you talk a little bit about that?
RH: So, in fact, IDEA 4, I believe it was 4, started to introduce support for J2EE, and IDEA 5 has really made that its major focus -- this is the latest version of IDEA. First of all, in IDEA 4, we had EJB configuration tools to help you with that. There was support for some refactoring, for renaming things. There was some support for JSP, and HTML and XML, but it wasn't quite integrated. So what we did was -- IDEA 5 has a lot more support, especially on the web development side, especially with JSPs and embedded CSS and JavaScript and HTML and the JSP 2 expression language. What we did to do that is we introduced a Language API, which allows anyone to develop plugins for any language, and you can add support for some refactoring, code navigation, finding usages, and highlighting usages, and syntax highlighting, and all sorts of stuff -- and inspections, and that kind of thing. We did that, that was a major undertaking for IDEA 5, and that will be the foundation for our future J2EE development support. We also have support for WebLogic and Tomcat integration built-in, and there are others available, and you can add support for any generic web app server. I think there's some JSR to cover the compatibility there, and we follow that spec. And I think that's about it.
JP: Great. What do you have now, and what do you have planned for EJB 3.0, the upcoming EJB spec, in IDEA?
RH: Well, we haven't decided yet. A lot of our developers are on vacation right now. But we will definitely support the EJB 3 spec. And the question is really, what exactly, how exactly we'll support it. I would have to say, or guess, that it will include some EJB-aware refactorings and navigation and configuration, helping you with the different annotation, and providing inspections about the proper usage of EJBs, and that kind of thing. So, this is a work in progress, and I don't know, is the spec even finished yet? I'm not aware of that.
JP: It's getting pretty close. It's in the final draft stages and stuff like that. JBoss and Oracle both have preview editions out there to mess with right now, but it's not finished yet.
RH: Well, when it solidifies, we'll definitely look into how we can support that. It will definitely be part of IDEA.
JP: We also had Bruce Tate on for a really fun interview in the last episode, and he was pushing alternate simplified frameworks like Spring and Hibernate, in that. I wonder, does IDEA have any support for that? Are there any plugins that allow you to do Spring and Hibernate and alternative frameworks in IDEA?
RH: This has currently not been a primary focus of IDEA. We do have some small support for Spring, which I can't recall exactly what it is, but we do have some small support for Spring. I think it's some sort of reference linking, being able to navigate, or something. I'm not sure exactly. But there are third-party plugins. All of them are free, that I can think of. For instance, there's Live Templates for Hibernate, for writing your XDoclet tags. There's a couple of plugins for Spring. One is Spring Console, which I think works in any IDE. The other one is called IdeaSpring, which can be downloaded directly from IDEA's plugin manager, and that offers some features like configuration and navigation like jumping to declarations and for ref and alias tags, and that kind of thing, and auto-scroll from source. And that's being developed, also I think that's from someone in our IntelliJ community, has developed that.
JP: Great. Actually Bruce spoke very highly of IDEA. That's his IDE of choice. I just thought I'd throw that in. We had a brief conversation prior to the interview about that, and he really likes what you guys are doing.
RH: Oh, I should mention that I met Bruce Tate at JavaOne 2004. He was there, he had his book, Better Faster Lighter Java, and he signed a copy for me. So that was fun.
JP: Oh great. He's a nice guy, great guy to talk to actually.
RH: Yeah, he's great.
JP: Okay, so you've mentioned a couple of times that IDEA does refactoring very well. Can you give a couple of brief examples of refactorings that are possible in IDEA, but not in other IDEs like Eclipse.
RH: Okay. It's kind of a case of, you know, if you compare feature by feature, then in most cases, Eclipse has many of the features IDEA has. But that's not what keeps people coming back to IDEA. It's not a feature list thing. I really believe that it's not so much about feature lists anymore. It's more about usability, and productivity. There are a couple IDEA-only refactorings, but I'll just briefly mention them, because I don't think that's the key to understanding what IDEA's about. So a couple are: Change Class Signature, if you have a generic class and you want to change the type parameters, the order of the parameters, or how many there are, et cetera. There's Safe Delete, which is being able to delete any class or any file you want to delete, without -- it checks first if there's references. There's being able to Replace Method Code Duplicates, so if there's a method existing in your class, and then many parts of the class also duplicate the functionality of that method, you just call this refactoring and it will replace all of those parts with a call to the method instead. There's Extract Superclass, which allows you to create a class in between two classes in a hierarchy very quickly. But I think that's not really the important difference here. The difference that I think is most important is how usable and how productive are these refactorings. So, the major differences there that I see is in, say, Eclipse, that if you have errors in your code, let's say you have a minor syntax error in some method, you can't rename that method. If you have a missing semicolon or something. You have to fix all the errors and then you can do your refactoring. For me, that is a major difference. You really have to try it to see what I mean, because if I just talk to you about it, it doesn't seem to sound very important, but so many times I've tried to use Eclipse, and I just get completely frustrated when there's some minor error somewhere, that I forgot to finish typing a name, but I want to extract some variable or method or something, and it won't let me do it. It says you have to fix the errors first. It completely gets me out of my flow, and I have to think in a different context, I have to switch contexts. Also, Eclipse is a little bit more unsafe than IDEA. For instance, you can't always undo refactorings, and when you can, sometimes it requires you to undo in every file the refactoring that was effected. Often times, you need to manually fix code after refactoring in Eclipse. We have some examples of that, but I can't think of them off the top of my head. We have more mature refactorings, like for instance Move Method. Move Method will handle cases such as inner classes in IDEA, where that is not handled properly in Eclipse.
JP: Okay.
RH: So, basically what I'm saying is that, it's not a matter of, you know, checking off, feature by feature and saying "Oh, this feature list is longer than that one," because that's not what's really important. What's important is, when you're developing in your day-to-day, you know, everyday programming time, that you want it to be as productive as possible. You don't want to be wasting time trying to fix the IDE's problems. The IDE should be fixing your problems. So, what else is there? Yeah, there's some other minor differences, but really it's the productivity that I think should be emphasized.
JP: Okay. I think that probably covers the majority of the next question I had, which was the question about the difference between -- or the benefits of static code analysis versus the automatic compilation on save that Eclipse has, and I think that probably rounds that off, unless you've got anything you want to add to that.
RH: Actually, I don't think it covers it at all, really.
JP: Oh, okay.
RH: This is one of these, kind of -- what do you call it? Like a 'diamond in the rough' feature. Unless you've seen it, it's really hard to explain what's going on. But I'll try to explain as best as I can. So, IDEA has 500 static code analysis, let's call them modules, or features. So, compiler errors are one thing. Eclipse, when you save, it automatically compiles, it lists certain errors. Most of those are compiler errors. Eclipse has about 30 other errors that it will -- not necessarily errors, but problems, that it will show up. But IDEA has 500, and these cover such a wide range of topics. It's not just possible errors, but it's things like internationalization issues, JUnit issues, J2ME issues, performance issues, serialization, threading, all sorts of stuff. And on top of that, it has some really great stuff, like there's a new inspection for highlighting in your code possible NullPointerErrors. We use a special annotation for that, for Java 5. It does things like code style issues. So it helps you highlight instantly in your code if you're violating some naming convention. Or say you're in one package, and you accidentally use a class in another package, and your project design has been set up by your team in such a way that you're not supposed access that package from the other package. That's a package dependency violation. So we have an inspection that will highlight that automatically. You just configure the package dependency rules that you want to set, and it will highlight that. Also it will show you a lot of redundant code things, like redundant if statements. This loop doesn't do anything, or redundant assignments of variables. So if you say like, a = a;, which sometimes happens when you intended to assign a field the value of some parameter, and you say 'field a equals a', but you forgot to put this.a, so it'll highlight that problem. And there's so many others, that it's just really -- this is one of the killer features of IDEA, and you really have to try it and see it to understand how it helps. What the basic benefits of this is that it drastically reduces common errors. It won't find major design errors, but it will find some design errors, like I said with the dependency violations, but also some class abstraction issues, or if you have encapsulation problems, like if you're exposing too many fields or something like that. It also helps you with things like migrating to Java 5. For instance it'll highlight for loops that are using the old style for loop and show you that you can replace this for loop with the new type of for loop. And in fact you can do it just by hitting one key and pressing Enter and it will automatically replace it for you. So a lot of these inspections are also attached with what's called a Quick Fix, which is different than the Eclipse Quick Fix. First of all it highlights in your code, and the Quick Fix will let you quickly apply whatever solution is suggested. First of all you reduce common errors, second you help improve your design, and the great thing about this is you do it as you go. So, you're working on your class, and you see all these things highlighted, you just clean up as you go. It's kind of like refactoring as you go. It's just something you should do as a continuous process. So, instead of waiting once a week and having a code review, you can have an 80% code review all the time, and then once a week you can have a code review to cover the rest of the 20% that automated code inspections can't handle. So, it saves you time, saves your time in code reviews, saves you time dealing with errors. I would say this is IDEA's killer feature, at this point.
JP: Okay. I have seen some capabilities from PMD analysis plugins available for other IDEs, but I do think, from the sound of the description you just gave, it does go a fair bit further than those. That's good.
RH: Yeah. The difference is, PMD does have more checks than Eclipse, but IDEA's is more complete, and PMD I don't believe it has quick fixes. It certainly doesn't have as many as IDEA's has. And IDEA's, it's all built into the editor, so these things work with all sorts of various things that PMD only, I think, only works on Java classes. For instance, IDEA's works in HTML files, and JSPs. You get all your same inspections in all your JSPs, if you have any scriptlet code in there. Also, it has CSS inspections. I could go on and on.
JP: Okay. Now we're going to move into the section of the interview where I've written some questions down that I kind of want to get some answers to as well.
RH: Sure.
JP: These will be a little more off the wall. But first of all, a particular interest of mine right now is scripting languages for the JVM. This is something I've found to be really very productive in recent projects. Particularly, Groovy is one that I've latched onto for its excellent XML and SQL support. I know there's a Groovy plugin for IDEA, because I was looking around recently to see what kind of capabilities it had, but at the moment it seems like it's limited mainly to syntax colouring and basically invoking the Groovy compiler. Are there any plans, do you know, to beef up scripting support for Groovy or other scripting languages? In particular, one of the things that I'm still waiting for from any IDE is a really good debugging solution for Groovy. So, any plans to do anything like that?
RH: Yeah. Our current plans are to support JavaScript as much as possible. And we provide this Language API, as I mentioned before, to allow other people to write plugins for other languages, and someone in our community has written the GroovyJ plugin, and it's more than just highlighting. I believe it also has code completion, and brace highlighting, and navigating between references, and this kind of thing.
JP: Oh, it may have moved on a little bit, since last I last looked at it. That's great.
RH: I think it has. It's using quite a lot of the Language API. And we're going to open up more of the Language API as we go, as we're able to make it more modular. Definitely, Groovy is going to be a big upcoming -- it's kind of like the competitor to Ruby on the Java side. So I think it's going to become pretty popular, and this will definitely be a major thing that we'll support. Basically, we'll be looking for people to write language plugins and have them give us feedback and tell us what problems they're having with the Language API, and what capabilities they need, and this kind of thing. So, we'll be developing the Open API, and other people will be using it. And we'll be using JavaScript as our internal test case for that. So, in terms of Groovy itself, as far as I understand it, Groovy classes are transformed into Java classes.
JP: Basically, the thing that really attracts me about Groovy is you can take virtually unmodified Java code and execute it under Groovy. But then you can start dropping out a lot of the type safety and using more of the dynamicism and stuff like that. But it also compiles up to Java classes. That, coupled with the good XML and SQL, are kind of the reasons I really like that particular scripting language right now.
RH: Right. So, in terms of that, I think there's the possibility -- and I was talking to Eugene Zhuravlev, who is one of our main developers, and he was telling me -- that if Groovy can generate debug info that meets the JSR 45 specification, then we can definitely add debug support to it. Now, it might not be possible right away in version 5, but we'll be definitely looking into this. It's something pretty important, I think, to this kind of support for these languages. So, you'd be able to set breakpoints and step over Groovy code, just like you would in JSP, for instance. We're definitely looking into that -- other languages. We're also looking into supporting XML-specific languages. There are so many different dialects of XML. I don't know if we've planned this specifically, but we're thinking of planning support specifically for XML languages to make it easier to create your own XML languages and provide IDE support: Refactoring, navigation, highlighting, and all that stuff, code folding, everything --
JP: Great.
RH: Reformatting. Other language that are possible are Python, Ruby. Regular expressions, I think we already have a plugin for that. XPath, we already have a plugin for that. And your own custom languages.
JP: Excellent. I look forward to that, seeing what happens there. Okay, we're going to get into an area where I've gotten myself into a little bit of trouble recently -- not just with you, a number of people have emailed me on this one. As a hobbyist developer, I work on the occasional small side project, and generally whatever I create -- saying I release it under the GPL is probably a bit grandiose, I usually push it out, let's see if anybody's interested, and it's GPL'd. It doesn't usually release as much as whimper and die. Anyway, given that, what options are open to me for using IDEA? Could I use the non-commercial license, and what would I have to do in order to use it?
RH: Okay. We do have an open source license, and there are some restrictions on it. First of all it has to be non-commercial open source, meaning it's not for profit, and also it has to meet the open source definition, it has to have a dedicated website, and an active community. As a hobbyist, it's not likely you're going to have a dedicated community if you just start right away.
JP: Right.
RH: It's not as broad as it could be, but it is available. I think at least 60% of the Apache -- is it Apache projects? I'm pretty sure. You can check our website. We have a page dedicated to that. Approximately 60% of the Apache projects using Java are using this open source license. And hundreds of other projects as well. And it's easy to apply, you just go to the website, you provide some information, and you get a one year renewable license for all the members of your project. But in terms of a hobbyist, we currently do not have a simple non-commercial license yet. I have considered that, and I'm kind of torn between the two possibilities as to whether or not it would be a good idea for our company in the long run to have a cheap, or a free. non-commercial license for everybody. But anyway, we're looking into that. In fact, I just read the other day an editorial by Rick Ross from Javalobby, who talks pretty closely about this subject. It was interesting to read his opinion, which was basically that it would be bad to do that, but I don't know, I'm torn. In my opinion, it could be a good idea, but we have to look into that.
JP: Okay. So basically the other option here is to actually -- for my hobbies, is to stump up the full price of $500. Given that, let's say I've got $500 and strictly this is, you know, for my own use, it's for messing around within my spare time. I have the choice of buying some hardware -- I actually went through this recently. Both my AMD 64 bare-bones kit and the Mac Mini I purchased recently came to about that amount. Can you make a case for me buying IDEA instead of one of those? Can you lay it out for me?
RH: Okay. So, in my personal opinion, that's really not an issue. $500? Yeah, it's a lot of money, but I mean, I enjoy programming and I want to use the best tools possible. So, in my personal opinion -- in fact, I did this when I was working at my previous company, I bought a copy of IDEA because my boss wouldn't buy it. I bought it with my own money, and I used it because I didn't want to use the other tools that were out there at the time. So finally my boss comes along and says, "You're using this? Isn't your evaluation expired?" I said, "No, I bought my own copy." And he's like, "Oh really? It's that good?" And I said, "Yeah, it's really that good." And so, he ended up pitching for licenses for the rest of the team. But anyway, that's my own personal experience. In terms of the general population, I would say that -- well, first of all there's one thing I should mention. It's not always $500, because we do occasionally, I think twice a year, we have a promotion for a Personal License, basically exactly what you're talking about, for half the price, so it's about $250, which, I don't know, that's really not a lot of money. And anyway, even if that is a lot of money for you, you can think of this analogy, which I mentioned to you in the email before. If you're a hobby bicyclist, and you decide -- you have a choice, you can ride in the city on a simple, cheap city bike, or you ride rough and fast on a mountain bike in the wilderness. You have a choice, what do you want to do? Some people are content riding in the city. They don't have a need to go on rough and fast terrain, right? So, that's an option, you can go for that. But, you know, you shouldn't expect -- just because there are city bikes that are out there that are cheap, or even used, you shouldn't expect bike makers, who make high-performance mountain bikes to make them cheap, just because there's cheap competition out there. What I would say is that, you have an option with IDEA. You have an option to try it for 30 days, see if you like it. And if you don't like it, you don't have to buy it. Or if you don't have the money, you don't have to buy it. It's kind of like, if you're happy with your city bike, and somebody says, "Here, you can try this mountain bike for 30 days for free. You don't have to buy it." Now the choice is, are you going to take that offer, or turn it down just because it has a price tag on it if you decide to buy. Personally, it would be a no-brainer for me. I would try it, because I like riding bikes -- or I like programming, and I want to see what the best tools out there are. Even if it's just to do some research for my professional job. I want to at least know what's out there. I try NetBeans, I try Eclipse, I try JBuilder, I try the other IDEs, and then from that knowledge I can pick the one that I like the best, and the one that suits me the best. So, that's how I would council people who are deciding. Try the IDEs, you can try them all free, and pick the one that you like the best. The other thing is that it's kind of like buying a Mac versus buying a Windows PC. People pay a little bit of extra money for a Mac. Why do they do that? It's because they enjoy using it. Even if you are just buying it for your own personal use, a lot of people they choose to buy a Mac because they prefer it. That's my opinion. I think that usability is a feature worth paying for, even if it's only for your own personal use. This is not a $5000 thing, it's not a $10,000 thing. It's only $500 and if you catch the yearly specials then you can get it for cheap for $250. And the last thing I'd like to say about this is that I think the reason I enjoy programming is because of something called flow, the mental state called flow. Your listeners can look it up on the C2 wiki, that's the original WikiWiki. It talks about this mental state you get in when you're highly focused, and even athletes have a thing called 'in the zone', which is very similar. You know, when you're deep in a problem in programming, and you're just chugging along, and you're just churning out code. It really is an enjoyable experience, and I think that's worth a little bit of my money to get that. And this is one of the things that IDEA focuses on, making programming so fluid and productive that you can get in flow, and you can stay in flow. It doesn't get in your way. It provides simple features that you can use at your whim. It gives you more control over the code. The more control you have, the more you can get into flow. It's like a programmer high. It's like a drug, in a way. It think this is why we have such loyal fans, because this is what it focuses on. It doesn't focus on being some platform for everything but nothing in particular, it focuses on being a Java IDE so you can get right in there and do your coding.
JP: I would just very gently offer a slight counterpoint on this one, my own personal feelings on it. Being the kind of developer that I am within the company I am, I always have a list of things as long as my arm that I've got to sit down and research at some point. And just knowing that if I do decide to use it, I am going to have to pay this fee, it just shuffles it down the list there a bit. I'm constantly searching for more time to learn new frameworks and new things that can help my job. This is one of those, it's not the only one. It just kind of shuffles it down the list. I think for me, something for personal use, and I am talking about personal non-commercial use -- I don't think $500 is out of line at all for anything that is corporate-used. In fact most frameworks, or most tools, cost a lot more than that. But for personal use, I've probably got a cut-off of about $100 maximum. I kind of look for the $50 to $100 -- it doesn't matter if it lacks things like full team capabilities, or stuff like that, for personal use. It's just I want to be able to get into it at a slightly more comfortable level. Personally, I find $500, I can get some pretty good hardware with that. Maybe it's just me, but I don't think I'm the only one out there. That's what I guess I'm trying to get across there.
RH: No, I agree. For some people it's not worth it, because that's their own personal feelings about it. And the only thing that I would say is, make that an informed decision. Try it, because it's free to try it. And while you're trying it, there's no obligations. There's nothing stopping you from trying it.
JP: Okay. Moving on, is there any kind of direct customer, or potential customer, feedback or forum, where developers can come and talk to you about what's available and maybe ask for stuff that they'd like to see in IDEA?
RH: Yeah there is, and in fact this is actually one of the big things that makes IDEA what it is today. We have a fairly large community. It's not as big as Eclipse, or -- I'm not sure about the NetBeans size -- but it's a fairly large community, it's customers, people who are just trying IDEA. And we have two websites. One is called intellij.net, and the other one is intellij.org. I would suggest, if anyone is interested, to go to intellij.net first. There's also, of course, for our customers we have full support. We have a dedicated support page for that, and a dedicated team for that. But the community is really the big factor here, that I would like to talk about. We have an interesting development process. Remember I mentioned I was a fan of -- I still am a fan of agile methodologies, like Scrum and Extreme Programming, and you know, I wanted to know how does this company develop this product, because it was developing features really super-fast, and they were good features, and it was very impressive. And I think to a large extent we are able to maintain that kind of turnaround. So I wanted to know, how does this company develop its software. So that's one of the reasons I joined the company. As it turns out, the method we use is called the Early Access Program, and we have a dedicated website for that, it's under the intellij.net website. We have forums and newsgroups that go along with this. Anyway, the Early Access Program -- basically what you do is, as we're developing the next version, you can get free licenses. Anyone can get a free license, as we're developing the next version. There's no strings attached. We do ask that you try to submit bugs and everything. We do tell you that it's not going to be perfect. It's not going to be fast, because we sacrifice performance while we're developing new features; we tune up the performance near the end. But what we end up with is a large community of people who are trying IDEA everyday, trying the new versions, and submitting reports, not just bug reports but feature requests, and we listen to them. So, if there's enough support for a feature request, we'll put it in. And in fact, a lot of the time it can happen very quickly, within a couple of weeks sometimes -- or within a few days sometimes. So, this is a very important -- I can't stress it enough -- it's a very important factor in why IDEA is what it is today, because we have a lot of people who use it all the time, and are really testing it, pounding it, trying it, and giving us feedback. And the important thing is that we listen to the feedback, and we make the changes, and post new builds every week or two, or sometimes every few days depending on the situation. So, yeah, we do have ways that you can get in touch with other people who are using IDEA, ask questions, get support. I would say go to the website and you can find it from there, jetbrains.com or intellij.net.
JP: Great. Thank you. Okay, well that's really the end of the questions I've got. Is there anything else you want to talk about, concerning anything, Java development in general, or IDEA, or anything like that?
RH: Yeah. This is a thread that's been going through my mind for quite a while. I listened to Bruce Tate's interview and, you know, he's talking about 'beyond Java', what's coming up. His attitude is that you shouldn't settle for the status quo. Just because the J2EE and EJB is "the way you should do it" doesn't mean that's the way you should do it. You should look for other alternatives out there. So, there's a lot of really interesting, exciting stuff coming up. Not just in the Java space, but in the entire development space. Things like Ruby on Rails, Groovy, even C# and .Net. There's so many new things that are coming up. We're working on something called Language Oriented Programming; I won't go into that, but it's an interesting thing. So, I'd just like to say that I think that people should not settle for the status quo. Raise your expectations. See what's out there. Just because you're doing something a particular way right now, you know, there might be a better way of doing it. So, you know, go out and look for alternatives. You might be pleasantly surprised.
JP: Actually, one more question has occurred to me here. I thought about writing this one down, never put it in there. I noticed that both you guys and the NetBeans team are based in Prague. It just seems an unusual coincidence, that. Do you guys have food fights and lob things at one another, or is there any kind of story behind that, or is it just coincidence?
RH: Hmm, I'm trying to think of the history now. I believe it's a coincidence, because Sergey Dmitriev was in Prague, he was working for TogetherJ, and he split off and started JetBrains, or IntelliJ at the time. And I think the NetBeans guys were independent. And the funny thing is -- oh no, I'm sorry, I'm thinking of something else. Yeah, the NetBeans guys are independent, and I'm not sure how their history -- like how they started and everything, but apparently some guy started it, and Sun picked it up. It's just independent.
JP: Okay.
RH: But, you know what, I've never met any of them. In fact, most of our development goes on in St. Petersburg now. It started here, but most of the development is in St. Petersburg, Russia.
JP: Okay. Well, thank you very much, Rob. That was an excellent interview, and hopefully it will be up fairly shortly, certainly in the next week.
RH: Thanks a lot, Dick.
Java Posse: Hi, and this is Dick Wall, for the Javacast, interviewing Rob Harwood of JetBrains. Today we're going to be talking about IntelliJ IDEA, an alternative IDE to the big boys that are out there, in particular Eclipse and NetBeans, right now. Hello, Rob.
Rob Harwood: Hi there.
JP: Can you tell us a little bit about your background and experience? Are you, or have you been a developer, and what do you do at JetBrains?
RH: Yep. I've been a developer for six years. I had a computer science degree. Around three years ago, I was looking for a better Java IDE, because I was using -- I think it was -- JBuilder at the time, and I wasn't happy with it, and discovered IntelliJ IDEA by JetBrains, and I liked it so much I bought my own copy. Another thing that I should mention is that I was a fan of agile methodologies, and so when I saw IntelliJ IDEA, I was very impressed by it, and I wanted to find the company that made it and try to get a job with them. So that's what I did, and I joined JetBrains as a programmer. I did a little bit of work on IDEA itself, but I mostly did internal projects. And so, then I moved on -- just recently actually, I just moved on to what I would call technical marketing, which is I'm actually more of like an expert user, and I use that knowledge to help educate about IDEA.
JP: You sound like an American, but you're --
RH: No, I'm Canadian.
JP: Oh, Canadian, I apologize. But, you're living out in Prague right now, is that correct?
RH: That's right. Yeah.
JP: Okay, how do you like it out there?
RH: It's great, I like it here. It's a nice change from North America, I'll tell you that. It's a lot more relaxing out here, I would say.
JP: Yeah, I've heard that it's a very beautiful city, actually.
RH: It is, yeah.
JP: So, can you sum up IntelliJ IDEA? Tell us a little bit about what sets it apart from the competition, like Eclipse and NetBeans.
RH: Okay, well, it's a Java IDE. But I think I should give a little bit of history, to kind of set the stage, in case some of your listeners aren't familiar with it. So, around 2000 or 2001, Java IDEs were kind of standard, and Sergey Dmitriev, who is one of the three founders of the company, decided that he wasn't quite happy with the situation. He had previously worked at TogetherJ. And so he wanted to create a new IDE that had much better code search, code navigation, and also something called refactoring, which I hope most of your listeners know about. It's being able to modify code without changing its behaviour, to improve its design. So, in fact, Sergey and two other founders joined together and they finished writing this IDE, and it was the first IDE with the Extract Method refactoring, which is what Martin Fowler calls 'crossing the refactoring Rubicon'. So, it had a little gathering of, kind of, fans, I would say. And in fact it won a Jolt Award one year, and then the next year, I think, it won the Jolt Productivity Award. And so, based on this and its success, other IDEs started to add refactoring and all these other productivity features. So the thing that sets IDEA apart is that it's focused specifically on developer productivity. And I usually say that productivity is achieved, in this case, with intelligent features and usability. And the difference is that IDEs like NetBeans and Eclipse, they actually start out as application platforms, plug-in platforms, and the IDE is kind of like the showcase application for it. So they start out as platforms and build an IDE on top of that, whereas IDEA is the other way around. It starts with the IDE, a heavily integrated IDE, and it builds out modular parts of it as we find ways to do that. So, the motivation is different, and also the architecture is different. Eclipse and NetBeans start from the basis of modularity, and IDEA starts from the basis of integration and adds modularity as it's needed. For instance, for adding plugins for version control systems, and now we have a new Language API for adding support for different scripting languages, and that kind of thing. So we have a modular architecture, but it's not from the modular side. It's not starting from modularity.
JP: Okay. Do you think there are any other major strengths of IDEA worth mentioning at this point at well?
RH: Well, definitely. I haven't really gone into much detail yet. So, I would say the primary things are based around usability and intelligence -- and again this goes back to productivity. We add features when we see that it will add to developer productivity. So, good examples of that are: Code navigation, for navigating your Java classes and XML files, and all that; code assistance, like code completion and generating code like constructors and getters and setters, and things like that; also, especially refactoring, which IDEA has very complete refactoring. There is also a fairly new feature in the last couple of years, is static code analysis, primarily the code inspections and on-the-fly error highlighting, which is something that is not really well known yet, but I think in the coming year or two, people will start to see the advantages of this feature. And also IDEA is heavily integrated for J2EE and web applications, as well as other things, but I mean I could just go on forever, so I think I'll leave that.
JP: Right. What do you think, if anything, the weaknesses are in IDEA?
RH: Well, it depends on your perspective, so I'll pick a couple of perspectives. One is, let's say, performance. It's not a text editor. It's a full-blown IDE. So, in some ways we trade off performance for things like building caches of information so we can do intelligent code searches, and highlighting of errors and potential errors, and that kind of thing. So, in some ways we're trading off raw performance for usability and intelligence. But, on the other hand, we treat performance as a usability feature, so if performance is not good enough, we definitely address that. So what you end up with is a well-performant IDE, but it's not going to be able to handle huge files, like 5 megabyte files, or something like that. It's not a raw text editor.
JP: Okay.
RH: And also the other one that I should mention is extensibility. As I said, we start from integration and we build in modularity as we go along. So, IDEA doesn't have as many plugins as other IDEs, but it does have a lot of built-in features. The other thing is that, because we're building in modularity piece-by-piece as we go, I would have to admit that sometimes the documentation is not that great for the Open API that we have. It can be difficult for someone to get started. However, we're looking into that. We have someone dedicated to working on the documentation, and we have already built -- it's a plugin development kit to help you kick-start your plugin development for IDEA.
JP: Yeah, as a developer, I would say that the documentation is never good enough for anything.
RH: One more thing, just to be fair, I think I should mention, to compare to NetBeans and Eclipse, the two obvious ones are: It's not open source, and it's not free. That would be a weakness, but, you know, it's a trade-off, right?
JP: Right. I think we're going to hit that a little bit later in the interview a little more anyway. Okay, so heading back to the main topic here. I guess the big gorilla in Java IDE space right now has to be Eclipse. Many people seem to think NetBeans is the main competitor to that, albeit somewhat smaller in terms of market share, right now. Why do you think that is, and why do you think that IDEA is not a bigger force in the marketplace right now?
RH: Yeah. So, Eclipse is definitely the gorilla. And by gorilla I'm using the terms coming straight out of Geoffrey Moore's popular books Crossing the Chasm and Inside the Tornado. You can see this in pretty much any industry. You get kind of a breakdown of who's the big heavyweight, and who are the two or three competitors who are providing alternative choices. Usually, the main one is called the gorilla, which is the most popular, the default choice, the one that has the most support from the community. But there's always competitive choices, and these are actually called chimpanzees, in Geoffrey Moore's terminology, or chimps. So, I would have to say, we are the adaptable and intelligent chimp in competition with the 800 pound gorilla. And the reason for that is pretty much that we started out as -- it's like the two guys in the garage kind of story, except this time it was three people in Prague. We started out from pretty much nothing, and all of our marketing, up until recently, let's say, a year or two ago, has been through word of mouth. So, people telling other people that they like it, and get their friends on it, and show it to their friends, and that kind of thing. Whereas, something like Eclipse or NetBeans, which is backed by a large company, they have the capabilities to provide a lot of extra support like extra websites and marketing money and ads in various magazines, and whatever. So, that would be one of the main reasons. The other one obviously is cost. And the third one is obviously open source, the fact that NetBeans and Eclipse are open source. So they have the kind of default attraction to most programmers.
JP: Okay. I think one more possibility, certainly one that I hear spoken about a lot, is a lot of people like Eclipse because of SWT. Now, I'm not going to go into my own views on this particular one, but that does seem to be a draw to the Eclipse platform, is the SWT IDE construction toolkit. Does IDEA have any kind of SWT compatibility, and what do you think of SWT compared to Swing?
RH: Well, I gotta say, this is somewhat of a religious topic, and to be honest, I don't have a lot of experience in GUI development, so I won't really provide my opinion on SWT or Swing. What I can say is what I see from the marketplace. I see SWT as kind of like the C# versus Java. So C# made a big appearance, and had a lot of interesting features, and for a while it was a little bit embarrassing for Java. But the thing is, Java didn't really stand still. Sun updated it to cover the big differences. You know, it's like competition; when you have no competition, things kind of stagnate, right? So, C# is providing competition for Java, and in the same way, SWT is providing competition for Swing. And I think that -- Personally, I think that Swing is so deeply embedded all over the world, and in so many projects, and so deeply embedded in the core JDK that I don't see SWT as -- I think it's probably going to slow down in its popularity, and I think Sun will update Swing to compete more with SWT. For me personally, the advantages of SWT that are promoted, like for instance operating system fidelity, and speed, and all that kind of thing. For me, those aren't that important because it's possible to build good interfaces in both of them. And I think both NetBeans and also IntelliJ IDEA are good examples of that. They both have good interfaces, and, you know, I'm biased, but IntelliJ IDEA blew me away when I first saw it, and it's written entirely in Swing. So, for me the most important thing is usability. Can you build a usable interface with it? And the answer is yes to both of them. So, that's what I think, basically. In terms of IDEA's support for SWT, it's basically a class library, so you can definitely write SWT applications in it, but there's no specific support like a GUI builder or anything like that. We have a GUI builder, but it currently only works with Swing.
JP: Okay. Staying on the UI for a minute, the upcoming -- I don't know if you've seen this, but the upcoming NetBeans 4.2 has a UI builder in it called Matisse, and that's based on something called the Natural Layout Manager. Have you looked at these at all, and do you think that Natural Layout Manager support, similar to NetBeans will be included in a future release of IDEA?
RH: Yeah, in fact, I had heard about it, but I hadn't looked at it until you sent me the questions. So, I did, I looked at the demo. I didn't download it, I didn't try it myself, because again, I'm not really experienced enough to evaluate a GUI builder type of thing. But it appears to me that Matisse seems to be targeting ease of use compared to hand coding code. And I think that's a good idea, because the weakness of Swing, and probably even SWT, again I might not be accurate there but -- I'll just say with Swing then -- the weakness of Swing is that to get a decent UI requires a lot of work, you know, hand coding. That's why people use GUI builders, but the GUI builders recently have mostly been kind of just adjuncts to hand-coding, whereas Matisse seems to be targeting more like a quick, usable GUI builder, in comparison to say VB or some form builder from Microsoft. I think that's good, and I think it's needed. I was quite impressed by the demo. I would say that when we add support for third-party tools, we do it in a pragmatic manner. So, if there's a good use case for adding some feature to IDEA, we add it. And usually that means that there's some customers who are asking for it, and some special integration would significantly increase developer productivity. Also, the tool should be fairly stable, and kind of like a de facto standard, usually. So, if something, some tool, meets those criteria, we'll definitely add it to IDEA. If it doesn't, then we do have an Open API, and someone else, some third party, could add it as well, as a plugin. For example, IDEA comes with JUnit support, because JUnit is the de facto standard for unit testing. We don't have built-in TestNG support, but a few IntelliJ community members, Mark Derricutt and Hani Suleiman, they wrote a plugin for TestNG, which is a competing unit testing framework. Also, IDEA comes with Ant, because that's the de facto standard build tool, but say Maven requires third-party plugins. So, basically what I'm saying is, if there's sufficient support for Matisse from the community and it's a solid tool, et cetera -- I think right now it's a pretty early tool. So, I can't see in the short term that we'll be directly adding support for it. But, you know in the long term, we might. Also, we do have our own GUI builder, and we'll probably be taking 'lessons learned' from Matisse and applying it to our own GUI builder, as well. But I mean, there's nothing stopping us from adding support for Matisse, whether or not that is just the Natural Layout, or whether it's the actual GUI tool itself, it's hard to say.
JP: Okay. As listeners will know, we've had -- in the course of the previous Javacast episodes, we've had some pretty extensive discussions on component-based development versus, I guess, traditional, more editing-based development. I just wondered what yours and JetBrains' stance on the component based development model is. And is it a focus in IDEA? Is it likely to become a focus in IDEA?
RH: I think when I originally heard the Javacast that I had responded to, I was probably a little bit confused about what you meant by component-based development and I think I took the wrong interpretation. What I think, actually, is that, when Brandon says 'component-based development', I think he means a couple of things. I think he means -- there's basically three things. One is pluggability. What's a component? It's almost like a plugin, right? The other one is kind of like the wizard-like functionality or the usability -- you know, providing a tool to help you get past the set-up configuration. The other one is kind of like the big tool that does it all for you. For instance, Sun Java Creator Studio, which is a tool for getting beginners, and experienced folks as well, but basically to provide all this support for you. So, in terms of that, I'll answer three different questions. What is IDEA's focus on all three of those situations? So, again, it comes back to the pluggability, where, yes, we do have an Open API, but that's not our number one priority. Our number one priority is being the best tool for Java and J2EE development. And in that sense, we are not really component-based, and that's what I originally had thought Brandon meant when he was talking about that.
JP: Right.
RH: But, in terms of the other two, which is the usability, you know, being able to click Next, Next, Next, like Brandon was talking about. That is basically a major feature of IDEA, being able to quickly and easily do things like creating a new class, or you know, just anything. We try to build in as much usability as possible in our tool. However it is more for like hand coding, right? So, in terms of the big tool that does everything for you, that's not what IDEA is about. So, our wizards -- I think we only have one or two. We have a project creation wizard, and I think there's another one, but I can't think of what it is. So, we don't really have wizards so much as like dialog panels that help you quickly do something, and it's all keyboard supported, so you quickly do something like extracting a method, or adding a parameter to the method, or something like that. So, in terms of the big tool, that does everything for you, IDEA's not going to become that. But we do have another product called Fabrique, which we're working on, and it's idea is similar to the Sun Java Creator Studio for helping to make web application development easier to do by using a tool, as opposed to something like a framework like Rails or Struts, or something like that, which is supposed to help you in terms of productivity by providing tools for hand-coders. But this one is more for quickly developing using a GUI tool to help you do websites.
JP: Okay. Alright, let's move into some of the more fun stuff, architecture in particular. IDEA has strong support for J2EE and EJBs. Can you talk a little bit about that?
RH: So, in fact, IDEA 4, I believe it was 4, started to introduce support for J2EE, and IDEA 5 has really made that its major focus -- this is the latest version of IDEA. First of all, in IDEA 4, we had EJB configuration tools to help you with that. There was support for some refactoring, for renaming things. There was some support for JSP, and HTML and XML, but it wasn't quite integrated. So what we did was -- IDEA 5 has a lot more support, especially on the web development side, especially with JSPs and embedded CSS and JavaScript and HTML and the JSP 2 expression language. What we did to do that is we introduced a Language API, which allows anyone to develop plugins for any language, and you can add support for some refactoring, code navigation, finding usages, and highlighting usages, and syntax highlighting, and all sorts of stuff -- and inspections, and that kind of thing. We did that, that was a major undertaking for IDEA 5, and that will be the foundation for our future J2EE development support. We also have support for WebLogic and Tomcat integration built-in, and there are others available, and you can add support for any generic web app server. I think there's some JSR to cover the compatibility there, and we follow that spec. And I think that's about it.
JP: Great. What do you have now, and what do you have planned for EJB 3.0, the upcoming EJB spec, in IDEA?
RH: Well, we haven't decided yet. A lot of our developers are on vacation right now. But we will definitely support the EJB 3 spec. And the question is really, what exactly, how exactly we'll support it. I would have to say, or guess, that it will include some EJB-aware refactorings and navigation and configuration, helping you with the different annotation, and providing inspections about the proper usage of EJBs, and that kind of thing. So, this is a work in progress, and I don't know, is the spec even finished yet? I'm not aware of that.
JP: It's getting pretty close. It's in the final draft stages and stuff like that. JBoss and Oracle both have preview editions out there to mess with right now, but it's not finished yet.
RH: Well, when it solidifies, we'll definitely look into how we can support that. It will definitely be part of IDEA.
JP: We also had Bruce Tate on for a really fun interview in the last episode, and he was pushing alternate simplified frameworks like Spring and Hibernate, in that. I wonder, does IDEA have any support for that? Are there any plugins that allow you to do Spring and Hibernate and alternative frameworks in IDEA?
RH: This has currently not been a primary focus of IDEA. We do have some small support for Spring, which I can't recall exactly what it is, but we do have some small support for Spring. I think it's some sort of reference linking, being able to navigate, or something. I'm not sure exactly. But there are third-party plugins. All of them are free, that I can think of. For instance, there's Live Templates for Hibernate, for writing your XDoclet tags. There's a couple of plugins for Spring. One is Spring Console, which I think works in any IDE. The other one is called IdeaSpring, which can be downloaded directly from IDEA's plugin manager, and that offers some features like configuration and navigation like jumping to declarations and for ref and alias tags, and that kind of thing, and auto-scroll from source. And that's being developed, also I think that's from someone in our IntelliJ community, has developed that.
JP: Great. Actually Bruce spoke very highly of IDEA. That's his IDE of choice. I just thought I'd throw that in. We had a brief conversation prior to the interview about that, and he really likes what you guys are doing.
RH: Oh, I should mention that I met Bruce Tate at JavaOne 2004. He was there, he had his book, Better Faster Lighter Java, and he signed a copy for me. So that was fun.
JP: Oh great. He's a nice guy, great guy to talk to actually.
RH: Yeah, he's great.
JP: Okay, so you've mentioned a couple of times that IDEA does refactoring very well. Can you give a couple of brief examples of refactorings that are possible in IDEA, but not in other IDEs like Eclipse.
RH: Okay. It's kind of a case of, you know, if you compare feature by feature, then in most cases, Eclipse has many of the features IDEA has. But that's not what keeps people coming back to IDEA. It's not a feature list thing. I really believe that it's not so much about feature lists anymore. It's more about usability, and productivity. There are a couple IDEA-only refactorings, but I'll just briefly mention them, because I don't think that's the key to understanding what IDEA's about. So a couple are: Change Class Signature, if you have a generic class and you want to change the type parameters, the order of the parameters, or how many there are, et cetera. There's Safe Delete, which is being able to delete any class or any file you want to delete, without -- it checks first if there's references. There's being able to Replace Method Code Duplicates, so if there's a method existing in your class, and then many parts of the class also duplicate the functionality of that method, you just call this refactoring and it will replace all of those parts with a call to the method instead. There's Extract Superclass, which allows you to create a class in between two classes in a hierarchy very quickly. But I think that's not really the important difference here. The difference that I think is most important is how usable and how productive are these refactorings. So, the major differences there that I see is in, say, Eclipse, that if you have errors in your code, let's say you have a minor syntax error in some method, you can't rename that method. If you have a missing semicolon or something. You have to fix all the errors and then you can do your refactoring. For me, that is a major difference. You really have to try it to see what I mean, because if I just talk to you about it, it doesn't seem to sound very important, but so many times I've tried to use Eclipse, and I just get completely frustrated when there's some minor error somewhere, that I forgot to finish typing a name, but I want to extract some variable or method or something, and it won't let me do it. It says you have to fix the errors first. It completely gets me out of my flow, and I have to think in a different context, I have to switch contexts. Also, Eclipse is a little bit more unsafe than IDEA. For instance, you can't always undo refactorings, and when you can, sometimes it requires you to undo in every file the refactoring that was effected. Often times, you need to manually fix code after refactoring in Eclipse. We have some examples of that, but I can't think of them off the top of my head. We have more mature refactorings, like for instance Move Method. Move Method will handle cases such as inner classes in IDEA, where that is not handled properly in Eclipse.
JP: Okay.
RH: So, basically what I'm saying is that, it's not a matter of, you know, checking off, feature by feature and saying "Oh, this feature list is longer than that one," because that's not what's really important. What's important is, when you're developing in your day-to-day, you know, everyday programming time, that you want it to be as productive as possible. You don't want to be wasting time trying to fix the IDE's problems. The IDE should be fixing your problems. So, what else is there? Yeah, there's some other minor differences, but really it's the productivity that I think should be emphasized.
JP: Okay. I think that probably covers the majority of the next question I had, which was the question about the difference between -- or the benefits of static code analysis versus the automatic compilation on save that Eclipse has, and I think that probably rounds that off, unless you've got anything you want to add to that.
RH: Actually, I don't think it covers it at all, really.
JP: Oh, okay.
RH: This is one of these, kind of -- what do you call it? Like a 'diamond in the rough' feature. Unless you've seen it, it's really hard to explain what's going on. But I'll try to explain as best as I can. So, IDEA has 500 static code analysis, let's call them modules, or features. So, compiler errors are one thing. Eclipse, when you save, it automatically compiles, it lists certain errors. Most of those are compiler errors. Eclipse has about 30 other errors that it will -- not necessarily errors, but problems, that it will show up. But IDEA has 500, and these cover such a wide range of topics. It's not just possible errors, but it's things like internationalization issues, JUnit issues, J2ME issues, performance issues, serialization, threading, all sorts of stuff. And on top of that, it has some really great stuff, like there's a new inspection for highlighting in your code possible NullPointerErrors. We use a special annotation for that, for Java 5. It does things like code style issues. So it helps you highlight instantly in your code if you're violating some naming convention. Or say you're in one package, and you accidentally use a class in another package, and your project design has been set up by your team in such a way that you're not supposed access that package from the other package. That's a package dependency violation. So we have an inspection that will highlight that automatically. You just configure the package dependency rules that you want to set, and it will highlight that. Also it will show you a lot of redundant code things, like redundant if statements. This loop doesn't do anything, or redundant assignments of variables. So if you say like, a = a;, which sometimes happens when you intended to assign a field the value of some parameter, and you say 'field a equals a', but you forgot to put this.a, so it'll highlight that problem. And there's so many others, that it's just really -- this is one of the killer features of IDEA, and you really have to try it and see it to understand how it helps. What the basic benefits of this is that it drastically reduces common errors. It won't find major design errors, but it will find some design errors, like I said with the dependency violations, but also some class abstraction issues, or if you have encapsulation problems, like if you're exposing too many fields or something like that. It also helps you with things like migrating to Java 5. For instance it'll highlight for loops that are using the old style for loop and show you that you can replace this for loop with the new type of for loop. And in fact you can do it just by hitting one key and pressing Enter and it will automatically replace it for you. So a lot of these inspections are also attached with what's called a Quick Fix, which is different than the Eclipse Quick Fix. First of all it highlights in your code, and the Quick Fix will let you quickly apply whatever solution is suggested. First of all you reduce common errors, second you help improve your design, and the great thing about this is you do it as you go. So, you're working on your class, and you see all these things highlighted, you just clean up as you go. It's kind of like refactoring as you go. It's just something you should do as a continuous process. So, instead of waiting once a week and having a code review, you can have an 80% code review all the time, and then once a week you can have a code review to cover the rest of the 20% that automated code inspections can't handle. So, it saves you time, saves your time in code reviews, saves you time dealing with errors. I would say this is IDEA's killer feature, at this point.
JP: Okay. I have seen some capabilities from PMD analysis plugins available for other IDEs, but I do think, from the sound of the description you just gave, it does go a fair bit further than those. That's good.
RH: Yeah. The difference is, PMD does have more checks than Eclipse, but IDEA's is more complete, and PMD I don't believe it has quick fixes. It certainly doesn't have as many as IDEA's has. And IDEA's, it's all built into the editor, so these things work with all sorts of various things that PMD only, I think, only works on Java classes. For instance, IDEA's works in HTML files, and JSPs. You get all your same inspections in all your JSPs, if you have any scriptlet code in there. Also, it has CSS inspections. I could go on and on.
JP: Okay. Now we're going to move into the section of the interview where I've written some questions down that I kind of want to get some answers to as well.
RH: Sure.
JP: These will be a little more off the wall. But first of all, a particular interest of mine right now is scripting languages for the JVM. This is something I've found to be really very productive in recent projects. Particularly, Groovy is one that I've latched onto for its excellent XML and SQL support. I know there's a Groovy plugin for IDEA, because I was looking around recently to see what kind of capabilities it had, but at the moment it seems like it's limited mainly to syntax colouring and basically invoking the Groovy compiler. Are there any plans, do you know, to beef up scripting support for Groovy or other scripting languages? In particular, one of the things that I'm still waiting for from any IDE is a really good debugging solution for Groovy. So, any plans to do anything like that?
RH: Yeah. Our current plans are to support JavaScript as much as possible. And we provide this Language API, as I mentioned before, to allow other people to write plugins for other languages, and someone in our community has written the GroovyJ plugin, and it's more than just highlighting. I believe it also has code completion, and brace highlighting, and navigating between references, and this kind of thing.
JP: Oh, it may have moved on a little bit, since last I last looked at it. That's great.
RH: I think it has. It's using quite a lot of the Language API. And we're going to open up more of the Language API as we go, as we're able to make it more modular. Definitely, Groovy is going to be a big upcoming -- it's kind of like the competitor to Ruby on the Java side. So I think it's going to become pretty popular, and this will definitely be a major thing that we'll support. Basically, we'll be looking for people to write language plugins and have them give us feedback and tell us what problems they're having with the Language API, and what capabilities they need, and this kind of thing. So, we'll be developing the Open API, and other people will be using it. And we'll be using JavaScript as our internal test case for that. So, in terms of Groovy itself, as far as I understand it, Groovy classes are transformed into Java classes.
JP: Basically, the thing that really attracts me about Groovy is you can take virtually unmodified Java code and execute it under Groovy. But then you can start dropping out a lot of the type safety and using more of the dynamicism and stuff like that. But it also compiles up to Java classes. That, coupled with the good XML and SQL, are kind of the reasons I really like that particular scripting language right now.
RH: Right. So, in terms of that, I think there's the possibility -- and I was talking to Eugene Zhuravlev, who is one of our main developers, and he was telling me -- that if Groovy can generate debug info that meets the JSR 45 specification, then we can definitely add debug support to it. Now, it might not be possible right away in version 5, but we'll be definitely looking into this. It's something pretty important, I think, to this kind of support for these languages. So, you'd be able to set breakpoints and step over Groovy code, just like you would in JSP, for instance. We're definitely looking into that -- other languages. We're also looking into supporting XML-specific languages. There are so many different dialects of XML. I don't know if we've planned this specifically, but we're thinking of planning support specifically for XML languages to make it easier to create your own XML languages and provide IDE support: Refactoring, navigation, highlighting, and all that stuff, code folding, everything --
JP: Great.
RH: Reformatting. Other language that are possible are Python, Ruby. Regular expressions, I think we already have a plugin for that. XPath, we already have a plugin for that. And your own custom languages.
JP: Excellent. I look forward to that, seeing what happens there. Okay, we're going to get into an area where I've gotten myself into a little bit of trouble recently -- not just with you, a number of people have emailed me on this one. As a hobbyist developer, I work on the occasional small side project, and generally whatever I create -- saying I release it under the GPL is probably a bit grandiose, I usually push it out, let's see if anybody's interested, and it's GPL'd. It doesn't usually release as much as whimper and die. Anyway, given that, what options are open to me for using IDEA? Could I use the non-commercial license, and what would I have to do in order to use it?
RH: Okay. We do have an open source license, and there are some restrictions on it. First of all it has to be non-commercial open source, meaning it's not for profit, and also it has to meet the open source definition, it has to have a dedicated website, and an active community. As a hobbyist, it's not likely you're going to have a dedicated community if you just start right away.
JP: Right.
RH: It's not as broad as it could be, but it is available. I think at least 60% of the Apache -- is it Apache projects? I'm pretty sure. You can check our website. We have a page dedicated to that. Approximately 60% of the Apache projects using Java are using this open source license. And hundreds of other projects as well. And it's easy to apply, you just go to the website, you provide some information, and you get a one year renewable license for all the members of your project. But in terms of a hobbyist, we currently do not have a simple non-commercial license yet. I have considered that, and I'm kind of torn between the two possibilities as to whether or not it would be a good idea for our company in the long run to have a cheap, or a free. non-commercial license for everybody. But anyway, we're looking into that. In fact, I just read the other day an editorial by Rick Ross from Javalobby, who talks pretty closely about this subject. It was interesting to read his opinion, which was basically that it would be bad to do that, but I don't know, I'm torn. In my opinion, it could be a good idea, but we have to look into that.
JP: Okay. So basically the other option here is to actually -- for my hobbies, is to stump up the full price of $500. Given that, let's say I've got $500 and strictly this is, you know, for my own use, it's for messing around within my spare time. I have the choice of buying some hardware -- I actually went through this recently. Both my AMD 64 bare-bones kit and the Mac Mini I purchased recently came to about that amount. Can you make a case for me buying IDEA instead of one of those? Can you lay it out for me?
RH: Okay. So, in my personal opinion, that's really not an issue. $500? Yeah, it's a lot of money, but I mean, I enjoy programming and I want to use the best tools possible. So, in my personal opinion -- in fact, I did this when I was working at my previous company, I bought a copy of IDEA because my boss wouldn't buy it. I bought it with my own money, and I used it because I didn't want to use the other tools that were out there at the time. So finally my boss comes along and says, "You're using this? Isn't your evaluation expired?" I said, "No, I bought my own copy." And he's like, "Oh really? It's that good?" And I said, "Yeah, it's really that good." And so, he ended up pitching for licenses for the rest of the team. But anyway, that's my own personal experience. In terms of the general population, I would say that -- well, first of all there's one thing I should mention. It's not always $500, because we do occasionally, I think twice a year, we have a promotion for a Personal License, basically exactly what you're talking about, for half the price, so it's about $250, which, I don't know, that's really not a lot of money. And anyway, even if that is a lot of money for you, you can think of this analogy, which I mentioned to you in the email before. If you're a hobby bicyclist, and you decide -- you have a choice, you can ride in the city on a simple, cheap city bike, or you ride rough and fast on a mountain bike in the wilderness. You have a choice, what do you want to do? Some people are content riding in the city. They don't have a need to go on rough and fast terrain, right? So, that's an option, you can go for that. But, you know, you shouldn't expect -- just because there are city bikes that are out there that are cheap, or even used, you shouldn't expect bike makers, who make high-performance mountain bikes to make them cheap, just because there's cheap competition out there. What I would say is that, you have an option with IDEA. You have an option to try it for 30 days, see if you like it. And if you don't like it, you don't have to buy it. Or if you don't have the money, you don't have to buy it. It's kind of like, if you're happy with your city bike, and somebody says, "Here, you can try this mountain bike for 30 days for free. You don't have to buy it." Now the choice is, are you going to take that offer, or turn it down just because it has a price tag on it if you decide to buy. Personally, it would be a no-brainer for me. I would try it, because I like riding bikes -- or I like programming, and I want to see what the best tools out there are. Even if it's just to do some research for my professional job. I want to at least know what's out there. I try NetBeans, I try Eclipse, I try JBuilder, I try the other IDEs, and then from that knowledge I can pick the one that I like the best, and the one that suits me the best. So, that's how I would council people who are deciding. Try the IDEs, you can try them all free, and pick the one that you like the best. The other thing is that it's kind of like buying a Mac versus buying a Windows PC. People pay a little bit of extra money for a Mac. Why do they do that? It's because they enjoy using it. Even if you are just buying it for your own personal use, a lot of people they choose to buy a Mac because they prefer it. That's my opinion. I think that usability is a feature worth paying for, even if it's only for your own personal use. This is not a $5000 thing, it's not a $10,000 thing. It's only $500 and if you catch the yearly specials then you can get it for cheap for $250. And the last thing I'd like to say about this is that I think the reason I enjoy programming is because of something called flow, the mental state called flow. Your listeners can look it up on the C2 wiki, that's the original WikiWiki. It talks about this mental state you get in when you're highly focused, and even athletes have a thing called 'in the zone', which is very similar. You know, when you're deep in a problem in programming, and you're just chugging along, and you're just churning out code. It really is an enjoyable experience, and I think that's worth a little bit of my money to get that. And this is one of the things that IDEA focuses on, making programming so fluid and productive that you can get in flow, and you can stay in flow. It doesn't get in your way. It provides simple features that you can use at your whim. It gives you more control over the code. The more control you have, the more you can get into flow. It's like a programmer high. It's like a drug, in a way. It think this is why we have such loyal fans, because this is what it focuses on. It doesn't focus on being some platform for everything but nothing in particular, it focuses on being a Java IDE so you can get right in there and do your coding.
JP: I would just very gently offer a slight counterpoint on this one, my own personal feelings on it. Being the kind of developer that I am within the company I am, I always have a list of things as long as my arm that I've got to sit down and research at some point. And just knowing that if I do decide to use it, I am going to have to pay this fee, it just shuffles it down the list there a bit. I'm constantly searching for more time to learn new frameworks and new things that can help my job. This is one of those, it's not the only one. It just kind of shuffles it down the list. I think for me, something for personal use, and I am talking about personal non-commercial use -- I don't think $500 is out of line at all for anything that is corporate-used. In fact most frameworks, or most tools, cost a lot more than that. But for personal use, I've probably got a cut-off of about $100 maximum. I kind of look for the $50 to $100 -- it doesn't matter if it lacks things like full team capabilities, or stuff like that, for personal use. It's just I want to be able to get into it at a slightly more comfortable level. Personally, I find $500, I can get some pretty good hardware with that. Maybe it's just me, but I don't think I'm the only one out there. That's what I guess I'm trying to get across there.
RH: No, I agree. For some people it's not worth it, because that's their own personal feelings about it. And the only thing that I would say is, make that an informed decision. Try it, because it's free to try it. And while you're trying it, there's no obligations. There's nothing stopping you from trying it.
JP: Okay. Moving on, is there any kind of direct customer, or potential customer, feedback or forum, where developers can come and talk to you about what's available and maybe ask for stuff that they'd like to see in IDEA?
RH: Yeah there is, and in fact this is actually one of the big things that makes IDEA what it is today. We have a fairly large community. It's not as big as Eclipse, or -- I'm not sure about the NetBeans size -- but it's a fairly large community, it's customers, people who are just trying IDEA. And we have two websites. One is called intellij.net, and the other one is intellij.org. I would suggest, if anyone is interested, to go to intellij.net first. There's also, of course, for our customers we have full support. We have a dedicated support page for that, and a dedicated team for that. But the community is really the big factor here, that I would like to talk about. We have an interesting development process. Remember I mentioned I was a fan of -- I still am a fan of agile methodologies, like Scrum and Extreme Programming, and you know, I wanted to know how does this company develop this product, because it was developing features really super-fast, and they were good features, and it was very impressive. And I think to a large extent we are able to maintain that kind of turnaround. So I wanted to know, how does this company develop its software. So that's one of the reasons I joined the company. As it turns out, the method we use is called the Early Access Program, and we have a dedicated website for that, it's under the intellij.net website. We have forums and newsgroups that go along with this. Anyway, the Early Access Program -- basically what you do is, as we're developing the next version, you can get free licenses. Anyone can get a free license, as we're developing the next version. There's no strings attached. We do ask that you try to submit bugs and everything. We do tell you that it's not going to be perfect. It's not going to be fast, because we sacrifice performance while we're developing new features; we tune up the performance near the end. But what we end up with is a large community of people who are trying IDEA everyday, trying the new versions, and submitting reports, not just bug reports but feature requests, and we listen to them. So, if there's enough support for a feature request, we'll put it in. And in fact, a lot of the time it can happen very quickly, within a couple of weeks sometimes -- or within a few days sometimes. So, this is a very important -- I can't stress it enough -- it's a very important factor in why IDEA is what it is today, because we have a lot of people who use it all the time, and are really testing it, pounding it, trying it, and giving us feedback. And the important thing is that we listen to the feedback, and we make the changes, and post new builds every week or two, or sometimes every few days depending on the situation. So, yeah, we do have ways that you can get in touch with other people who are using IDEA, ask questions, get support. I would say go to the website and you can find it from there, jetbrains.com or intellij.net.
JP: Great. Thank you. Okay, well that's really the end of the questions I've got. Is there anything else you want to talk about, concerning anything, Java development in general, or IDEA, or anything like that?
RH: Yeah. This is a thread that's been going through my mind for quite a while. I listened to Bruce Tate's interview and, you know, he's talking about 'beyond Java', what's coming up. His attitude is that you shouldn't settle for the status quo. Just because the J2EE and EJB is "the way you should do it" doesn't mean that's the way you should do it. You should look for other alternatives out there. So, there's a lot of really interesting, exciting stuff coming up. Not just in the Java space, but in the entire development space. Things like Ruby on Rails, Groovy, even C# and .Net. There's so many new things that are coming up. We're working on something called Language Oriented Programming; I won't go into that, but it's an interesting thing. So, I'd just like to say that I think that people should not settle for the status quo. Raise your expectations. See what's out there. Just because you're doing something a particular way right now, you know, there might be a better way of doing it. So, you know, go out and look for alternatives. You might be pleasantly surprised.
JP: Actually, one more question has occurred to me here. I thought about writing this one down, never put it in there. I noticed that both you guys and the NetBeans team are based in Prague. It just seems an unusual coincidence, that. Do you guys have food fights and lob things at one another, or is there any kind of story behind that, or is it just coincidence?
RH: Hmm, I'm trying to think of the history now. I believe it's a coincidence, because Sergey Dmitriev was in Prague, he was working for TogetherJ, and he split off and started JetBrains, or IntelliJ at the time. And I think the NetBeans guys were independent. And the funny thing is -- oh no, I'm sorry, I'm thinking of something else. Yeah, the NetBeans guys are independent, and I'm not sure how their history -- like how they started and everything, but apparently some guy started it, and Sun picked it up. It's just independent.
JP: Okay.
RH: But, you know what, I've never met any of them. In fact, most of our development goes on in St. Petersburg now. It started here, but most of the development is in St. Petersburg, Russia.
JP: Okay. Well, thank you very much, Rob. That was an excellent interview, and hopefully it will be up fairly shortly, certainly in the next week.
RH: Thanks a lot, Dick.
posted by Rob Harwood at 7:36 PM
37 comments
