In a recent special election, JetBrains was elected to the JCP Executive Committee to fill one of the seats vacated by Ericsson and TOTVS. Trisha Gee, developer and technical advocate at JetBrains, and Anna Kozlova, software developer at JetBrains, will represent JetBrains on the executive committee. JetBrains will serve out the remaining two-year term that ends in 2018.
JetBrains was unable to vote on the JSR 376 original ballot, because their tenure on the executive committee commenced on May 15, 2017. However, they were eligible to vote on the reconsideration ballot and voted in favor of its passing.
Gee spoke to InfoQ about this latest milestone for JetBrains, what they plan to accomplish, the recent JSR 376 vote, and plans for future development.
InfoQ: Why is this seat on the executive committee important to JetBrains?
Trisha Gee: It's really great not only to be able to see what's coming in Java, but also to have some influence over it. The JCP is a much more transparent and open process than it was before, thanks to a lot of effort from the User Groups (in particular) on the EC helping to drive this, but also from all the JCP EC members, particularly Oracle, for recognising this need and working hard to make it happen. But it's one thing to be able to review specifications and give feedback to the Expert Groups, it's another to be able to influence the development by voting on those specifications. And as you've seen from the process with JSR 376, if the Executive Committee has concerns about a JSR, those concerns really do need to be addressed before progress can be made. But JetBrains' goal is not simply to throw our weight around, it's to be another representative of Java developers on the EC, so that the end user's voice is heard when these specifications are thought of.
InfoQ: How was JetBrains nominated as an executive committee candidate?
Gee: There are three types of seats on the EC: ratified, standard, and associate. Oracle, as the stewards of Java, gets to choose who to nominate for ratified seats, and they picked ARM and JetBrains to take over two vacant seats. You'd have to ask a representative of Oracle for the reasons why they chose JetBrains, but I like to think it might be one of more of the following reasons: we (JetBrains) have been involved in the JCP before, we've been members of Expert Groups and contributed to a number of JSRs; JetBrains not only makes tools for Java and JVM developers, but also develops our own JVM language (Kotlin), so we have a very keen interest in the development of both Java-the-language and Java-the-platform; we have a bi-directional communication with Java users - our users tell us what they expect from the platform and tools, and we communicate frequently with the Java community about the technologies that are out there, how to use them, and have the ability to also educate people about the JCP and the processes that go into evolving Java; and finally I personally have been a representative in the EC before as a member of the London Java Community, so I know the processes and the community knows me.
InfoQ: JetBrains was unable to vote in the original JSR 376 ballot that concluded on May 8, 2017. If you were able to vote on that ballot, how would you have voted based on the status of JSR 376 at that time, and why?
Gee: I'm actually really pleased we weren't able to vote on that one! It was a very tough call. I, personally, would have liked to vote "yes," this is from the point of view of a Java developer who just wants Java 9 to get out of the door. I've also used the new Java Platform Module System (JPMS), on new projects and have migrated an existing modular project to JPMS. I've seen how much it’s improved over the last year, and how much developers can gain thinking more explicitly about modularity, encapsulation, separation of concerns and so on. It's not perfect, and definitely has its rough edges, but I was leaning towards a "yes" vote.
Others inside JetBrains quite correctly pointed out that my approach of "let's just get it out of the door" is a terrible reason to push something through, and that something with as big an impact as the JPMS really needs not only to be well designed and well thought out, but also has to be accepted by the community or it will never achieve the goals set for it. Given we don't use JPMS inside JetBrains (although we do provide support for it in IntelliJ IDEA), we didn't have solid enough experience working with it to be able to say whether it was fit for purpose or not. I think we probably would have abstained, which means we wouldn't block any progress, but we would be able to register any concerns about the JSR, most notably about its impact on existing libraries, frameworks, and tools.
InfoQ: The tenure for your position on the executive committee ends in 2018. What happens after your tenure expires?
Gee: I hope we'll be nominated for re-election! We aim to be valuable to the EC so that not only are we nominated for the ratified seat but we are elected again.
InfoQ: What do you hope to accomplish during your tenure?
Gee: Our goal is to help create specifications that are valuable to Java developers around the world, and to help the language to evolve in a way that makes people more productive. We want to evaluate each JSR according to whether it will help a developer get a job done.
Of course, as an IDE vendor it is up to us to provide the tools to help developers to use libraries and frameworks that conform to the specifications - if this is hard for us to do, it'll be hard for developers to use, too. We also hear a lot of feedback from our users about what they would like to see in Java to help ease the pain of things they do regularly (see our blog post announcing the election to the JCP). This helps us to understand the priority of things under development, and push for those we think are important.
I would also like to see even more participation from all Java developers in the JCP. User Groups like the London Java Community have really been leading the charge on this, but we can reach other developers who may not be aware of initiatives like Adopt a JSR and Adopt OpenJDK, and through our blog, Twitter, and newsletter we can share with the development community not only what's coming in Java, but how they can be involved in the process and how they can impact it as individuals.
InfoQ: What’s on the horizon for JetBrains, especially IntelliJ IDEA?
Gee: We're working really hard on our latest IntelliJ IDEA release, 2017.2. It has a lot of updates for Java 9, which I'm particularly happy to see, especially because some of them are features I requested!
As well as this, we have a lot of plans for Kotlin, too:
- adding support for Java 9.
- adding enhancements for Java interop that will make many scenarios (including the ones common for Spring and Android) even easier.
- Gradle Script Kotlin (the new Kotlin DSL for Gradle) is getting improved IDE support.
- We are improving the tooling and library support for Kotlin coroutines, including some very handy debugger features.
Looking into the future, Kotlin is looking into value types in parallel with Valhalla.
InfoQ: How long have you been with JetBrains and what are your current responsibilities?
Gee: I've been with JetBrains for 2½ years. I'm the Java developer advocate, and I work mostly with IntelliJ IDEA (JVM/polyglot IDE) and Upsource (code review tool). As a developer advocate, my job is not to try and sell our tools, but to help developers become more productive in their jobs - if they use IntelliJ IDEA to do that, this is obviously great for us! But my focus is more on helping developers to "level up," for example talking about Java 8 top tips, and showing developers the new features in Java 9.
InfoQ: As one of the representatives for JetBrains on the executive committee, how will this affect your current responsibilities?
Gee: It's more work! But it overlaps quite nicely with my responsibilities. For example, I need to stay on top of the evolution of Java so that I can make sure the material I work on (presentations, blogs, screencasts, and a monthly Java newsletter) is up to date and relevant, ideally with many topics that are ahead of where developers are currently working, hence the focus on Java 9 this year. Working on the Executive Committee almost guarantees I'll learn about what's coming for Java, either in Java-the-language (for example, the recent Jigsaw vote) or the wider ecosystem (e.g. Java EE). So being a representative on the EC does involve more work, in terms of meetings with other EC members, researching the current JSRs, figuring out how to vote, but this aligns well with my goals of bringing the latest Java news to developers.
I'm not doing this alone; it would be impossible to be an expert on everything in the Java ecosystem. Inside JetBrains we have a working group of about a dozen people with different backgrounds, responsibilities, and experience, and each of us will chip in information on the JSRs we have expertise in. This range of experience allows us to better represent developers using the Java platform.
InfoQ: IntelliJ has been enjoying spectacular success, perhaps against the odds, given that powerful tools like Eclipse and NetBeans are free. What is your secret?
Gee: Well, importantly it's still free for a lot of Java developers: I myself used the Community version for years when I was at LMAX; this free version still provides the killer features around refactoring, navigation, code analysis and so on.The paid version, Ultimate, has extra support for Java EE development, Spring, UML diagrams, and much fuller support for polyglot programming. Because of this, it's often companies that pay for the subscriptions rather than individuals - they see how productive their developers are using the free version, and are willing to pay to get the extra features to support enterprise development.
I myself made the switch from Eclipse to IntelliJ IDEA after pairing with the power users at LMAX. Previously I'd used both IDEs (and I'd used Netbeans too earlier in my career) and didn't really have a preference, all IDEs supported the way I coded. But once I saw IntelliJ's refactoring tools in action, saw that the IDE could reshape my code without causing compilation errors, I was hooked. I know the other IDEs do this too, but my personal experience pairing with both Eclipse and IntelliJ power users is that IntelliJ IDEA just did much more, and painlessly. I speak to a lot of developers in my job and many of them tell me a similar story - once they discover how much more productive IntelliJ IDEA makes them, and how it helps them to stay in the flow, they can't go back.
