The "Free", "Standard", "Open" Software Heresy
The "Free", "Standard", "Open" Software Heresy
Join the DZone community and get the full member experience.Join For Free
With the influx of DevOps-related products and services on the market, today’s application delivery toolchain has become complex and fragmented. Watch Avoiding the DevOps Tax to learn best practices for integration and automation to realize a faster DevOps lifecycle.
There are those people that have a strong, dogmatic belief in what they call “Free” or “Standard” or “Open” software. One of those individuals is Jimmie (let’s call him Jimmie in this article) who has responded to an article aboutJava persistence by Marco Behler on TheServerSide.
Let me cite Jimmie’s response here:
JPA is difficult but complete. It has a learning curve, and you’ll have surprises if you try to shortcut its complexities. But they mostly are there for a reason. Difficult stuff is difficult using JPA, that’s true.
JOOQ is quick to learn. And is proprietary stuff. Not free. Only one implementation. No public review, only one body involved in its evolution. SQL-oriented, not OO (ok, they say it’s a feature).
As a serious professional, learn JPA. Fully. There is no excuse for not knowing which sql queries are generated in your production app. Replacing it with a more basic framework is no solution.
Let’s not go deeply into the concrete difference between JPA and jOOQ / SQL. That topic has been discussed already in lengths on Reddit. Let’s consider the essence of the comparison as perceived by Jimmie. Because, Jimmie would probably say exactly the same thing when comparing
- JSF with Ext.JS or ZK
- PostgreSQL with Oracle
- MS Office or Google Docs (probably OK cause “gratis”) with LibreOffice
- Linux with Windows or MacOSX (although he might perform somedoublethink as a Mac user)
Software not being free
Jimmie, Is YOUR software free and “not proprietary”? If so, how do you finance it? How do you earn a living? And why are you doing it? What reallymotivates you? What really motivates your customers and why?
Only one implementation
How many people actually do use alternatives to Hibernate and why? Are they using EclipseLink mainly because they used to use TopLink for the last 20 years and the learning curve (or benefit) to switch to Hibernate is too high? How often do you actually switch implementations? What keeps you from implementing the jOOQ API, and open-source its implementation?
And most importantly: Do you always adhere to the JPA API, even if Hibernate has lots of awesome, proprietary extensions that just happen to work so much better / easier?
No public review
Who exactly is “public”, and what are their main interests? Did you know that one of the major driving force for the JDK is Credit Suisse, being a large customer for Oracle in the Java environment, for instance? What is your stake and relation with Credit Suisse as your “public” representative?
Only one body involved in its evolution
Do you say that to YOUR customers also, about your own software as well?
SQL-oriented vs “a serious professional”
What’s not serious about SQL? In fact, SQL is reviewed by more entities than the JLS, let alone the JPA specs. Have you ever thought about that?
Fair enough. But don’t forget: You probably replaced your sophisticated EJB 2.0 framework (still a standard!) from the early 2000’s by a more basic one, which was (at the time) proprietary, had only one implementation, had no public review, nor multiple bodies involved in its evolution. It was, at the time, called Hibernate. And let me take the opportunity to cite Gavin King (creator of Hibernate) about when to use Hibernate:
My reply to you, Jimmie
According to you, JPA has to be learned fully. So I challenge you to also FULLY learn SQL, including all the SQL:2011 clauses, including
- window functions
- grouping sets
- common table expressions
- distinct/match/type/submultiset/unique predicates
- time periods
- partitioned outer joins
- lateral joins
- standard OFFSET pagination
- contextually typed value specifications
- quantified comparison predicates
… and of course all the details of interoperation between SQL and XQuery, one of the most popular aspects of the SQL:2011 standard!
And please, learn this FULLY, regardless of whether these things are part of your specific implementation. Because as a serious professional, you shall fully learn SQL. And while you’re at that, learn also everything about execution plans, and join, fetch, buffer caching, cursor caching and all other sorts of algorithms. Because there is no excuse for not knowing which SQL transformations are generated by your database’s CBO.
I know you like standards, Jimmie. But beware of the fact that there are some people out there who cannot wait for a standard to evolve to solvetheir problems. They may have more immediate problems. More specific problems. Simpler problems. Problems that might be solved only by proprietary software, so far. Or problems that are solved by proprietary software, that can be put into production with much less effort than your standards, Jimmie.
Lower time-to-market is what your customer might consider “professional”. Not whether this or that tech is used.
Someone always invents something proprietary at some time. It might just evolve into a standard. It might have been a bad idea and not evolve into anything. Or it might evolve into a standard and then be the worst standard ever. See again: EJB 2.0. I think we all agree on that, today.
No, Jimmie, the world isn’t black and white. It isn’t just about standards vs. proprietary. About free (libre) vs. commercial. About free (gratis) vs. “closed”. It’s about creating value for your customer.
Oh, and Jimmie. I sincerely hope you’re neither a Windows, nor a Mac user, because that wouldn’t be free, and there is only one implementation of each OS, and no public review, and only one body involved in their evolutions. And yet, the whole world runs on one of them.
Thanks for your attention, Jimmie.
Published at DZone with permission of Lukas Eder , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.