
Jodd – The Unbearable Lightness of Java - tilt
http://jodd.org/
======
mooreds
I think there is a huge need for these kind of frameworks. They combine the
convention over configuration productivity and tooling that rails and its
clones provide, while letting users tap into the massive java ecosystem.
Others like this include dropwizard and spring boot, but there's always room
for more.

Java ain't perfect, but a lot of hard problems have been solved for the
ecosystem and building on top of those solutions will save teams time and
money.

~~~
cheald
That's the same reason I use JRuby so heavily - I can use the entire Java
ecosystem, while claiming the productivity benefits of Ruby.

~~~
kyllo
Same for myself and Clojure. Better coding productivity, easy Java interop for
more libraries, and the deployment story is a no-brainer.

~~~
dkersten
Me too. What I like about Clojure (and other JVM languages) is that I can
choose how much I want to take part in the JVM ecosystem. There is usually a
spectrum from _pure-clojure <\---> clojure-wrapping-java <\--> pure java_ and
I get to choose where on that spectrum I want to or need to be based on the
needs of my project.

Since the Java ecosystem is huge, this gives me a lot of confidence that most
of my needs will be met by existing tools.

------
this_user
I'm not sure why I would need this when Java EE does most of this already. The
Enterprise Edition has made a lot of progress with version 6 and 7 and greatly
cleaned up the XML descriptor nonsense and instead relies on convention over
configuration and annotations where necessary. Things like CDI for DI, JAX-RS
for webservices and JPA for persistence just work out of the box with minimal
configuration. As far as web pages go, JSF works well and is nicely integrated
with the other technologies. But server-side web applications are obviously
outdated in 2015, you could easily get something like Angular to work with the
Java backend and ditch JSF.

~~~
tajen
Your comment should have been the first one of the discussion page! because
it's nice that there's a default standard like Java EE.

However... What's painful with Java EE is the time it takes to understand it.
Please correct me if I'm wrong, because I've never got around it, but it takes
5 years of experience to build an app using CDI, JAX-RS, JPA, JSF, JNDI. For
each of them you need to choose the implementation provider (Hibernate, Jersey
if I'm correct?) and configure it, then you get bugs like the application
isn't aware of your JPA and you don't know why, because the spec is
circonvoluted enough to be powerful but then takes months to understand.
Whereas some frameworks like Play Framework can be learnt in 2-5 months.

This is my feeling about Java EE, but have I been in bad luck with my
experience? Is it supposed to be quick to get a canonical-JEE app running?

~~~
eternalban
To understand JEE you first need to align with the motivation for the
platform: distributed component oriented systems for an heterogenous
enterprise environment. The second preliminary is to fully grok why
indirection is necessary for loosely coupled component systems. JEE is built
on a set of canonical indirection layers.

The rest is simply a set of orthogonal specs -- none in anyway intellectually
or technically challenging. Building a tutorial full stack JEE app should let
you see and touch most of these layers from client to backend.

It is a good thing that the new hotness in coding is ignoring JEE ..

------
koevet
Big kudos to whoever is behind this framework for the excellent documentation
and the funky site.

Still, I doubt I would use Jodd in a new project. The core components (MVC and
data access framework) are completely new to me. It seems that they are
developed by the same people behind Jodd. I don't particularly like Spring MVC
or Hibernate, but Jodd libraries don't seem to be widely used (only 22
questions on SO and no forum or mailing list).

Beside the poor adoption, from a cursory look at the documentation, I couldn't
find any striking feature. Actually the DB mapping module seems quite
convoluted.

Also, I don't get this strong emphasis on the framework being "lightweight".
Who cares if my project uses 3MB or 20MB of libraries?

As others pointed out, also take a look at Dropwizard and Ninjaframework.

~~~
twic
> that they are developed by the same people behind Jodd

Same _person_ :

[https://github.com/oblac/jodd/graphs/contributors](https://github.com/oblac/jodd/graphs/contributors)

Mr Spasic seems to be something of a virtuoso!

------
matdrewin
I love this. Java may be verbose at times but it's still very easy to
understand, fast and stable.

~~~
snambi
Java is verbose for a reason. It is easier to modify and run code that is
written decades ago. It still works.

Being concise is good for the first time. If someone needs to fix the
"concise" code years later, the only option may be to throw it away and write
it again.

~~~
yummyfajitas
This is not about conciseness, it is more about lack of language evolution.
Older, purely functional haskell ocaml or scheme is quite readable and quite
concise.

The main place where older code in readable languages (e.g. not J, common
lisp, Perl) becomes hard to read is when new language conventions have
replaced the old.

~~~
eternalban
You should temper that first sentence with an 'only'.

------
JustSomeNobody
Java desperately needs more of this. It's a good language and a great
platform. A lot of people don't want to look at it because they've heard (or
experienced) horror stories about the huge frameworks. Enterprise development
doesn't have to be that way!

~~~
untog
I've long thought the same about C#. I haven't worked with in years now but I
loved it when I did, and thought the reputation given to it by horrific
enterprise development was never deserved. You can be _amazingly_ concise with
that langauge.

~~~
aikah
if you ignore webforms C# doesn't have the "bloat load" Java has really.

~~~
ghuntley
Yeah but no. You know those fancy FRP frameworks, ever wonder where they got
their inspiration from?

[https://rx.codeplex.com/](https://rx.codeplex.com/)

------
edavis
If I wanted to learn more about web development in Java, what's a good
starting point? Something that can give me a high-level overview, current best
practices, and perhaps a simple "Hello World" example.

I currently work with Django and Wordpress, so I'm not totally new here. But
last time I dived into this world, I could not make heads or tails of it.

Java seems like a powerful tool to have in your toolbox, but from what I've
found it does not lend itself to be easily picked up.

~~~
hendzen
One word. Dropwizard.

~~~
twic
edavis asked about web development. Dropwizard was built for web services.
There is a bit of a difference - user-facing web apps need to do templating,
authentication, session management, etc.

I see that there is a Dropwizard module for templated views, which looks
reasonably nice:

[https://dropwizard.github.io/dropwizard/manual/views.html](https://dropwizard.github.io/dropwizard/manual/views.html)

I'm not sure how well it supports the other aspects of a web application.

------
andretti1977
Do you want powerful jvm environment and exceptional java ecosystem? Do you
want a java-like language (easy learning curve) but want to write less and in
a more elegant way? Do you want a powerful scripting language? Do you want to
work with consolidated technologies like hibernate and spring but in a more
comfortable way? So why don't you choose Groovy and Grails?! I've been working
with it for the last 2 years after many years as a J2EE developer and now i
can't think to start a J2EE project without it!

~~~
frowaway001
Groovy and Grails have lost their reason for existence years ago, and without
the sponsoring they are both dead.

~~~
monksy
What reason is that?

They're an Apache supported project now.
[http://adtmag.com/articles/2015/03/04/groovy-joins-apache-
fo...](http://adtmag.com/articles/2015/03/04/groovy-joins-apache-
foundation.aspx)

~~~
vorg
The Codehaus implementation of Groovy was only voted into Apache a week ago,
and still needs to complete the infrastructure conversions which could take
months, or longer if problems surface. Its project manager Guillaume Laforge
has been making fraudulent claims about the consensus of the "Groovy
Community" on joining [1]. He's redefining "Groovy" to be whatever's in their
particular codebase, instead of a reference implementation of a spec as its
creator James Strachan asserted right up to his last ever posting on the
Groovy mailing list [2]. From there, Laforge is redefining the "Groovy
Community" to be whoever's committed to that codebase, instead of whoever's
contributed in any way to Groovy, including people who've haphazardly worked
on other implementations of Groovy and those who've mainly written
documentation. To further support his new narrative, he recently withdrew from
the expert group and lead role on the JSR-241 [3] that defines a spec for the
JVM version of the Groovy Language. I suspect the Apache mentors of Groovy
such as Roman Shaposhnik, Bertrand Delacretaz, and Emmanuel Lecharny might not
fully realize the fabrications they're dealing with.

[1]
[http://thread.gmane.org/gmane.comp.apache.incubator.general/...](http://thread.gmane.org/gmane.comp.apache.incubator.general/48801/focus=48810)

[2] [http://groovy.329449.n5.nabble.com/Paris-write-up-
tt395560.h...](http://groovy.329449.n5.nabble.com/Paris-write-up-
tt395560.html#a395571)

[3]
[https://jcp.org/en/jsr/detail?id=241](https://jcp.org/en/jsr/detail?id=241)

~~~
blackdrag
there is one thing you can be very happy about... there is no Project Lead in
Apache Projects, right?

~~~
vorg
Whether someone's called a Pivotal Project Manager, an Apache P.M. Committee
Chair, a Codehaus despot, a JSR lead, or whatever, if their skills are
managerial rather than technical then they generally end up relying on having
the best title and position rather than what they actually do to make the
product be the best possible.

As for being happy about something, if Groovy development is being effectively
led by its technical people as well as not being dictated to by the
applications using it, then I'd be optimistic for its future (the Codehaus-
cum-Apache implementation of it anyway).

------
ExpiredLink
People interested in 'lightweight' Java EE should check out Adam Bien's web
site: [http://www.adam-bien.com/roller/abien/](http://www.adam-
bien.com/roller/abien/) . He energetically promotes modern lightweight EE
(especially for startups). He overshoots the target sometimes (being too
simple) but it's always interesting and entertaining.

------
emmanueloga_
The premise of "micro" anything in Java sounds attractive. I think the JVM is
awesome, but often times I go back and forth on my enthusiasm about it because
my recollection is that most things implemented for it end up being bloatware
(think Eclipse). In the back of my mind I can't stop thinking any given Java
app may be using n times more memory than necessary [1].

By the way, I think they went overboard with the marketing. Jodd libraries are
all of: efficient - elegant - fast - lightweight - micro - powerful - slick -
super - tiny - versatile. It is almost like they picked a random superlative
for each piece. I get the point! I see lots of projects going this route on
their marketing materials and it ends up being a bit annoying.

1:
[http://stackoverflow.com/a/632525/855105](http://stackoverflow.com/a/632525/855105)

~~~
yogthos
I don't think Java lends itself very well to doing anything light or micro by
design. However, it's perfectly possible to have lightweight stuff on the JVM,
Luminus [http://www.luminusweb.net/](http://www.luminusweb.net/) is a good
example for Clojure.

~~~
emmanueloga_
Cool, Luminus is micro, lightweight, robust, and scalable.

Sorry, I could not help myself :-).

I think it would help if people backed their claims with some actual data: a
memory/CPU/lines-of-code comparison against mainstream alternatives or
standard libraries.

~~~
yogthos
Well, the docs do start with a walkthrough of a simple application:
[http://www.luminusweb.net/docs](http://www.luminusweb.net/docs)

You can really judge for yourself how it compares to the alternatives you're
familiar with.

In terms of memory/CPU there are plenty benchmarks out there such as the
benchmarks game site
[http://benchmarksgame.alioth.debian.org/](http://benchmarksgame.alioth.debian.org/)

A small Luminus app will take around 100megs
[https://groups.google.com/forum/#!topic/clojure/mQbcz82I7iI](https://groups.google.com/forum/#!topic/clojure/mQbcz82I7iI)
so that's pretty lightweight by most standards.

In general though while people seem to be obsessed with benchmarks of all
kinds, performance is simply not going to be an issue for the vast majority of
sites out there. The real question is how productive your stack is and how
easy it is to work with.

------
vskarine
I would still recommend going with
[http://www.ninjaframework.org](http://www.ninjaframework.org) as it is a lot
more complete

~~~
raptaml
Full ACK!

------
pimlottc
How does JDateTime compare with Joda Time? Date and time classes are extremely
tricky to get right, and Joda has been working on it for a long time.

~~~
twic
JDateTime appears to be very minimal:

[https://github.com/oblac/jodd/tree/master/jodd-
core/src/main...](https://github.com/oblac/jodd/tree/master/jodd-
core/src/main/java/jodd/datetime)

And to repeat some of the mistakes of the past, such as having the classes be
mutable, and not separating zoned and unzoned times. It also contains some
novel wackiness of its own: new instances of JDateTime take default values for
some settings (time zone, whether date arithmetic should be clamped to valid
dates, etc) from fields in the class JDateTimeDefault; but these fields are
static, not final, and public, so any code in the JVM can change them, thus
changing the behaviour of JDateTime objects created by completely unrelated
code!

As of Java 8, there is a pretty comprehensive and well-designed date-time
package in the JDK:

[https://docs.oracle.com/javase/8/docs/api/java/time/package-...](https://docs.oracle.com/javase/8/docs/api/java/time/package-
summary.html)

That package was designed primarily by Stephen Colebourne, who designed Joda
Time, and essentially constitutes the Joda Time: The Next Generation. I don't
see any reason to use JDateTime over this.

------
bronson
> Jodd is set of Java micro frameworks, tools and utilities, under 1.5 MB.

Curious, what do they mean by 'micro'?

~~~
ipedrazas
that's exactly what I thought. What I would like is something like those JS
frameworks where you can choose what you want and generate the lib that suits
your needs.

Customisation over configuration.

~~~
tokenizerrr
[http://jodd.org/download/](http://jodd.org/download/)

When using maven you can pick and choose the modules you want.

~~~
ipedrazas
I know, I was talking about having a simple ui where you check check check and
"pom" you have the libraries that you want.

Edit: The ui generates the dependencies for your pom. I know how maven works,
and it's a pain to copy all those xml snippets in your pom.

~~~
saryant
But... that's the point of Maven and other package managers. Why does it need
a UI like that? Unlike JS, the tradition in Java development is to use managed
dependencies rather than download JARs for everything and throw them in /lib.

~~~
curun1r
Maven needs a UI because of its pathologically-verbose XML syntax. Compare a
pom.xml with its Gradle equivalent...only one is designed with humans in mind.

~~~
saryant
Which is why I said "and other package managers." My point was that a UI like
the one to build a custom Bootstrap download doesn't make sense in the Java
world because we have package managers, unmanaged dependencies are not the
norm in most projects.

------
abalone
Cool, how does this compare to DropWizard?

I know DropWizard is like a distro of select "best" projects out there, glued
together with some configuration and instrumentation code. That makes them
easier to use while leveraging the battle-tested-ness of established libraries
like say Jackson for JSON.

Is this more of a "built from scratch" set of frameworks? How battle-tested
are they?

~~~
devonkim
DropWizard is mostly meant for creating a set of conventions to production-
ready applications with operations-friendly things like instrumentation hooks.
Jodd is oriented more around simpler libraries for doing what people have
oftentimes used heavyweight frameworks for (not in terms of performance though
necessarily but in terms of mental efforts and scaffolding required to get a
MVP out the door). You could use both frameworks together because they have
almost orthogonal concerns and both being minimal don't step on each other's
toes.

Jodd in itself could work for not needing an app container by using something
like Winstone (Jenkins is built with it) for deployment models closer to
systems like node.js or Flask and Sinatra that emphasize minimal scaffolding
to make it easier to horizontally scale a system by just deploying more dumb
nodes.

I've seen Jodd used in production systems and just never seen a stacktrace
fail to that point so far. I've only ever seen application code fail in itself
or fail due to a side effect or misunderstanding of the underlying libraries.
I've seen FAR more bugs due to the ugliness of the old Java dateutil libraries
than Jodatime, for example, but would we argue Jodatime is more or less
mature?

Maybe I didn't answer your question but I'd say if you're looking for super
stable libraries I'd argue on a time basis alone to just use core Java then.
The very point of minimalism from a reliability perspective is to reduce
points of failure in code with simply less parts. And really, with the number
of deployment headaches I've had resolving random classes across an app
container, I could take one less transient dependency in my project.

~~~
abalone
> I'd say if you're looking for super stable libraries I'd argue on a time
> basis alone to just use core Java then.

Thanks for your reply but I didn't understand this part of it. Core Java
doesn't have a lot of this functionality. Are you proposing it would be better
to write your own JSON serializer in core Java, for example, than using a
battle-tested library like Jackson?

~~~
devonkim
I'm arguing the opposite - if you want stability and time-proven code, you
will find the most boring, standard library possible. So, you'd pick Jackson
for JSON serialization over, say, GSON. But taken further why not just go back
to C... Or COBOL? We have to trade off some stability through age for some
newer code that's got better potential. Reinventing the wheel should be
discouraged only on the basis of it not being tested as well in the fires of
production use, not so much for being actually redundant. How many of us would
write exactly the same hashing library if we were told to do it repeatedly?

So in a scenario like being stuck with Java 6 I'd say you could use libraries
like Jodatime and Jodd to make up for certain inconveniences, but it's up to
you to decide if your application is fine with the AOP in Jodd v. Guice v.
Spring v. whatever J2EE standard is trying to catch up after the fact.

------
csense
> Designed with common sense

Disclaimer: I have nothing to do with this project.

It looks interesting though.

------
kazagistar
> Proxetta - the fastest proxy creator with new, unique approach for making
> pointcuts and different type of advices.

Man, this just sounds so lightweight!

------
StrykerKKD
I used Jerry at work and it's really one fine HTML parser. I like it better
than JSoup, although it works a little bit weirder. :D

------
zo1
Are all the libraries together, combined, under 1.5MB? Or is each one under
1.5MB?

~~~
jodder
All together :)

------
enthdegree
Some day, in the distant future, 2015, development of all new startup
projects' descriptions, documentation, websites and source code will be
automated using Markov chains. The projects' half-life will be a strong
function of its position on the Hacker News Front Page. After dropping out of
the top 30, the project immediately decays into an EOL abandoned repo in an
archive no one will ever look at.

The conspiracy, what most people know is true yet are afraid to admit, is that
the Markov chains are trained entirely on past failed code projects. Like cows
chewing their own cud, like dogs lapping up their own vomit. Soylent Green is
People and Libraries are Pure Virtual.

____ is set of ____ micro frameworks, tools and utilities, under ____ MB.
Designed with common sense to make things simple, but not simpler. Get things
done! Build your Beautiful Ideas! Kickstart your Startup! And enjoy the _____.

is this the future of technology, or has the future already arrived

~~~
zo1
A shame that you didn't decided to make this very insightful comment on one of
the "Library ___ in [Rust|Go]" threads. I'm not trying to bag on anyone, just
want us to maybe consider that there is some sort of "underlying" malaise that
is causing us to invent, and reinvent constantly. Is it due to us simply
wanting to reinvent things, or perhaps due to libraries/frameworks eventually
becoming too big that we _need_ to reinvent it in smaller forms and new
languages? I don't know, but it needs to be discussed...

~~~
kyllo
People are building those things in Go and Rust because they're currently
implemented in unsafe languages like C/C++ and are therefore riddled with
undiscovered memory management bugs, overflow bugs, undefined behavior etc,
which are often security vulnerabilities waiting to be exploited. I don't
think it's reinvention for reinvention's sake, I think they're genuinely
trying to fix some of the horrible historical mistakes of C.

