Thursday, April 14, 2016

The Innowhere's World For Sale

For many years I've been working on personal open source with the exception of JNIEasy still commercial, this project is pending to be made open source, but currently I have no time and makes me angry to throw to the dust interesting C++ code for license management (for instance Java-like code calling Java from C++). is the port to my personal world. Innowhere is the name of my company, the umbrella to cover my personal stuff to make some business when possible (JNIEasy was commercial, ItsNat was licensed trying to make money with commercial licensing).

I'm proud to say that most of the software done by me through Innowhere from the beginning is innovative and unique or I think so, using unique approaches to problems that developers (mainly Java/Web/Android)  have any day. My motivation has been to make unique products in spite of the idea behind is usually obvious.

Yes, it is surprising how many obvious ideas are not executed in the software world. For instance RelProxy makes use of the Java compiler API ever present in any servlet application just to recompile changed classes, ItsNat name is "Natural AJAX" because the server rendering is also web tech, DOM manipulation in server using Java (or the JVM lang you like more) generating JavaScript code to keep in sync the client side (yes you have stateful and stateless options), instead of the weird, and alien approaches of most of the web templating tools.

The current times are hard for me, my productivity is too low to bring my preferred tools to a higher level, technically and related to marketing (better home web site, using ItsNat of course like the current site, better documentation, more pretty examples). ItsNat Web and ItsNat droid could achieve more power and get more adoption and be the foundation of new products (ItsNat iOS?), similar to the good job of Vaadin people, following the Vaadin example, Vaadin is great for web apps (ItsNat could also compete in this area) but not good for public web sites.

In case of ItsNat Droid Android Client SDK, my preferred child where I'm working hard now (as far I can), is getting a good level of maturity (in spite of there are many things to do and things I'm not able to figure out). Unfortunately ItsNat Droid client SDK needs ItsNat Server (for Web and for Droid) to be also improved accordingly (for instance server side Droid components beyond DOM).

ItsNat Droid is in some way very similar to ItsNat Server Web, ItsNat Web delivers by HTTP remotely HTML pages, CSS and JavaScript to a web browser, ItsNat Server Droid (ItsNat Server Web and Droid are the same, ItsNat Server) also delivers, by HTTP, remotely "pages" based on native Android layouts and associated resources like drawables, animations, menus also remote, also Beanshell for scripting with an excellent integration with Android native API.

If you don't be able to figure out some use of ItsNat Droid, you doesn't actually now the problem of Android development and the different types of services/applications of the mobile world (there are enormous differences between a game an the shop app of Amazon).

If you are able to figure out some use of ItsNat Droid, maybe you could discover how it could radically change how app development is done in case of certain types of Android client/server applications and keep using the mature world of UI and services of Android. I'm sure many concrete "persons" would be excited when they could see what ItsNat Droid is already able to do and how much is promising.Unfortunately these persons are "too long" for me because they are "living" in Google, Apple, RedHat, Microsoft, Xamarin, Sencha, Appcelerator, Qt, Vaadin...  

I would like to sell the Intelectual Property of Innowhere, my software, I could keep contributing as much I can FOR FREE.

Innowhere Software Services S.L. (  is a Spanish company, I own the 50% and my partner holds the other 50%, the company is still alive but with no commercial activity.


Sunday, April 10, 2016

Mi primer Anuncio/Spam: El mundo Innowhere está en venta

Durante muchos años he trabajado en proyectos open source salvo uno que todavía sigue siendo comercial y que no hago open source por falta de tiempo y en parte por rabia de tener que tirar interesante código específico para gestionar licencias comerciales (tal y como una especie de Java en C++). es la entrada a mi mundo.

Me siento orgulloso de decir que la mayoría del software no privado que he hecho durante estos años es innovador y hasta cierto punto aportando soluciones y enfoques únicos a problemas que el programador Java/Web/Android tiene en su vida diaria. Mi motivación siempre ha sido hacer productos únicos aunque la idea que tenga detrás sea bastante obvia.

Es sorprendente como muchas ideas obvias no se hacen realidad en el mundo del software, RelProxy, ItsNat Web e ItsNat Droid son ejemplos de obviedades nunca exploradas por otros.

Por circunstancias diversas me resulta muy difícil llegar mucho más lejos, especialmente en el terreno del "marketing". Se que alguno de mis productos, especialmente ItsNat Web e ItsNat Droid podrían llegar muuucho más lejos si recibieran el apoyo que necesitan y ser el germen de algún otro nuevo (¿ItsNat iOS?).

En el caso de ItsNat Droid Android, mi niño bonito actualmente, está llegando a un buen nivel de madurez, pero por desgracia su aceptación estará muy ligada a la aceptación de ItsNat Droid Server que en la práctica es apostar por la idea original, ItsNat como framework web server centric (ItsNat Web). ItsNat Droid en cierto modo es ItsNat Web en donde el browser es un navegador diseñado para navegar a través de "páginas" basadas en layouts Android nativos remotos así como la gestión de los recursos asociados tal y como drawables, animaciones, menues etc todos ellos también remotos.

Si no se te ocurre ningún uso de ItsNat Droid es que realmente no conoces la problemática del desarrollo Android y los diferentes tipos de servicios/aplicaciones del mundo móvil (hay un mundo de diferencias entre un juego y la app de la tienda de Amazón).

Si se te ocurre algún uso quizás descubras que podría cambiar radicalmente como se enfoca el desarrollo Android para ciertos tipos de aplicaciones Android cliente/servidor sin renunciar al universo Android nativo. Dicho de forma muy vulgar, estoy seguro que hay "personas" concretas a las que se les "caerían las bragas" si descubrieran lo que ItsNat Droid es ya capaz de hacer y su potencial, esas "personas" están muy lejos de mi alcance (Google, Apple, RedHat, Microsoft, Xamarin, Sencha, Appcelerator, Qt, Vaadin...)

Me interesaría vender la propiedad intelectual de todo mi mundo software creado a través de, yo podría seguir colaborando en la medida de mis posibilidades, incluso de forma gratuita.

Innowhere Software Services S.L. ( es un empresa española de la que poseo el 50% (el otro 50% es de mi pareja) que sigue viva legalmente aunque sin actividad.


Wednesday, January 27, 2016

Java vs Node/JavaScript, Mind Storm

I just watched in YouTube an interesting discussion of Java and Node supporters, the videos are in Spanish here and here. This subject is not indifferent to me. Soon my brain started to generate ideas, past facts, even traumatic experiences.

This article is an explosion of not ordered ideas about Java, Node, JavaScript, explicitly typed and weak typed languages.

The root of evil, origins of JavaScript

In spite of  I was very young, I lived the birth of JavaScript. The W3C page about this historic fact is really scary.

JavaScript, not to be confused with Java, was created in 10 days in May 1995 by Brendan Eich, then working at Netscape

I don't remember the first release of Netscape browser with JavaScript, but I remember the reasons of JS introduction:
  1. Provide a simple scripting language "inspired on" Java to control embedded Java applets in web pages.
  2. A simple scripting language to control forms. 

Later the public DOM representation of the page (partial initially), visible for JavaScript was introduced by Netscape, to provide some support of page changes driven by user actions beyond forms.

As you can see the initial motivation WAS NOT TO create a complete and powerful language to develop WEB CLIENT APPLICATIONS.

The JavaScript creators just were thinking on minor form manipulation (validations and similar), color changes and some texts added to the web page on user demand, no more than 100 lines of code (is an example).

Of course developers are ambitious, they want more and more, browsers could be more sophisticated and JavaScript could be improved... And yes it happened UNTIL Microsoft DESTROYED Netscape both the product and the company, MS Internet Explorer 5 won the browser war. Microsoft released later MSIE 6 AND FROZE the web technology for MANY years, being the browser the facto with no competition because the Netscape 4 (the loser) was a crap, with an enormous technical dept, the code was finally open sourced and the Mozilla Foundation was created to build the new generation of W3C compliant browsers (almost no code of the old Netscape was reused).

This reinvention took many years, meanwhile the absolute success of Windows XP + MSIE 6 and the lack of innovation of Microsoft in the web area, stalled the web technology including JavaScript, for many years, until Mozilla suite first, FireFox later, started to be popular (you know the rest of history). Today MSIE 8 (not very different to MSIE 6) still has a significative user market (yes really) and is probable this market share is greater in companies.

The browsers have been improved rendering pages and executing JS code, but JavaScript, the language, is mainly the same thanks to Microsoft.

JavaScript is as is as the result of lack of innovation, there is no "trascendental reason", there is no "deep thinking" about how to make a good language good enough for a long future, for instance the "prototype" feature just was a quick idea to create a mediocre object system, a mediocre version of Java and OOP , but good enough for a scripting language of  the past.

The monothread asynchronous programming is more performant than a thread based

Sure you have read A LOT OF TIMES how bad and costly is thread context switching and how good is mono-thread programming delegating blocking operations to a thread pool (yes again a thread pool, the dark secret of Node).

But the real facts do not agree, take a look Paul Tyma experiments, my own insights or the famous Tech Empower benchmarks, take a look how the venerable raw Java servlet blocking threads in I/O is performing, and the position of async I/O Java alternatives, of course Node is even in a lower position.

Java is tedious and verbose. Is programming with JavaScript quicker? 

It depends, if you are doing a very simple web application with Node, yes you are going to deliver some result before Java developers, but when the code becomes bigger and bigger the missing types are more a problem for productivity than an advantage.

The optional generics Java type system is not an evil invent to make the life of Java developers more sad, is a tool to make your code more robust, the verbosity cost is backed with a better code, any Java developer understands that "List<User> hello" is a list of User (readability) and only can contain User objects (robust) in spite of the stupid variable name, is it bad?

Can you make big web applications in Node? Yes of course, everything is possible with effort and discipline (in weak typed languages the discipline must be "military" even more strict than a explicitly typed one), but in the long term a dynamic weak typed language becomes a nightmare in projects with a lot of code, even in projects with a single developer (is my experience).

The problem of argumentation based on inferiority complex

I remember the times when Java was invented and was becoming more and more popular, Java was initially a C++ simplification, many C++ developers received Java with some skepticism. To win more Java developers from C++, Java supporters praised the "simplification" as a feature. For instance, the Java class system lacked the powerful templating system of C++, "you don't need it, everything is more simple in Java", this kind of argumentation trying to convert the inferiority in an advantage is unfair and a bad trick but it usually works. Years later Java 1.5 introduced generics, yes conceptually similar to the venerable C++ templates.

This is an example of the art of converting the limitation on feature, in spite of I'm a Java guy for many years (and a C++ guy before), Java marketing was not honest.

A Node instance has only one working thread, no concurrency problems, on the other hand, end developers are forced to execute ALL business logic of ALL concurrent users in the same single thread. This introduce a severe limitation, the problem of "CPU bound applications", your logic business must be very simple and quick otherwise all users will be stalled.

Related to the previous limitation, do you know the anecdote "Why npm's progress bar slows down install time by ~20%".  The explanation is simple, the progress bar updating is time consuming and is executed in the main thread instead of starting a new thread. I'm sure it will be fixed maybe executing the log operation in an extension coded in C/C++ in a different thread or similar. This makes me think, are we in 1970? Are we coding on Windows 3.1/95 (the later with a crappy not preemptive thread system)?

In practice any Node application is multithread because blocking I/O operations are executed through a thread pool, whether the thread context switching is time costly, Node has the SAME problem that a thread per request pool.

Node is trying to sell us how good is lacking thread programming, "the missing feature is the best feature". Something similar happens in JavaScript space, the inherent lack of features to structure code (that is the lack of decent OOP support) is sold as "freedom" and simplification.

JavaScript is mediocre, period (ES6 is a step forward, it would be even better whether types were optional like in Dart). Do you like JavaScript/Node? Right, but formally is a mediocre language, hard to defend out side of the browser, Java is by far superior.

Is Java the best language OOP/functional of the world? Of course is NOT, in the OOP space I'm sure most people agree with me that Scala, Kotlin, Ceylon, typed Groovy or C# are SUPERIOR languages, no problem, and in no way is the best functional language.

"The language is not important, the developer is"

Yes, you are heard/read this polite phrase often, and yes, a good developer can be good in ANY language... BUT...
  • A good surgeon is a good surgeon in a shelter tent and in a conventional operating room of a modern hospital. Try to ask him/her what is the best place for surgery...
  • Can you do surgery with a kitchen knife? Yes you can but I'm sure you prefer a scalpel.
  • Do you think a veterinary surgeon is appropriated to do surgery to humans?

The myth of complexity of concurrence management in "conventional" request-thread web apps

This is a very bad argument, a very big percentage of conventional web apps have NO problem with thread concurrency because, in most of them all of the code is single thread because they have no need of dealing with other parallel requests (threads), the database is in practice the synchronization point, al decent RDBMS ensure consistency in column writes and if you need a more sophisticated synchronization you have transactions.

Node, JavaScript and foundation libraries

Java is not only the language, a large library is part of the Java platform, it doesn't prevent smart developers to pick alternatives (for instance Guava, Apache HttpClient, Apache Commons etc).

The same does not apply to Node, something so basic as a decent collection system (beyond the crazy native arrays of JavaScript) must be externally downloaded.

An explicit type system is not only to reduce the number of tests

Yes you know how useful is a good type system, if you do something wrong usually some other place is broken and the compiler advises you with no need of executing tests.

However an explicit type system provides more very important benefits:
  • Readability: read the code of a Java class from a decent open source product, I'm sure you're going to understand the function of the class just reading the types.
  • Robust code: MyClass obj only can reference MyClass objects or inherited from, List<MyClass> list is a list and only can contain objects of MyClass or inherited (a final class is also possible).
  • Reliable code navigation: any decent Java IDE offers a "Find Usages" ("References" in Eclipse) feature, if you use this feature selecting "any" element of your code, the IDE is going to show with precision all uses of this element (an attribute, param, local variable, method, constructor, class name etc).
  • Reliable code refactoring: any decent Java IDE offers many options for easy and secure refactoring for instance name changing (the simpler case, IDEs offer more complex refactoring options). Brutal refactorings can be performed with almost no risk.

Paradigms, paradigms, paradigms

In the end of the day the important characteristic of your preferred language is the paradigms supported, for instance, structured (ex. C), OOP, OOP+functional (Java, Scala...), pure functional (Lisp, Haskell, Closure...).

In Node/JS you can do OOP, but the approach is tedious and cumbersome.

I suspect in practice OOP is not mainstream in JavaScript, maybe "objects", I suspect mainstream JavaScript code is like a C with functions capturing context vars, or something similar to VisualBasic 6 pre .Net (had classes but not inheritance and polymorphism).

I'm not kidding, take a look this C like code of Mozilla based products (for instance FireFox).

The myth of inheritance abuse

Some people say that "people" usually abuse using inheritance, one reason for bashing OOP (the typical all or nothing argument, bad argument in my opinion).

I don't agree, in the real world is the contrary, many people inherits ONLY when there is no other option (when the API being used provides an abstract class or interface to implement) but rarely you are seeing fully user defined inheritance trees not forced by the frameworks. Of course this is personal vision and isn't scientifically backed.

Many people ignore how to model a class system including inheritance, encapsulation and polymorphism when appropriated, others maybe because are following the mantra of some "gurus" saying "the inheritance is bad".

A long time ago was OOP became popular many people abuse of inheritance trying to fit too many things in the same class tree, for instance a class User inherited with visual code, persistent code, networking etc. Fortunately that time is gone, however some people today invites to back to this old crazy approach because they don't like the modern layering/services approaches (and usually is the same people saying the inheritance is bad).

Fortunately good OOP developers use the inheritance (the complete OOP features in general) when needed.

Are you able to figure out?

  • A Big Data tool made in Node.js
Hadoop, HBase, Spark, Storm, Kafka, Cassandra, Kubernetes, docker? Most of Big Data tools are made in Java or a similar JVM lang (docker and Kubernetes are Go).
  • Replacing Java Android core on top of C++ by Node.js
Maybe really a good idea? I remember years ago the filtered statement of a Google executive about the language on Android something like "Java is the only option, any else is crap" (modern JVM statically typed langs were not created yet).
  • A desktop application in Node.js 
FireFox, Thunderbird etc do not apply because most of the code is C++, the JavaScript/HTML/XUL is the external layer. In case of Java just see the three main IDEs: NetBeans, Eclipse e IntelliJ (Visual Studio as far I know is C++ and .Net).

Has Node.js a reasonable place in the World?

Yes course, Node is useful for conventional web sites with small and relatively simple business code.

Oh yes some important parts of PayPal are built with Node, almost the public web site, Right, OK, however PayPal is a relatively easy service, yes really, PayPal is far far away of the enormous complexity of the Google, Amazon or Apple ecosystems. I remember the article about the "competition" of the options, Java and Node, for replacing the old C++ based tech of PayPal, I'm sure you know Node won.

In my opinion is quicker to make a simple spaghetti than a solid Java version, and as far I remember the Java developers tried to include every Java framework invented in SpringSource and GitHub (the competition was to make a quick prototype of a service, not a production service) and imported also the kitchen sink. Yes Node is fine in the short term, the LONG term is different... remember the case of Twitter and Ruby, I respect Ruby, Twitter is as is thanks to the flexibility of Ruby in the beginning before becoming the current monster, by the way, today based mainly on Java.


No, this is not the end, stay tuned for the next entry about Java and JavaScript, much more personal....


Monday, January 11, 2016

Why Useful TDD is a Unicorn

Some description of the scene

First of all we must explain what is TDD, TDD = Test Driven Design, that is the design is driven by tests, only the design can be driven by tests if the tests are coded FIRST, that is BEFORE THE IMPLEMENTATION DETAILS.

Obviously the method or methods to test must be coded first, in theory with a simple and minimal implementation just to compile (in compiled languages of course) and run to make the test fail.

When I talk about TDD I want to underline the primary concept, TEST CODE IS FIRST CODED. Underlining this is absolutely necessary because many people think TDD = TESTING. Many articles about TDD are just articles about testing, and many praises to TDD are in practice praises to testing "in general", and when TDD is criticized or questioned, automatically is translated as a rant against TESTING. The need of testing is so old as software development.

In this article I'm going to talk about what I think about TDD, I'm no longer a young guy and fortunately I'm a not "consulting seller" and I'm not forced to public defend something I don't "believe", this is hard in a software world/industry plenty of people anxious to be "trendy" that we could name the "me too syndrome".

In this context is very hard to "contradict" the "industry", the industry is EVER trying to sell unicorns as real stuff, in my opinion TDD is one of these unicorns, many (most of?) people say "I've got TDD, I use TDD to make software, TDD is great". The problem of TDD is like teen sex, everybody talk a lot but in practice...

This article is brief, I've no interest on TDD ranting, TDD want to be a honest effort to make software better and predictable, there are a lot of articles about how great TDD is and of course some rants. This is just my vision.

Is TDD possible? The TDD paradox

Yes OF COURSE TDD is possible, the problem is in the details.

Someone has said you is doing TDD? Don't believe a word until you see him/her coding.

My thesis is simple, TDD is possible of course but only in trivial code!!! USEFUL TDD IS NEAR IMPOSSIBLE OR AN ABSURD WASTE OF TIME!!

Yes this provocative conclusion is presented first to make the explanation more expected :)

Try to remember how many articles introducing TDD you have read, yes most of them are trivial examples, the implementation code is so simple that most of the implementation must be written before the test because otherwise is not possible to execute any test.

Take a look to the Java code of this example, the article teaches you to avoid testing each method, instead invite you to test behaviors... Behaviors? What behaviors? The example is so extremely simple that is hard to find a "behavior" use case.

Do you remember the "revolutionary" Ian Cooper's talk TDD: Where Did It All Go Wrong?

The key phrases:

Avoid testing implementation details, test behaviors

– A test-case per class approach fails to capture the ethos for TDD. Adding a new class is not the trigger for writing tests. The trigger is implementing a requirement.

– Test outside-in, (though I would recommend using ports and adapters and making the ‘outside’ the port), writing tests to cover then use cases (scenarios, examples, GWTs etc.)

– Only writing tests to cover the implementation details when you need to better understand the refactoring of the simple implementation we start with.

Ian invites to avoid the classical typical low level testing apparently accepted by everybody for TDD (test any class, test any method). The rationale is simple, the less level, the more trivial code we are testing, the less level, the less value of the test. Consequently the number of tests are extremely high and in the same time the value of tests is extremely low, a lot of work for near nothing back.

OK we accept we must practice TDD (remember, test-first before implementation details) with behaviors. A "behavior" beyond a simple class or method implies in OOP a class system design,  that is, several top level classes collaborate to get a result or action (unless you are coding a kind of StringCalculator parser), ignoring the necessary internal classes (implementation details). Identifying the top level classes is not a trivial task, it involves trial and error, redesign, external API conceptualization...

In the best case you are going to get a bunch of main near empty top level classes and corresponding public methods, THEN perhaps you are ready to start to code tests (obviously red tests in TDD). When implementing the details frequently you are going to kick your head against the wall of the premature API optimism, the implementation details usually influences the public API of the module we are developing (the industry knows a lot about the problem of defining APIs in papers), because unless you have a clear pre-designed public external API for end users imposed as requisite, your API must be designed up to front and you must predefine the scope if you want really practice TDD.

The result is several iterations of implementation/refactorization coding and API changes until a final API is stable enough, meanwhile your first ambitious "test first" code in practice is just a draft being absurdly modified again and again and again... Are we really doing Test Driven Design? Really? Is worth the test first obsession? Is up to you but perhaps this is the time to think the sense of the hype:



Tuesday, July 7, 2015

Native Mobile vs Hybrid Mobile = ItsNat Droid

The eternal question, what or when is better? Native Mobile ? Hybrid Mobile ?

I have some very personal opinions, not sure to be "universal arguments".

Go on:

  • Language

    • Native Mobile:  built using "serious langs" like Swift (iOS) or Java (Android). Serious means: statically typed, good OOP and speed.
    • Hybrid Mobile: based on the horrible JavaScript (weak types, bad OOP, not so quick than native langs), unfortunately if your application UI is sophisticated you must be ready to tons of clumsy JS. In pure Web you have GWT, Dart... to generate JS, in mobile web I suppose is a lot of harder to avoid JS.

  • UI fidelity to platform

    • Native Mobile: ready in your hands. Just using the default native components you get a perfect native UI look and feel.
    • Hybrid Mobile: you must use a mobile toolkit simulating native UIs and make two visual versions (iOS/Android) of parts of your app.

  • Access to the native API

    • Native Mobile: direct and unlimited access (only security restrictions of the app are applied).
    • Hybrid Mobile: you must use a mobile toolkit because native access from JavaScript is not unlimited, for instance in Android the native (Java) methods to be called by JS code must be defined in a interface, this is the job of the mobile toolkit API. If you need a stronger integration be ready to program in native Java. In fact the term "hybrid" is used because many hybrid applications are really hybrid native-web, that is, some architectural elements are native (menues etc) and other parts web rendered. Some things are very annoying like the necessary asynchronous calling between JS and native code (for instance, in Android the JS code is executed in an exclusive thread different to the main thread).

  • Development Performance

Maybe this is the most opinionated item of this analysis.

In my opinion native development is by far more productive than hybrid thanks to the language, the tools, the natural native integration... Yes, you must make two (iOS/Android) apps, usually two teams. The performance of both teams surpasses in quality and development performance to the "one hybrid team". Some things can be reused like data management using a Java-Objective C generation tool like Google does. I recognize that if you need to support Windows Mobile the advantage is not so great.

  • Debugging/Testing

    • Native Mobile: native tools are fine enough.
    • Hybrid Mobile: debugging tools have been improved but not in the same level than native.

  • Version management

In this subject we must differentiate between two types of hybrid applications:

  1. Behavior/UI (HTML/JS) is mainly local. In essence the hybrid app is self-contained and is not different to a native app.
  2. Behavior/UI is mainly remotely delivered. In essence the hybrid app is like a mobile web site packaged into a native app.

If your application is type 2 you are lucky, version management is by far easier than a native app, in a native app minor UI changes and behavior requires a new release and you must keep back compatibility with old versions because upgrading is a task of the end user. This is where hybrid development can shine.

I suspect Amazon Shop apps are of this type 2:

"the most compelling reason to incorporate HTML5 into your mobile applications is to get the ability to update the app without requiring an upgrade on the device user's side. This capability makes it both easier and safer to manage apps -- permitting developers to roll out or draw back updates as needed. In the brave new world of continuous deployment and live testing, that's a huge advantage"

And by the way, this type 2 is the reason of ItsNat Droid development.

ItsNat Droid: native UI (and some behavior) delivered remotely.


Wednesday, June 17, 2015

My pseudo psycho analysis of the "three types of developers" regarding tech adoption

I'm usually obsessed about what type of developer I am, a pioneer adopting tech? conservative? a creative/seller of my own software? The answer is more complex.

This reflection is the result of reading this article at DZone, it was first a comment, but WTF! I HAVE A BLOG AT LAST!

There are three kind of people in software development regarding tech adoption:

1) People obsessed looking for the newest and coolest technology

2) More conservative/skeptical people (usually experienced developers and/or with some "bad experiences")

3) People interested on promoting some concrete tech (people with an agenda)

This is a pseudo naive psycho analysis:

1) People obsessed looking for the newest and coolest technology

They are proud of being "pioneers" and early adopters, sometimes they are good enough to make anything in any kind of tech including not mature or simply wrong tech, but sometimes he/she will ruin your project because the motivation is usually too ego-centric and project "needs" and using proven stuff are not the priority.

The problem with this people is their pervasive promotion of unproven or wrong tech, and ready to "believe on any new thing".

I remember people proud of "using Java from 1.0", when I read this I feel a shake. Java was A GREAT INVENT, Java avoided Microsoft as the absolute dominant player in software industry (Java was born when Microsoft was near to becoming a brutal monopoly in anything, Java "saved" the industry, just ask to old Oracle, Sun, IBM guys...). In the same time Java 1.0 was really mediocre in the alpha category (1.1 was the first decent release)...

Apply to any new cool tech of today...

2) More conservative/skeptical people

There are several sub-types:

- Lazy people unable to learn something new

- Conservative people very resilient to change (fear driven)

- Skeptical people: aged developers who have seen too much tech "died" (C++ decline, XML and Object databases, CORBA, SOAP, native desktop development, RUP...) tired of listening "world savers", "everything will be" and "silver bullets" again and again.

3) People interested on promoting some concrete tech (people with an agenda)

In practice they are "Bible sellers" where everything is a "success case", their points and arguments can be valid but they are biased... Sometimes the tech "sold" becomes very good and get some success (or great success) with time but ever even in alpha state is sold as the best stuff after the sliced bread invention. Sometimes the merit of the tech is obtained just by "mantra repetition" (frequent repetition of "X is good" becomes "X is good") and "hiding information", and inviting to imitation to avoid "IT shame" (we are cool are you cool?)

----------------- My point of view:

I recognize I'm a mix of three :)

1) People obsessed looking for the newest and coolest technology

This kind of people must exist for promoting innovation. Sometimes there are really exciting new tech around the corner "yes at last".

In my case I've tried to create this kind of disruptive tech for this kind of pioneers early adopters, most of the time I've failed but I still have some hope .

Yes I'm in1)

2) More conservative/skeptical people

This kind of people must exist to provide a rational point of view. For instance to resist to use DBs with almost no warranty for critical data, to avoid applying tech and approaches only worth and valid for very big companies, to resist to use alpha tech in mission critical apps...

For instance, I've read THOUSANDS of times how much bad is sync IO and thread scheduling and how performant is async IO processing, but data is not usually aligned to speeches.

Yes I'm in 2)

3) People interested on promoting some concrete tech (people with an agenda)

Yes they are biased, sometimes they will revolutionize the industry, sometimes is just a temporally marketing success, in any case they try "to convert you and to spread the WORD".

This kind of people must exist to create exciting new tech, for instance Sun, Oracle, IBM... survived thanks to Java invention. Yes they want to make money and it is not bad, is up to you what is your role (follower?, fanatic?, ingenuous re-seller?, a satisfied user/customer?).

Yes I'm in 3) I create and promote open source software, sometime ago I tried to make a living, now is mainly pleasure driven.

And you?


Friday, March 13, 2015

JEPLayer, Java 8 and jOOQ a Match Made in Swiss Heaven

Note: this blog entry is a tutorial of JEPLayer, is alive and has been updated to JEPLayer v1.3, ignore the date of this blog entry.

Last update: 2015-6-3


Sometime ago I promised to Lukas Eder to make some example using JEPLayer and jOOQ, Lukas is the main author of such nice and powerful RDBMS Java toolset. A promise is a duty!


This blog entry is a tutorial of how we can use jOOQ runtime SQL generation with the ORM API of JEPLayer. jOOQ is a complete ORM, JEPLayer is also an ORM, they provide two different point of view of solving the Object-Relational problem in a Java environment.

JEPLayer is a non-intrusive approach to persistence of pure POJOs, a lightweight alternative to more intrusive and "magic" approaches like JPA implementations. JEPLayer tries to simplify to extreme the JDBC lifecycle hiding the JDBC API, but through listeners we can optionally access to the underlying pure JDBC layer avoiding as much as possible the API repetition of JDBC in JEPLayer. JEPLayer has a special focus on managing JDBC and JTA transactions.

In spite of JEPLayer ORM capabilities, a powerful SQL syntax modeled by Java objects is missing in JEPLayer (instead of plain text), jOOQ SQL modeling in Java is probably the most complete in the world. jOOQ is a perfect match for JEPLayer to write robust, error-free, refactoring friendly SQL code based on Java.

JEPLayer v1.3 introduces automatic implicit SQL generation for INSERT, UPDATE and DELETE actions, no explicit SQL is needed, anyway jOOQ SQL in Java is still invaluable for SELECT queries where complexity can be cumbersome and error prone.

In this tutorial the use of jOOQ is brief, SQL examples are very simple, SQL management of jOOQ is much more powerful than shown here.

The other new kid on the block is Java 8 (Java 1.8 specification), specially interesting for JEPLayer are streams and lambdas. JEPLayer is designed using a fluid API customized with listeners most of them based on a single method, perfect to get code simplified using lambdas, in the same time, JEPLayer returns "alive" result sets based on List (and ListIterator) interfaces, and as you know a List can be easily converted to a stream in Java 8 for some type of processing. The code of this tutorial could be even less verbose when using lambdas, but some extra unnecessary variables are exposed to show the name of the interface listener involved, because remember, this is a JEPLayer tutorial (not a Java 8 tutorial).

The first part of this tutorial just show the typical DAO class based on JEPLayer to manage a POJO class (Contact). One important feature of JEPLayer is the absolute respect to the user data model, no annotation, interface or similar artifact is needed in data model, data model is clean and independent from the persistence layer (JEPLayer), only some optional Java bean property conventions are required to easy class and attribute mapping to table and columns.

The second part of this tutorial shows some use examples of persistent actions grouped, most of them using JDBC transactions (no JTA API of JEPLayer is used in this example). Most of the code is repetitive (code similar doing the same) because the motivation is to show the extreme JDBC customization allowed by JEPLayer, especially in transaction management.


The code of this example can be found in:


This example has been coded in NetBeans using Maven, Java 8 JDK, MySQL and the C3PO connection pool. JEPLayer does not mandate a concrete connection pool, just to show a "real world" configuration.

Because there is no custom SQL code, any other RDBMS database could be used with no business code change (just changing data source bootstrap).

OK now show me the code!

No more blah blah. The methodology of this tutorial is simple, let's to show the code first, and later we will explain the details of every code snippet.

The code of this tutorial just have two parts, the DAO class and use examples managing a Contact POJO class and the second part talks about transactions.

We are presenting first the ultra complex Contact class

The DAO class managing Contact objects

Finally the use cases

Let's Explain: initialization

To initialize JEPLayer (non-JTA) we just need a DataSource:

to finally obtain a JEPLNonJTADataSource object, this object wraps the provided DataSource. In fact JEPLayer is basically a set of wrappers on top of JDBC, nothing new, the "new" JEPLayer specific part is you ever have optional access to original JDBC objects when you need some specific configuration and behavior, depending of the phase of the persistent lifecycle, avoiding re-inventing JDBC again and again.

As you can see jOOQ initialization for MySQL is trivial because we are going to use just a subset of its capabilities.

The previous code configures by default the JEPLNonJTADataSource root object to disable transactions using a JEPLConnectionListener, this is the verbose version of jds.setDefaultAutoCommit(true), in fact it is also unnecessary because transactions are disabled by default (later we are going to see many options to execute transactions with no need of enable them by default, in a ideal world all persistent actions must be inside transactions but in practice only changing actions should).

The method createTables() shows how to execute SQL raw code  using a JEPLDAL (DAL=Data Access Layer) object. A JEPLDAL object can be a singleton (the same as JEPLDAO objects in fact this interface inherits from JEPLDAL) and is designed to execute persistent actions when you do not need to convert requested data to POJOs.

Let's see how ContactDAO is initialized:

This constructor creates a JEPLDAO<Contact> object, this object can be a singleton and can be used to manage Contact objects, besides implementing the interface JEPLDAL, JEPLDAO<T> provides methods to manage the persistence of the class T specified, in this case Contact.

The constructor is very verbose to show the options of mapping columns and attributes, the parameter mappingMode decides the approach used for mapping. In this example all approaches are the same, all attributes are mapped to the columns with the same name ignoring case. The first one is enough and the simplest in this case:

The JEPLUpdateDAOListenerDefault when registered will be used to internally generate the SQL code and parameters to execute JEPLDAO<Contact>.insert(Contact obj)/update(Contact obj)/delete(Contact obj) methods.

The JEPLResultSetDAOListenerDefault when registered will be used to create the POJOs mapped to resulting rows when executing DAO queries.

If you need more complex bindings and data transformation use other more specific approach. The JEPLResultSetDAOBeanMapper is interesting when most of them match by default but someone need a custom binding or excluding.

Inserting persistent objects

Insertion example:

This is the insert() method in DAO:

Because we are not going to return Contact objects, this method uses a DAL query.The values "email", "name", "phone" are non-sense values, they are required by jOOQ and will be replaced by ?, if you need to provide inline values use inline("") and similar as parameters (this is jOOQ specific). jOOQ generates parameters with format ? , JEPLayer also allows parameters with :name format to avoid "counting accidents", because of jOOQ they are not shown in this tutorial (see the JEPLayer Manual). Because of insertion we finally call the method getGeneratedKey() calling under the hood the similar JDBC method.

There is another example of insertion, the result is the same but it is defined to show how we can optionally modify how the results are processed (in this case only one row and column, the generated id, is expected):

This specified JEPLResultSetDALListener could be registered on the constructor of ContactDAO (do not confuse with JEPLResultSetDAOListener, is DAL not DAO).

Finally there is a simple DAO sentence for insertion without explicit SQL code and parameters, the JEPLDAO<T>.insert(T obj) method uses under the hood the JEPLUpdateDAOListener<T> registered, this listener provides the column mapping and values to insert.

Alternatively we can use raw SQL code with named or numbered parameters, the code is self explanatory:

Updating persistent objects

Now the code to update:

Nothing to explain, very similar to insertion, again jOOQ in action. In this case we call executeUpdate() returning the number of "rows" involved (one in this case).

Similar to insertion we can use the simple DAO sentence for updating without explicit SQL code and parameters, the JEPLDAO<T>.update(T obj) method uses under the hood the JEPLUpdateDAOListener<T> registered.

Deleting persistent objects

The code to delete one row:

Again the 0 literal value is not used and a ? is generated instead. The call executeUpdate()returns the number of "rows" involved (one in this case).

The same to insertion and update we can use the simple DAO sentence for deleting without explicit SQL code and parameters, the JEPLDAO<T>.delete(T obj) method uses under the hood the JEPLUpdateDAOListener<T> registered.

Query and processing alive/active results

The DAO method getJEPLResultSetDAO():

only can be called inside a Connection got from DataSource, we cannot directly call the same as we execute executeUpdate() because JEPLResultSetDAO holds an active JDBC ResultSet.So we need to wrap the call and data extraction using a JEPLTask.

One shot query

If you know the number of resulting rows or you just want to load an affordable subset of rows, there is no need of using a JEPLResultSetDAO. Instead we call getResultSet() which returns a conventional List<T> (remember you can optionally register a JEPLResultSetDALListener and a mapping listener calling addJEPLListener() before getResultSet()).

The method setMaxResults() is used in this example to limit the number of results.

One shot query, alternative

The method setMaxResults()is enough but to show how much configuration is possible, we are going to show an alternative to do the same registering a JEPLPreparedStatementListener listener to customize the PrepatedStatement used under the hood (we have seen before the same kind of customization of ResultSet). By the way do not worry about threading, a PreparedStatement is bound to a Connection and only one thread can hold a Connection.

Counting rows

Because we expect just one row and a single field, there is a specific method getOneRowFromSingleField().

Select a range

Most of your queries need a range of the results based on a search criteria and order. This is why setFirstResult() and setMaxResults() exist.

Select a range, alternative
If you are an obsessed for control, you can alternatively control how the range is got through JDBC level methods.

Data Access Layer (DAL) level queries

Frequently you want to execute queries returning diverse data beyond model objects, for instance we need the number of columns and the average value of a column of a table in a single query. JEPLayer provides two approaches, using an alive java.sql.ResultSet wrapped by the interface JEPLResultSet and by using a cached result set with the interface JEPLCachedResultSet.

DAL Active Queries

When an alive java.sql.ResultSet wrapped by the interface JEPLResultSet is returned, it is similar to JEPLResultSetDAO, in this case diverse data is returned instead data model objects. Because result iteration requires an alive connection a task is required.

DAL Not Active Queries

When returned a JEPLCachedResultSet, it is similar to the POJO List returned by JEPLDAOQuery<T>.getResultList(), again diverse data is returned instead data model objects. No task is required because a connection is not required for iterating the result, everything is cached into JEPLCachedResultSet.

Transactions, transactions, transactions...

One of the most important features of RDBMS is transactions, more specifically, the implied rollback capability of transactions. The everything or nothing persistence is one of the most important features when evaluating the confidence of a IT system.

JEPLayer is conscious of how important is transactions and how much tedious and error prone is the typical manual demarcation of other DB APIs (I am not talking about jOOQ, which follows a similar approach to JEPLayer). This is why transaction demarcation (begin/commit) is defined by a single user method (nested transactions are possible) and commit is ever implicit when the method normally ends or rollback if some exception is thrown. Later we are going to see how to optionally we can manually demarcate transactions.

JEPLayer provides support to JDBC and JTA transactions, this tutorial only shows JDBC transactions (controlled by the auto-commit JDBC mode). When auto-commit is set to true (the default) every SQL sentence is executed into a built-in transaction according to the guaranties typical of an ACID system. Our interest is when auto-commit is set to false and we need to change several rows by several sentences inside a transaction.

The following examples are ever rollback examples because rollbacking our changes is how we can evaluate if our sentences have been executed into a transactions.

The simplest transaction

In JEPLayer code executed into a transaction is ever wrapped by the only method (exec()) of a JEPLTask. By setting the autoCommit parameter to false we ensure JEPLayer executes the task into a transaction and execute a commit just in the end of the task (or rollback when an exception is thrown).

Transaction by configuring the connection

By using a JEPLConnectionListener we can set auto-commit false in the Connectiongoing to be used in the transaction. JEPLayer executes the task into a transaction.

Transaction by configuring the connection (2)

With a JEPLConnectionListener we can make much more complex things and manual transaction control.

Previous example can be coded in a generic way hiding the JDBC Connection object usingJEPLTransaction instead.

Transaction by annotation

Finally we can specify a task is going to be executed into a transaction specifying @JEPLTransactionalNonJTA.


We have seen how to mix JEPLayer, Java 8 and jOOQ to code true POJO based persistent applications with less verbosity thanks to Java 8 and code less error-prone by using jOOQ.