

Java lightweight framework - jodd - javinpaul
http://joddframework.org/

======
jurre
Note to people that design pages like these: If you're putting a blinking
cursor on your page, I'm trying to type things. The first key I will press is
the backspace key, if this takes me to the previous page, I now left your
webpage and it's unlikely that I'll return. Might be just me though :)

------
hmottestad
Here is the real page: <http://jodd.org/>

~~~
sciurus
Having the landing page be on a completely different domain seems like a bad
idea for search engine ranking.

------
ShabbyDoo
"Only 1.1M" Why do I care? Is this framework designed for embedded systems or
mobile apps? Smaller is better, but one MB vs 10 MB makes no difference for me
as a guy writing server-side Java.

~~~
j_baker
I suppose it makes a difference when it comes to getting your local dev
environment set up. Plus, you might be able to get away with doing continuous
integration that downloads all its dependencies every time it runs.

~~~
eropple
> I suppose it makes a difference when it comes to getting your local dev
> environment set up.

It shouldn't, if the artifacts are in your company repo. (You have a company
repo, right?)

------
bitwize
I was trying to figure out Java EE, and wrote some notes on how the various
pieces fit together.

My final note was "You don't need this crap".

Oracle didn't take over Sun in 2009; the takeover started when Java EE started
taking hold. It's given the cool little language Java a bad rap and I'm glad
to see some efforts to bring Java back to its roots as a lightweight and easy
language in the Web development sphere.

~~~
UK-AL
Java EE is not that bad. The problem is that it is for enterprise and you have
tons of frameworks for interfacing with legacy mainframes and such.

Go for for EE web profile, which the lean version for pure web stuff.

All you really need is JPA, some ejbs and a front end(mvc framework or
something) and that's it. Add in jax-rs, add some annotions to your ejb and
you will have a rest api for you application for free basically.

~~~
eropple
IMO, JPA (and ORMs in general) is one of the bigger crimes-in-progress in
Java. One of the things about Play I _do_ like is that the Scala API eschews
JPA.

EJB, however, manages to be even a _bigger_ crime-in-progress than JPA. Which
is a feat. Making immutable bean classes, and then providing a pleasing API
for using them, is an exercise in futility. (And this may sound dogmatic, but
I don't really care: immutable-by-default is the only acceptable practice.
Embracing EJBs means you probably don't care about that, and that I want
nothing to do with your code.)

~~~
UK-AL
Dude stuff goes in and out fashion faster than anything in tech. Orms went in,
Orms went out, then in again(Django, rails) then out. Just need to stop being
zealots following the latest trend and get things working.

People take the immutable route, then some other guy tells you your being
silly. Trust me I've been programming long enough.

Besides you don't need Mutability for ejb. The majority of ejbs are just used
to access the db.

~~~
eropple
No, thank you, I won't trust you on this. I've been a fairly loud critic of
ORMs since the first time I was exposed to them (Hibernate, as it
happens)--having seen them in practice hasn't changed that a bit. The
conventional opinion on them may have changed, but mine never has; mutable
data structures increase code complexity and greatly increase the surface area
for state changes in places it wasn't (or shouldn't have been) intended.

And you may not _need_ mutability for EJB, but it's almost always the case
that you _have_ it--it's partly a side effect of having to deal with people
like you who consider it "not a big deal" and partly because JavaBeans are
completely misused[1].

(For those following along at home, who might not be familiar with the culture
of Java programmers, mutability in absolutely bizarre places eventually ruins
your day at least once. See, for example, the Date[2] class, which for some
very Java-y reason is completely and totally mutable. Questions related to the
Date class are among my favorites for determining whether a Java programmer
has any concept of mutability, and why "do you use Joda Time?" is a decent
barometer of basic not-going-to-kill-your-project competence.)

.

Seriously, though: is "just get it working" the entirety of your defense for
diverging from good practices? This isn't just me calling it "good practices,"
this is what Bloch says in head-shrinking detail in _Effective Java_ and what
pretty much everybody else who's had to write Java in anger eventually agrees
with. This[3] isn't the best thing in the world on the topic, because I'm not
going to quote _Effective Java_ at length, but if you can read that and then
come back with "just get it working," I'm gonna have to go light a candle for
whoever inherits your code down the line because I've been there (still am
there, in the day job) and it's hell.

[1] <http://www.javapractices.com/topic/TopicAction.do?Id=84>

[2]
[http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Date....](http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Date.html)

[3] <http://www.javapractices.com/topic/TopicAction.do?Id=29>

~~~
UK-AL
I'm a functional programmer I know what immutable is. However if you've
programmed a game in a functional programming language you know it also
requires the code to become more complex in various situations. You have to
introduce reactive programming to do it properly.

No longer can you simply change to coords of an entity to change a position.

In that situation I would recommend introducing mutability, trying avoid
mutability would make it more complex.

Date api is one broken things about java. Everyone knows it is broken.

There about ten billion versions of good practise, I could quote them and say
you are diverging from good practise?

I also recommend you keep things immutable, but not if it makes things
difficult.

~~~
eropple
_> if you've programmed a game in a functional programming language you know
it also requires the code to become more complex in various situations_

Irrelevant. A game is not a web application. A game has a claim to require
mutability for performance concerns, but mutable state is generally safer in
such a use case. A game is likely to have a few threads, each with a dedicated
task or set of tasks, whereas a web application is not so constrained and any
request may effectively duplicate another. Web applications that are cavalier
about mutable state literally-literally invariably decompose to "synchronized
blocks for all the things!" and, seriously, who wants to have anything to do
with that?

 _> I can also find lots literature about following java bean convention as
good practise. Your just cherry picking literature._

I'm not "cherry-picking" a Goddamned thing: I'm referring to one of the major,
canonical sources of Java convention. You may find shitty Apress books that
say "sure, use JavaBeans everywhere!", but that's why they're shitty Apress
books. _Effective Java_ is the book that literally-literally every competent
Java programmer I have ever met has read and fully digested. There are areas
of style where not everyone I've met agrees with Bloch, but immutable-by-
default is very widely accepted _except_ in areas (such as game development,
though that is, again, irrelevant to the topic at hand) where performance
becomes a legitimate concern.

But, except for those edge cases (and they really are edge cases, they
certainly don't apply to web development) you are _not_ going to find someone
of significant credibility and stature in the Java community who is going to
say "follow JavaBean convention". You just aren't.

(If you were, you already would have.)

~~~
UK-AL
Indeed, I too implement web apps in a immutable manor when I can. Most of my
ejbs are immutable, since they just add and return stuff. I don't like web
servers relying on state. I also keep my ejbs mostly stateless using stateless
ejbs funnily enough.

However when choosing JPA or JDBC - thus relying on boilderplate code loading
data into java object constructors manually then I choose jpa.

It is a trade off for me. Boilerplate or keeping immutable data classes. For
me that is a situation when adding immutability makes things more difficult.

And besides most well supported modern web frameworks like Django or rails
also do it that way. So it is not really trade off when choosing EE / rails /
Django. You have to have in most of those frameworks unless you rip out the
orm.

I'm not really in a position to choose some obscure framework.

------
nlz1
Excellent use of icon art on <http://jodd.org/>

Why do we need another Java framework?

------
jshen
Whenever I read about java things I get really confused. WTF is a super
property, a BeanUtil, and a timeless JDateTime???

People like to hate on DHH and rails, but remember the "make a blog in 15
minutes" video. That's a compelling story for a web developer. Compare that to
this.

------
adrianmsmith
Not sure about the rest of it but this is something I hadn't heard of before:
"JQuery in Java" (Jerry), looks nice.

<http://jodd.org/doc/jerry/index.html>

Interesting use of $ as a method name in Java as well.

~~~
prophetjohn
Looks pretty similar to GQuery/gwtQuery

<http://code.google.com/p/gwtquery/>

------
bad_user
Awful page for mobile phones. Note to ambitious designers: sometimes plain
text is much better.

------
j_baker
If scrolling down gives me jodd experience, am I to assume that jodd is made
for UX folks who care only about form and not function? That's what this
webpage seems to be telling me.

(Although to be fair, it _is_ pretty and neat.)

------
chucknelson
Wow, this link should just go to jodd.org. Scrolling through the "experience"
just made me hit the buzzword wall.

------
swGooF
How does this differ from Play?

~~~
eropple
That's a very good question (and one I'm personally interested in because I'm
pretty frustrated with Play and the Play developers right now).

Jodd looks like a very 'old-school' Java framework. This is not a compliment--
it looks like a few tools that sit on top of Servlets, and that's just
terrible. Wire-up appears to be XML (bad developer, no cookie) and it just
doesn't look _better_ than any other Servlet-based library. (Personally, I am
convinced that there are no good Servlet-based libraries, and this doesn't
help change that.)

The various libraries they keep touting on their various pages are a little
scary. I'm pretty well-versed in the Java ecosystem, but I don't know what
"Petite", their dependency injection library, is. I know what Guice is, and I
know what Spring (barf) is, but this thing is new, and by default shifty and
untrustworthy.

"Props" - looks terrible compared to HOCON; gross syntax, no importing, etc.

Their database library touts itself as "better than JDBC", but looks almost
identical and makes that little voice inside whisper, "it's a trick - get an
axe."

I'm not trying to harsh on them, because they clearly spent a lot of time on
this framework, but this is enterprisey as hell.

~~~
dfragnito
Care to share your frustrations with play? We are considering it for an
upcoming project.

~~~
eropple
-Play 2 was released too early and Play 1 isn't getting any love anymore, so it's currently in an awkward spot. There's stuff you can do in Play 1 that can't be done in Play 2 yet; they're working on it, but it's not yet there.

-Play 2 is uncomfortable and vaguely user-hostile if you want to use Java. More than most Java apps, that is. It's fairly obvious that the Play team considers Scala to be The Way To Do It, so you'd better be on-board or you're probably going to hate using it. (I'm OK with Scala, though as I've said before I find it troublesome[1]. I hear eventually Kotlin is supposed to be supported though.)

-Play is _all_ SBT. You may find that you love SBT, in which case this won't be a problem for you, but it has been a while since a build tool made me yearn for the days of ye olde makefile. There's a lot of "magic" involved and there's little coherent documentation for either SBT or Play's use of it.

-Play's DEV mode pins a core on my laptop and turns it into a campfire on my lap. A ticket asking what's up with this has gone unanswered.

-Play 2 is designed for single projects and trying to build sane multi-project systems (like, a frontend app, a common code library, and a backend app) can be an exercise in frustration. This has gotten less bad over time, but it's still not great. I literally _don't remember_ the last time I wrote a web app that wasn't at least three separate pieces, so for me this is very nearly a game-breaker.

-The developers are apparently pretty insular. It seems like they are more than happy to have you fix their bugs, but adding features that _you_ need--not so much. Sample size of one, so apply all necessary caveats, but I've found that offers of help and requests for guidance for making what you want to do fit into their plans for Play seem to get ignored[2]. _I want to help make it better_ , so let's talk and see how to do that, yeah? (Lack of good communication isn't just a Play thing, but seems common throughout the Typesafe stack of libraries.)

-The community isn't really a community at all. If you look at their Google Group, it's mostly the same five questions over and over again and nobody seems to really stick around. I look at something like Rails--which I can't stand working with, but they have the "active, good community" part absolutely nailed--and you see a lot of newbie questions, but you also see a lot more people sticking to the community and, IMO, that bodes a lot better for the platform.

.

Honestly, Play isn't that bad, if your needs line up closely to the Play
developers'. Mine don't, so for me it's a very frustrating experience. If
you're just rapidly iterating on something small I have to think it'd be great
- hot reloading works great (although compiling templates seems like it'd turn
off designers) and I would believe that, once over the initial hurdles, you
can probably Get Stuff Done very effectively. But every time I work in Play I
start getting a little bit crabby and want to go write a better web framework
(with blackjack! and hookers! in fact, forget the blackjack!) but I know I
don't really have the time to do it justice. As such, my projects mostly end
up being a set of libraries bolted together on top of Jetty (a handler, a
regex dispatcher, etc.). Maybe at some point I'll codify them into an actual
for-realsies "library". It'd be a good reason to learn how to do Java class
reloading...

[1] - <http://news.ycombinator.com/item?id=4051556>

[2] -
[https://play.lighthouseapp.com/projects/82401/tickets/502-mo...](https://play.lighthouseapp.com/projects/82401/tickets/502-more-
flexible-configuration-for-multi-project-setups)

~~~
swah
Perhaps someone should fork 1.2.5 and develop it as a new project? (to avoid
confusion with Play 2)

------
bwei
I use them. They are good.

