on jOOQ and modularity
37 views
Skip to first unread message
Garret Wilson
Apr 15, 2014, 5:02:20 PM4/15/14
to jooq...@googlegroups.com
Just five minutes ago I was doing a search to nail down some specific behavior of Java 8's Optional<> class, and I stumbled on a post (without realizing until afterwards that the post itself was from the jOOQ team). On that page, the author bemoans the stalling of JSR 305 (nullable/nonnull annotations) in favor of JSR 303, which is JavaBeans-specific:
I can readily empathize with that author. One of the most fundamental objects of the web, the MIME content type, has various and incompatible implementations, some of them requiring JavaMail, some of them requiring other libraries. We have the same thing with Java's URI class (which blatantly breaks object equality rules, by the way) and Android's Uri. The list goes one. It seems as if the most fundamental objects have been reinvented over and over; nobody ever fixes them once in for all, and forces us to mix-and match.
Enter jOOQ's use of unsigned data types. In a brilliant and useful move, jOOQ decided to split out its unsigned data types implementation into a separate jOOU library and put it on Maven Central so that we all could have a single, well-design, shared, modular way of representing unsigned types.
And then, instead of referencing that library, jOOQ turned around and included the source code into its own library inside a different package.
Wonderful. So now my libraries that don't access the database will use jOOU. My libraries that do use the database will use the redundant version stuck inside of jOOQ. Somehow I'll have to convert between the two. I'll never know if the versions match. And instead of lowering dependencies, I have now increased my dependencies because I'm including essentially the same code twice in my distribution, just because jOOQ tried to throw a monkey wrench into Maven's very nice dependency mechanism.
It's true that the JDK includes some third-party APIs in the JDK itself. The JDK had no choice. It was defining an API to ship with the development kit, and the JDK must be self-contained for its own API. But that argument doesn't apply to third party libraries, which one already has to download from somewhere.
If we're using Maven, then we don't want one of the libraries to try to sabotage the Maven dependency process. If one isn't using Maven, it's simple enough for jOOQ to have a build script that spits out a jooq-all.x.x.x.jar file that has all its dependencies in one place. There is no reason to hard-code these dependencies in the code.
I think jOOQ is awesome. I was overjoyed to find jOOU. But please, no more inconsistency and redundancy through hard-coding of public libraries. More modularity, por favor.
(My apologies for the sarcastic tone of this "article". I meant it in a non-spiteful way, only trying to make a point. Thanks, Lukas and the rest, for all the nice work on jOOQ. No disrespect intended.)
Yes, more inconsistency and redundancy between the various approaches of doing things. Yay ;-)
I can readily empathize with that author. One of the most fundamental objects of the web, the MIME content type, has various and incompatible implementations, some of them requiring JavaMail, some of them requiring other libraries. We have the same thing with Java's URI class (which blatantly breaks object equality rules, by the way) and Android's Uri. The list goes one. It seems as if the most fundamental objects have been reinvented over and over; nobody ever fixes them once in for all, and forces us to mix-and match.
Enter jOOQ's use of unsigned data types. In a brilliant and useful move, jOOQ decided to split out its unsigned data types implementation into a separate jOOU library and put it on Maven Central so that we all could have a single, well-design, shared, modular way of representing unsigned types.
And then, instead of referencing that library, jOOQ turned around and included the source code into its own library inside a different package.
Wonderful. So now my libraries that don't access the database will use jOOU. My libraries that do use the database will use the redundant version stuck inside of jOOQ. Somehow I'll have to convert between the two. I'll never know if the versions match. And instead of lowering dependencies, I have now increased my dependencies because I'm including essentially the same code twice in my distribution, just because jOOQ tried to throw a monkey wrench into Maven's very nice dependency mechanism.
Yes, more inconsistency and redundancy between the various approaches of doing things. Yay ;-)
It's true that the JDK includes some third-party APIs in the JDK itself. The JDK had no choice. It was defining an API to ship with the development kit, and the JDK must be self-contained for its own API. But that argument doesn't apply to third party libraries, which one already has to download from somewhere.
If we're using Maven, then we don't want one of the libraries to try to sabotage the Maven dependency process. If one isn't using Maven, it's simple enough for jOOQ to have a build script that spits out a jooq-all.x.x.x.jar file that has all its dependencies in one place. There is no reason to hard-code these dependencies in the code.
I think jOOQ is awesome. I was overjoyed to find jOOU. But please, no more inconsistency and redundancy through hard-coding of public libraries. More modularity, por favor.
(My apologies for the sarcastic tone of this "article". I meant it in a non-spiteful way, only trying to make a point. Thanks, Lukas and the rest, for all the nice work on jOOQ. No disrespect intended.)
Lukas Eder
Apr 16, 2014, 4:37:01 AM4/16/14
to jooq...@googlegroups.com
Hi Garret,
Thanks for your insisting and for your patience. As already discussed in private messages, we are more than willing to review our general "external dependency strategy" with respect to jOOU (and jOOR, Apache Commons, CSV Parser, JSON Simple, see also [1]). As you've discovered yourself, jOOQ currently internalises all of those dependencies to make using jOOQ out-of-the-box even simpler, e.g. for those users that do not use Maven. This is particularly true for jOOR, Commons, CSV Parser and JSON Simple, which are only used internally by jOOQ. jOOU is different, as generated classes may reference these types.
Your point has been well received and will be considered for the next major release jOOQ 4.0 with issue #3184 [2]. Until then, I hope you will understand that we cannot break semantic versioning, so we cannot address this issue before then.
Best Regards,
Lukas
--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages