Java-based NetBeans began life nearly 20 years ago as ‘Xelfi’ – a project at Charles University in Prague. Since then, it’s evolved into one of the most popular IDEs for developers in the JVM space, used by 10% of Java developers in a recent poll. A large part of the success of NetBeans can be attributed to Jaroslav Tulach, who holds the title of NetBeans founder and initial architect. In this interview, we travel the length and breadth of the NetBeans journey through the years, discuss Tulach’s involvement with the DukeScript, and the disconnect between old school Java programmers and youthful JavaScripters. Why was the move to modular so pivotal to him, and what does he deem critical for the success of Java in the future?
Voxxed: To what extent do you feel you were successful in meeting your primary aims for NetBeans? (For a full look at the history of the IDE, check out the excellent Wiki page which Tulach has recently put together).
Tulach:When NetBeans company was established, we basically threw away all of the Xelfi code and started to work on version 2.0. The business goal was clear: to support all the newly appearing Java technologies of that time, attract enough users, and be acquired by a major Java player (which happened in autumn 1999 when NetBeans was acquired by Sun Microsystems). However the technical goal (which was closer to my heart from my perspective of NetBeans Architect) was to break the original monolithic design of Xelfi.
I had a vision of modularity. I envisioned a JAR with all the well defined APIs, another separate JAR with implementation of such APIs and then many small modules plugins with support for various technologies (Java, JSP, EJB, etc.). I think this vision worked great (with one small correction, you need many JARs with well defined APIs), so I like to refer to NetBeans not as an IDE, but as “the first modular Swing application framework in Java”. Without modularity we couldn’t manage the thousands of modules which compose NetBeans IDE these days.
You’ve since turned your attention to the Duke Award winning project, ‘DukeScript‘, designed to put the Java back into JavaScript. What do you have against JavaScript and HTML5?
Well, I am just a contributor to a small part of the DukeScript project. The name and the vision to glue various different technologies (some created as part of NetBeans project) and combine them into DukeScript is idea of Toni Epple.
For me personally, JavaScript is just another assembly language. An object oriented assembler people were seeking for in 80-ties. At that time I was coding in Z80, C64 assembler and felt happy, but things have changed since those days, I don’t see any reason why people should code in assembler anymore. And certainly I am not going to do so myself – I rather spend a year to create a framework than to write directly in JavaScript.
I know large group of people that are fine with JavaScript, but face it: It’s a “write once and throw away” language. You write your code once and ship it when it works. Later, when you are asked to change something in it, you are afraid to touch it. No refactorings, as no tool can guarantee that your code will behave the same after refactoring (unlike in more restricted languages like Java), no huge changes – touch it only lightly and with care. It is often easier to start from scratch.
I hear complaints of this kind from executives everywhere. Especially if they have one gang of Java programmers and another of JavaScript developers in-house. They tend to see the latter as less reliable geeks always trying something new, but never delivering long lasting product. It may be clash of generations (as JavaScript guys are usually younger), but I believe the root cause is the assembly nature of JavaScript.
To illustrate why I believe JavaScript is another assembly language, let’s think about a way to invoke original implementation in an overwritten method. In Java you’d use “super” keyword:
1
2
3
4
5
|
protected void aMethod() {
super.aMethod();
}
|
This is a common construct in classical object oriented languages, not only in Java. It makes it easy to do something programmers do frequently – for example, specialising behavior when subclassing. However “super” has its limitations: you cannot call super.super.aMethod() – e.g. skip level of inheritance. You cannot call super.aMethod on some completely different object, etc.
JavaScript does not have concept of “super” – however it has something more powerful: there is a “call” function where you can specify the actual method/function to call, on what object (e.g. “this”) and with what arguments. You can use the “call” concept to simulate “super”, but you can also use it in a number of other ways. It is flexible, but low-level. It is something that belongs to assembly language, but not something regular developers should use when coding their business logic.
I have to repeat myself: if you keep coding in JavaScript, you end up like everyone who’s using assembler: feeling powerful at first, but constrained in the years to come.
What are the overarching aims with DukeScript? What makes it different to JavaScript and HTML5?
These days there seem to be two progressive directions of UI development: mobile and browser. The mobile world is currently dominated by Android and its flavour of Java, and it seems to be doing really well. On the other hand, the browser is about HTML5/CSS, followed very closely by JavaScript.
These two worlds seem to be separated, yet it is very clear that both sides are looking at each other and trying to find a way to capture the other market. So far the efforts are not very satisfying (in my opinion) as each carries the weaknesses of originating world with itself making it almost unacceptable for the other world to swallow such technology. On one side most of Java developers don’t want to code in JavaScript. On the other hand, browser plugins for Java and flash are less and less popular.
Is there a way to pick-up best of the two worlds? DukeScript does it. Unlike its name, DukeScript is not a new programming language. DukeScript merges HTML5/CSS with Java, without the need to write business logic in JavaScript. DukeScript’s inventor Toni Epple calls DukeScript – “the JavaScript as it was meant to be” – and I can only confirm that: if the way DukeScript interacts with HTML elements was known in ’90s, there would be no need to invent JavaScript (and name it so it piggy backs on Java popularity).
Everybody who tries DukeScript can immediately see its benefits. HTML5/CSS can be rendered on any device these days and (as world-wide-web and its essential HTML format celebrated twenty fifth anniversary last year) it’s tooling is really excellent. Everyone knows how to write an HTML page and use responsive web design to make it cross-platform these days. Java has been around for more than twenty years and its tooling is also superior. IDEs support refactoring, static code analysis, reliable code completion, and there are an enormous number of libraries to use. Java is industry strength language known to keep cost of ownership low – way lower than any “Joe, the developer” using the “assembly language of these times” – e.g. JavaScript – managed so far.
DukeScript (named after Duke, the mascot of Java) brings together the strengths of HTML5/CSS and Java while allowing you to write once and display everywhere. The same application can be packaged to run on desktop, Android, iOS and even in a browser. DukeScript tooling builds on the synergy of the best tools available for HTML5/CSS and for Java and clearly separates the developer vs. design workflow. Use your favourite HTML5/CSS auditing tools for the UX design, and use your favourite Java IDE to develop application logic. Reduce time to market with DukeScript ‘s carefully designed APIs leading to comparable and sometimes even shorter code than similar JavaScript based solutions. Speedup your edit/try cycle by automatic hot redeploys of your HTML and Java without page reloads or restarts. Be productive. When done, let DukeScript package everything for you and just deploy everywhere: AppStore, Google Play, your website, native app, etc.
You’ve been working with Java for many years now – how have you seen the community change?
I’d say it is getting older. That is sad, but probably inevitable. Younger generations seem to have other toys to play with – I’d say that every generation needs its own assembler – so they don’t find Java that interesting. I’d like to change it, but for that it is essential to re-establish Java reputation on the client – that is why I am such an enthusiastic supporter of DukeScript.
What do you hope to see in future versions of the platform?
Java has to get smaller, not bigger. I have been observing and contributing ideas to project Jigsaw – the modularisation of JDK – since 2006. I am glad to see the project finally delivered some results – at least the sources in Java repository are now modularised.
However, we need more of that. The smallest proposed JDK9 module still has more than 3000 classes. That is way too many for my purposes. Also, I am a bit worried about adding more complexity to the VM specification, that will only complicate life of alternative VM implementations (like my
Bck2BrwsrVM, for example).
But my hope still lives on that we we will have small, easily portable Java core one day.
How do you think NetBeans ranks alongside other leading IDEs – what to you makes it a standout?
Recently I had some interaction with Gradle community and Gradle inventor suggested that IDEs should not invent their own internal build system. I can only support such idea: a good IDE should be just a UI wrapper around the build system!
This has been NetBeans vision since 2003 – first of all NetBeans was a wrapper around Ant, then Make, later also Maven, now also Gradle. As a result one can trust that pressing F9 (build) is the same thing as typing “mvn install” on command line – e.g. if it works in NetBeans, it will also work well on the continuous integration server. I can’t envision development style where the connection between IDE and build system would be any weaker.
In case somebody is looking for an IDE tightly integrated with build system, try NetBeans and you’ll be surprised how addictive such connection can be.
There’s a lot of excitement around JavaFX – can you see it eventually displacing Swing entirely?
I’d like to use the excitement around JavaFX and re-transform it into something more promising – i.e. DukeScript.
There are excellent things that JavaFX provides: CSS-like styling or declarative description of UI via FXML. However there is one problem with JavaFX – it is a complete stack – from the widget APIs, through the various rendering pipes, down to the hardware video card accelerator. This is a lot of code to maintain and the code is different for each supported platform. No wonder the JavaFX team at Oracle used to have hundreds of engineers. However, as far as I can tell, there are not as many people working on JavaFX anymore, and it will be hard to ensure wide portability and pace of innovation.
Nonetheless, if you like CSS styling and want to describe your UI in declarative way, there is no reason to despair – try DukeScript. The UI is in HTML/CSS and the programing language is still Java. Moreover DukeScript is really lightweight – it is just a tiny, yet inventive, Java wrapper around web pane – as such your mobile application will be few times smaller than similar JavaFX one. Moreover the rendering stack is reusing work done by major browser vendors and as such it is easy to keep up with the innovation happening in the JavaScript world and also port such applications to run everywhere.
If I was a Java developer trying to bring my client application to new platforms (like iOS, Android, embedded, browsers), my choice would be DukeScript.
As a well respected veteran of API design, what fundamentals would you give to any developer looking to emulate your style?
There is a difference between building an in-house software and building a framework. If we try to apply our daily knowledge based on the in-house development when developing a framework, we may be very surprised. I call such surprises “paradoxes” – situations where our expectations are not matched. I don’t claim I know everything about API design, but I managed to collect at least 20 API Paradoxes and enlist them in a book
http://www.amazon.com/gp/product/B009NNXPES – it’s a relatively easy read and knowing some of these paradoxes in advance can save every starting API designer quite a few surprises.
This story, "NetBeans Founder Jaroslav Tulach: “Java has to get smaller, not bigger”" was originally published by voxxed.com
