Saturday, March 28, 2015

“Database is wrong for you” and all that FUD

Checksum-based storage. It’s one of the key features that makes Artifactory better than the competition. Here is the typical false claim made by Sonatype (creator of Nexus, that uses a plain Maven2 filesystem for their repository) about Artifactory storage:

“Artifactory takes the polar opposite approach and stores the metadata and the artifacts themselves in a huge database. The reason they claim it’s needed is for transactional behavior. Using a database doesn’t guarantee transactionality and it certainly isn’t the only way to get transactional behavior.”
Not only are these claims and vague reasoning wrong (we didn’t do it just for the sake of transactional behavior, and we recommend to store the artifacts on the disk), but so is the main claim that using a database is bad for you. Here are the real reasons that Artifactory uses checksum-based storage:
  • Deduplication- By referencing binaries by their checksum, pretty much like Git or Dropbox do, and not relying on filesystem paths same-content files are never stored more than once. This is one of the few ways you can optimize the storage of binaries.
  • Free copy and move- Artifact promotion (i.e. Moving between repositories with different visibility rules) is critical for building continuous delivery pipelines. With a checksum-based storage those operations don’t involve any filesystem activity at all – just adding and removing file references in the database.
  • Efficient uploads, downloads and replication- Optimize network operations by first sending checksum headers. Files that already exist in storage are skipped, even when they appear under a different path.
  • Filesystem performance. Since files are never overwritten, and are only deleted during storage GC, normal operation never requires a write lock on the FS. Expect significant performance gains compared to plain FS storage.
  • Search stability and performance-
    Misusing frameworks initially meant for full-text indexing to search through a filesystem is fragile and slow. With a checksum-based storage, all repository information and artifact metadata are stored in optimized database-indexes: always up to date, blazingly fast and never broken.
  • Freedom of layout- When metadata is extracted only from the filesystem and the files are locked in a Maven2 (or any other) layout, it’s hard to impossible to support other layouts. Since Artifactory uses the database as a layer of indirection between the actual storage and the displayed layout, it natively supports all layouts including Maven2, Maven1, Ivy, Gradle, Nuget, YUM, npm, debs, Docker, PyPI or any other custom layout.

Get the picture?

Smart checksum-based storage == powerful  features and better performance.

Naturally, Artifactory supports all the major relational databases including Oracle, MySQL, MS SQL Server and PostgreSQL. We could have used any database, including NoSQL ones, however we choose to use a relational database as a bullet-proof technology that many of our customers, enterprise and startups alike, feel at home with. Out of the box, Artifactory comes with a bundled Apache Derby DB, and customers switch to their production DB by modifying one line of configuration.

And look who’s crashing the party!

It took a while, but it looks like Sonatype finally got the picture as well.
Тhe Maven2 layout is burned into Nexus repository information that is a mixture of a Maven2 inflicted Nexus index in Lucene format and the file-system. This effectively blocks Nexus from being flexible in supporting other systems and layouts.
To solve this problem Sonatype mimicked the Artifactory approach by using H2 for their NuGet support. It didn’t help much; Nexus support for NuGet is “suboptimal” to say the least, but at least it shows someone finally understood that relying purely on the filesystem for metadata and indexes can not scale.

“H2″ you said?

So what’s that H2 database that Sonatype use for Nexus? Well, it’s an embedded in-process database which is supposed to give Nexus an escape route from its Maven2 layout prison. Is it any good? It is! Does it have commercial support that you might transitively need when using Nexus for production? Judge for yourself! And I’ll quote:
“Commercial support for H2 is available from Steve McLeod (steve dot mcleod at gmail dot com). Please note he is not one of the main developers of H2.”
All in all, it’s definitely a step in the right direction. Unfortunately, it leaves Nexus users in pretty much the same place: a repository locked down to the Maven2 layout filesystem, effectively making anything other than Maven artifacts a second class citizen; and optimized metadata locked down to a production-questionable in-process database.

NetBeans Founder Jaroslav Tulach: “Java has to get smaller, not bigger”

Jaroslav Tulach
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:
protected void aMethod() {
   // do something before inherited behavior
   super.aMethod(); // invoke original behavior
   // do something after inherited behavior
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.
Find out more at
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 – 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

Why You Should Care About the Java EE Management API 2.0 (JSR 373)

In recent a GlassFish Community blog post, Reza Rahman comments that JSR 373 –  Java EE Management API 2 , has thus far sat in the shadow of other Java EE 8 initiatives. With the JSR now moving full steam ahead though, you can expect to hear a lot more about it going forward.

A modern counterpart to the J2EE Management specification (JSR 77), which was designed to manage various resources on an application server, JSR 383 is aiming to adopt REST as the de-facto interface for communicating with managed objects and providing functionals like exposing the CRUD operations on managed objects as RESTful interfaces.
As Abhishek Gupta notes in his whistle-stop tour of all things Java EE 8, JSR 373 will also leverage SSE to distribute events in response to changes in managed object states, and allow for deployment of Java EE applications using a REST interface.
To Rahman, it represents “one of the most interesting and useful parts of Java EE 8.” Whilst the success of JSR 77 was muted by factors like an overly “complex, abstract and cumbersome” API, Rahman writes that this new incarnation will be a new opportunity to take on the problem with a modern set of tools. In addition to REST, this will mean taking advantage of things like SEE and possibly WebSocket for event notification.
The interface should resemble the GlassFish REST management interface, which will mean that, from an industry standpoint, developers will be able to work, “with all Java EE 8 application servers using a uniform, predictable cross-platform API from all kinds of tools from simple HTTP command-line clients to Chef and Puppet.” It will be accessible both on cloud and on premise.
There’s already an expert group in place for this particular JSR, but you can subscribe to the JSR user alias to keep up with all the latest on this Java EE 8 effort. For the Java EE Management API 2.0, this alias is users at javaee-mgmt dot java dot net – head to the Java EE Management API 2.0 project page to subscribe.
We also recommend checking out this featured Parleys presentation, where Arun Gupta outlines everything coming in Java EE 8 – including JSR 373 (skip ahead to 0:13:03 for this part) – and how it all links together. And, as ever, if you’d like to join this global push in the name of Java, you can always get involved in Adopt a JSR. Click here for a detailed account of what this entails, written by Mani Sarkar.

This story, "Why You Should Care About the Java EE Management API 2.0 (JSR 373)" was originally published by

10 difference between Java and JavaScript for Programmers

Programmers, developers and internet users  have always been confused between Java and JavaScript.  Many people still thinks that JavaScript is part of Java platform, which is not true. In truth, JavaScript has nothing to do with Java, only common thing between them is word "Java", much like in Car and Carpet, or Grape and Grapefruit. JavaScript is a client side scripting language for HTML, developed by Netscape, Inc, while Java is a programming language, developed by Sun Microsystems. James Gosling is Inventor of Java, popularly known as father of Java. While in today's world calling JavaScript just a client side scripting language would not be good, as its now been used in servers also using node.js and people are doing object oriented development in JavaScript, but that was what it was originally developed. There are several difference between Java and JavaScript, from how they are written, compiled and executed. Even capability of Java and JavaScript vary significantly. Java is full feature Object oriented programming language, used in almost everywhere, starting from programming credit card to server side coding. Android uses Java as programming language for creating Android apps, Swing is a Java API used to create desktop applications and Java EE is a Java platform for developing web and enterprise applications. On the other hand JavaScript is primarily used to bring interactivity into web pages, though there are other alternatives like Flash, JavaScript is the most popular one and regaining lots of ground lost earlier with introduction of powerful and easy to use libraries like jQuery and jQuery UI. You can use JavaScript to validate user input, create animation and cool effects in HTML page and can do lot of interactive stuff e.g. reacting on button click, mouse movement, image click etc. In this article, I will share some key differences between Java and JavaScript, mostly from a programmers perspective.

Difference between Java vs JavaScript

Here is my list of key differences between JavaScript and Java as programming languages. I have worked both on them, mainly used Java for all Server Side development, Android and JavaScript for writing client side scripts to do validation, interactivity, animation and ajax calls.
Difference between Java and JavaScript

1) Execution Environment

First difference between Java and JavaScript is that Java is compiled + interpreted language, Java code is fist compiled into class files containing byte code and than executed by JVM, on the other hand JavaScript code is directly executed by browser. One more difference which comes form this fact is that, Java is run inside JVM and needs JDK or JRE for running, on there other hand JavaScript runs inside browser and almost every modern browser supports JavaScript.

2) Static vs Dynamic Typed language

Another key difference between JavaScript and Java is that, JavaScript is a dynamic typed language, while Java is a statically typed language. Which means, variables are declared with type at compile time, and can only accept values permitted for that type, other hand variables are declared using vary keyword in JavaScript, and can accept different kinds of value e.g. Stringnumeric andboolean etc. When one variable or value is compared to other using == operator, JavaScript performs type coercion. Though it also provides === operator to perform strict equality check, which checks for type as well. See here for more differences between == and == operator in JavaScript.

3) Support of Closures

JavaScript supports closures, in form of anonymous function. In simple words, you can pass a function as an argument to another function. Java doesn't treat method as first class citizen and only way to simulate closure is by using anonymous class. By the  way Java 8 has brought real closure support in Java in form of lambda expression and this has made things much easier. It's very easy to write expressive code without much clutter in Java 8.

4) OOP

Java is an Object Oriented Programming language, and though JavaScript also supports class and object, it's more like an object oriented  scripting language. It's much easier to structure code of large enterprise application in Java then JavaScript. Java provides packages to group related class together, provides much better deployment control using JAR, WAR and EAR as well.

5) Right Once Run Anywhere

Java uses byte code to achieve platform independence, JavaScript directly runs on browser, but code written in JavaScript is subject to browser compatibility issue i.e. certain code which work in Mozilla Firefox, may not work in Internet Explorer 7 or 8. This is because of browse based implementation of JavaScript. This was really bad until jQuery comes. Its a JavaScript library which helps to free web developers from this browser compatibility issues. This is why I prefer to write code using jQuery rather than using plain old JavaScript code, even if its as simple as calling getElementById() or getElementByName() methods to retrieve DOM elements.

7) Block vs Function based Scoping

Java mainly uses block based scoping i.e. a variable goes out of scope as soon as control comes out of the block, unless until its not a instance or class variable. On the other hand JavaScript mainly uses function based scoping, a variable is accessible in the function they are declared. If you have a global variable and local variable with same name, local will take precedence in JavaScript.

8) Constructors

Java has concept of constructors, which has some special properties e.g. constructor chaining and ensuring that super class constructor runs before sub class, on the other hand JavaScript constructors are just another function. There is no special rules for constructors in JavaScript e.g. they cannot have return type or their name must be same as class.

9) NullPointerException

JavaScript is much more forgiving than Java, you don't have NullPointerException in JavaScript, your variable can accept different kinds of data because of JavaScript is dynamically typed language.

10) Applicability

Last but not the least, JavaScript has it's own space, sitting cozy along with HTML and CSS in Web development, while Java is everywhere. Though both has good number of open source libraries to kick start development, but jQuery has certainly brings JavaScript on fore front.

That's all on difference between Java and JavaScript language. As I said, they are totally different language, one is a general purpose programming language, while other is scripting language for HTML. Though you can do lot of fancy stuffs using JavaScript, you still don't have features like multithreading, as compared to Java. By the way JavaScript was originally named as Livescrpit, may be due to the fact that it makes your HTML pages live, and programming world would certainly be free of this confusion, had Netscape hadn't renamed LiveScript as JavaScript.