
Java Micro Frameworks - tkfx
http://blog.takipi.com/java-micro-frameworks-the-new-trend-you-cant-ignore/
======
pvg
This is an odd and uninformative write-up that compares two things (Jodd,
Ninja) that aren't really micro-frameworks (say, in the mold of Flask or
Sinatra) with one that is (Spark). The comparison seems based purely on
advertised features and, even stranger, number of github stars and forks.

Spark is a Sinatra-inspired micro-framework built on the familiar 'call me
when this HTTP verb happens' pattern. It does little beyond that but is quick
and easy to get up and running.

Despite the forks and stars, it's also probably the least mature of the three
- it's not hard to run into a bug or a wart. Those are usually easy to find
and fix since it's pretty small. On the other hand, the maintainer has been
busy with other things for quite some time and it takes a very long time for
PRs to get much attention. The testing setup is an ugly mess so adding a test
for your fix is also unpleasant.

A couple of other constraints are that it requires Java 8 and, while it
theoretically supports running in an arbitrary servlet container, it's really
happiest living in embedded Jetty.

------
danneu
From Spark's homepage copy:

    
    
        Why use Spark?
    
        If you're a Java developer with neither the urge nor time to learn
        a new programming language, and you're not planning to build a
        super large web application that scales in all directions, 
        then Spark might be a great web framework for you.
    

Maybe they're just being honest, but "use Spark if you're stuck with Java and
can't be bothered to learn something else" is a bit off-putting.

I think a better angle looks something like "use Spark if you want a simple,
minimal Java microframework" and "if you're coming from Sinatra/Flask/Express
and you want something more statically-typed".

~~~
eloisant
I guess it's for people who are stuck with Java because of a corporate choice
that has been made to use only this language.

That's very common, and it's usually easier to get approval for a new
framework than a different language.

~~~
fennecfoxen
now if I could only get approval for Java 8... now that 7 is officially end-
of-lifed...

------
lmm
It's long been ironic that Java has excellent dependency management in the
form of Maven - better than any other tool I've used, for any language - but
the typical java project had far fewer dependencies than in ruby or node. Glad
to see some smaller libraries emerging (and it's worth noting that even e.g.
spring is now released as a collection of smaller modules rather than one
giant jar).

~~~
eridal
It's undeniable that maven can do much more things that other dependency
managers, like setting IDE configurations for instance, but that does not make
it better.

Do you think it's better than the likes of npm, bower, or composer? where you
just say: give me all these things, with at least these versions, and could
you please run these scripts also --all at once, in about 30 lines

Every time I want to use mvn I need to start for google .. which was the
archetype parameter that I needed?

or so let's run this not-so-common target, no problem I have 5 minutes for a
coffee while it downloads all the requirements .. then 5 minutes later says
"missing parameter"

~~~
lmm
> Do you think it's better than the likes of npm, bower, or composer? where
> you just say: give me all these things, with at least these versions, and
> could you please run these scripts also --all at once, in about 30 lines of
> plain text.

Yes. "Run these scripts" leads to snowflake builds: every project ends up
_slightly_ different from every other, no-one can resist putting a little
"magic" in their build that then goes on to confuse future developers.
Requiring every build step to be encapsulated as a plugin, so that there's one
and only one way of putting the scm version in your build, one and only one
way of bundling your app into an executable, and so on, makes everything much
more maintainable.

> Every time I want to use mvn I need to start for google .. which was the
> archetype parameter that I needed?

You don't need archetypes if you find them problematic. Just start with a
minimal pom: groupId, applicationId and version. That's not so hard is it?

> or so let's run this not-so-common target, no problem I have 5 minutes for a
> coffee while it downloads all the requirements .. then 5 minutes later says
> "missing parameter"

Either you share your build steps, which means downloading them sometimes, or
you copy/paste them everywhere. I know which I prefer. Maven caches quite
aggressively (if anything too aggressively), I'm not sure what more it could
do.

~~~
jjnoakes
Running scripts doesn't imply "snowflake builds" \- one can just as easily
write duplicate plugins that are a mess, and one can also just as easily write
encapsulated scripts that do one job and do it well.

It's all about the quality of the developers.

~~~
lmm
It's not "just as easy". A maven plugin is necessarily a maven module, a
first-class module like any of your libraries; unless you go out of your way
to make it not, it has versioning, tagging and the like. Even more
importantly, since the plugin itself is built with maven, it naturally has
dependencies and unit tests, arranged in the same familiar structure as the
rest of your code. Everything guides you towards good development practice; of
course you could manage your scripts in the same way, but you'd have to do so
by hand, and with the best of intentions I've never seen any team that used
scripts have the discipline to manage them properly.

Good developers can make good things with bad tools and bad developers can
make bad things with good tools yes, but even so, tooling and defaults are
extremely important.

~~~
jjnoakes
> I've never seen any team that used scripts have the discipline to manage
> them properly

And I'll throw in my personal experience too, which is the opposite: I've
never seen any team that used Maven and had the discipline to manage it
properly.

Anecdotes don't really get you too far.

------
zaphar
The author starts out by saying that one consequence of Java

    
    
       being a safe, rigorously tested, backwards compatible 
       language is making some sacrifices around agility and 
       streamlining.
    

Yet there is nothing in Java as a language that prevents agility and
streamlining. It's not a consequence of Java the language it is purely a
consequence of Java's community.

It's true that there are a lot of people who when doing java are starting to
change the community from the inside and this is good. But pretending like you
are fighting the language when doing this is counterproductive.

~~~
zkhalique
The language itself is verbose. Instead of overloading operators, for
instance, the convention is to have longer method names.

~~~
abalone
But that's the point: convention is a product of the community. You don't need
operator overloading to design classes with shorter method names.

~~~
dikaiosune
In many cases, the community starts with something that looks like a languages
standard library. And Java's is very verbose, so it makes sense that the
community would have verbose method names as well.

However, while I can see it taking some getting used to if one comes from a
different background, I personally find Java to be nicely self-documenting
when using the conventions on display in the standard libraries. Lines are
long and sometimes a statement spans multiple, but in many Java libs/apps
things do exactly what they're named.

------
javajosh
Uh, what about Dropwizard[1]? By Github stars, it's 50% bigger than Spark, the
most popular in this writeup.

It's really quite good. Provides integrated, configured libraries for REST,
JSON, health checks and metrics. Even supports shaded fat jars (which provide
a true single "java binary" you can execute with java -jar). It's really quite
nice.

[1]
[https://github.com/dropwizard/dropwizard](https://github.com/dropwizard/dropwizard)

~~~
msluyter
The author did mention Dropwizard:

 _The first wave was around lightweight Java frameworks (a few of which we
wrote about: Dropwizard vs. Springboot). These delivered lightweight, modern
frameworks for Java and helped cut down development time. Now there’s a second
wave that’s been recently hitting the scene. That wave is Java micro
frameworks._

~~~
javajosh
Ah. Somehow I missed that. Thanks.

------
scarmig
Is it too grumpy for me to complain about Spark's name? It postdates the more
well-known one by like a year or two.

~~~
saryant
I'm glad I wasn't the only one confused by that. I'd never heard of Spark the
micro-framework and thought the author had somehow Spark the cluster framework
into this article.

------
stickfigure
For folks working with Guice that want a _really_ simple and stripped down
framework, check out GWizard:

[http://www.gwizard.org](http://www.gwizard.org)

It's basically DropWizard reimagined with dependency injection. Thanks to
Guice, there's surprisingly little code involved.

(I'm the primary developer)

~~~
latchkey
The fascinating thing for me about gwizard is that you no longer think about
testing from the http layer. You use guice to create a resource and then
directly test the resources api. No need to build up urls or post data to a
server. No need to spin up a http server at all. Now you get statically typed
tests that execute much faster. Win.

------
erikb
Can someone reframe the definition of the term "micro framework"? I understand
the article as micro=very small, but the first example has a lot of batteries
included. Isn't that the opposite?

~~~
Zancarius
I don't know if this will help since I suspect you know way more than you're
letting on, but I usually find myself framing the definition of a "micro
framework" in terms of those I'm most familiar, chiefly Flask. It should have
enough "batteries included" to be immediately useful, but small enough that
you can keep most/all of the framework's API in your head at any given time.

Then again, I sometimes wonder myself if the definition blurs over the age and
maturity of the project. If you look at Flask's ecosystem, there are
extensions for nearly _everything_ , making it so that ecosystem as a whole
does just as much as a full-featured framework, but you have greater choice as
to what components to include (and there's not One True Way to do anything in
particular--there's just extensions that are more well-supported than others,
well-maintained, and more popular).

I suppose this means that the better analogue is that micro frameworks give
you greater control over lower level aspects and make fewer decisions for you
(e.g. Django more or less expects you to do things Django's way; Flask has
fewer such expectations). Given some of the micro frameworks I've seen,
though, I think it's a definite spectrum, not an absolute, and probably
depends just as much on the ecosystem and culture surrounding the language as
it does on the intent of the creators. Silex (the PHP framework) does very few
things, for instance, but it seems that you ought to include healthy chunks of
Symfony if you really want it to be usable.

That said, I did stumble across something called "sinetja" [1] which I'd bill
as an _absolute_ micro-framework in Java in that it provides a fairly bare
bones RESTful router/API and not much else. Think of it as another data point
on the spectrum of micro-frameworks but much closer toward the bring-your-own-
everything-else half.

So, if you want to roll your own bits to interface with 3rd party libraries or
handle common tasks, use a micro-framework. If you want these decisions made
for you, don't!

[1] [https://github.com/sinetja/sinetja](https://github.com/sinetja/sinetja)

~~~
erikb
I can agree with that. A framework that does little on its own with a lot of
things to plug in. That would make sense. But the explanation in the article
got a little confusing with the first tool doing nearly everything and leaving
a big footprint.

------
nogridbag
I've toyed with both Ninja and Spark a bit in the past and have nothing but
positive things to say about them. I mainly use Spark these days when I want a
quick web app server to experiment with the JS framework of the day. Spark is
great if you want complete control over your stack. So for example I paired it
with Dagger for DI and plain JDBC for persistence. But of course it took some
amount of effort to create this initial plumbing whereas with something like
Ninja (and most other web frameworks), all this is already done for you.

~~~
this_user
Where is the advantage over using JAX-RS, CDI and JPA? All of these
technologies are available per default in any certified application server.
Since EE 6 using them is as simple as adding a minimal amount of annotations
to your POJOs. For most use cases all of this works out of the box and with
next to none additional XML configuration files.

~~~
nogridbag
It's been some time since I used JAX-RS, but with the reference impl, Jersey,
it was always a hack to use a different DI library like Guice or Dagger and
honestly that was the only problem I really had with JAX-RS. So if you mean in
comparison to Spark, then one advantage is with Spark you can use whatever DI
solution you want.

------
timclark
Ratpack - [http://ratpack.io](http://ratpack.io) is another interesting Java
micro framework.

------
aikah
meh, in most businesses you'll still have to maintain these huge struts/spring
apps. You can't call yourself a java web dev and not know all the Spring
ecosystem, so if the goal is to make things easier, well for whom? not for new
comers who'll still have to learn a bunch of legacy XML backed frameworks and
all the JEE stack.

------
CSDude
In the place I work we can deploy an enterprise Spring web application in 15
seconds, in my local machine. I truly miss those microframeworks, where a
deploy is nothing but a restart of the process. I know Spring does so much
under the hood, but those benefits do not make up for those ridicilous startup
times and deploy scenarios.

~~~
vbezhenar
Ha-ha. I worked on a project where old WebSphere Portal took 30-60 minutes to
start. And shutdown? Noone knows, admins just -KILL-ed it when they wanted to
shutdown. You better write your code without bugs. Crazy stuff. 15 seconds?
Enjoy that.

Oh, and logs. Nobody knew what happens there. Some alien life chatting about
something. May be A.I. was about to born there. Don't think about logs. Use
your own files.

And that thing actually worked and was useful to some people.

------
dikaiosune
I've looked at ninja a couple of times, and I've always been turned off by
what appears to be a lack of Gradle support and the need for a special
compilation tool chain. Whenever possible I like to keep tooling as vanilla
and commodity as possible.

EDIT: Oops! See my reply below.

~~~
vorg
By "special compilation tool chain" do you mean Maven? That's not special,
that's standard. On the contrary, I was put off by the build example for Jodd
needing Gradle to build, rather than Maven. Gradle and its bundled scripting
language are heavyweight, which goes against the whole idea of micro-framework
philosophy as described in the article, i.e. " _much of the functionality
wrapped in those [legacy] libraries is no longer really needed for most
projects. Micro frameworks are an attempt to address this_."

~~~
dikaiosune
To be perfectly honest, I was misremembering the information from this page:

[http://www.ninjaframework.org/documentation/getting_started/...](http://www.ninjaframework.org/documentation/getting_started/setting_up_your_ide.html)

As I had previously recalled, Ninja's SuperDevMode involved a bunch of
bytecode manipulation or something, but that was obviously incorrect.

Re Maven vs. Gradle, I _HATE_ XML with a burning, undying passion. It's just
my personal holy war, and while I quite like Maven, I moved to Gradle a while
ago to cut out the main source of XML anguish in my life.

 _Of course_ , a quick google indicates that that is changing too:

[http://www.infoq.com/news/2015/03/maven-
polyglot](http://www.infoq.com/news/2015/03/maven-polyglot)

I do like me some YAML. Realizing that my early-morning phone comment was from
half-memories and out-of-date information? Not so much :).

------
facepalm
Very sparse on details, unfortunately. What makes those frameworks so micro?

------
treenyc
> Java micro frameworks are an attempt to address the weaknesses of Java while
> maintaining its strengths

What about all those scripting language for java?

Jruby, Jython, Rhino, Nashorn....

------
sgt
Interesting - but people should note there's also something to be said about
the more light-weight components of Java EE 6.

For instance CDI for injection and inversion of control, plain JDBC, JAX-RS
for RESTful API's on Tomcat or Wildfly app server. Not always necessary to use
the more heavy weight technologies such as EJB, JMS, JPA (particularly the
last one should be avoided, in my opinion).

Admittedly the concept of an app server can seem antiquated to some, but it's
not necessarily a negative thing either.

They do bring useful things to the table, and can be used to build powerful
and scalable apps - microservices as well even if they run within a container.

------
davelnewton
You beat me by a couple of minutes :)

I'm no Java lover, but for some purposes (some non-technical) it's the only
real option. These seem like great ways to cut the bloat and still get stuff
done.

~~~
humbleMouse
I am curious what kind of non-technical uses for Java you are talking about?

~~~
woodman
s/purposes/political reason/g

Several years ago I faced a problem that was extremely computationally
intensive, basically the travelling salesman problem [0]. So I wrote the
solution in c, fully documented it with a nice config file for all the knobs
and the most beautiful makefile I've ever seen. When I presented the work it
was as if I had brought a dead cat into the office. They ended up using it as
a reference implementation and rewriting it in java, because "We are an Oracle
shop" after all. Unsurprisingly the java version didn't work so great, not
because java is a bad language, but because it wasn't well suited for the
specific problem - it is much more difficult to write java code that can
exercise the processor cache the was c code can.

[0]
[http://en.wikipedia.org/wiki/Travelling_salesman_problem](http://en.wikipedia.org/wiki/Travelling_salesman_problem)

------
travjones
It's funny that the author is selling the concept of microframeworks as a "new
trend." It seems that devs are moving away from monolithic frameworks in
general (no matter the language) for practical reasons, not because it's a
"trend."

~~~
JustSomeNobody
Why are you getting down voted? I don't see anything particularly wrong with
what you said.

~~~
travjones
I have no idea. Happens to me all the time on HN. :/

I still <3 you guys.

------
avodonosov
I ignore it with ease :)

~~~
avodonosov
Hey, don't down-vote this comment, down-vote the title, containing this direct
and barefaced lie! (For the record, I am a java programmer with years if daily
java coding.)

~~~
dang
Your comments are probably being downvoted because they break the HN
guidelines (they're not substantive, plus we ask people not to post comments
about being downvoted). Nevertheless you are right about the title. I'm not
sure how we missed the objectionable baity part, but it's gone now.

------
ExpiredLink
Well, you must first commit yourself to Micro-Services before you can consider
Micro-Frameworks. The Micro-Services hype currently seems disappear as fast as
it appeared.

~~~
maaaats
No, this has nothing to with micro-services. The point here is that in Java,
most frameworks are huge systems violating the "single responsibility
principle", and instead do everything. Currently, it's a movement to split
these things into smaller, reusable parts.

Heck, even Spring is looking good now. Many smaller projects, not a huge jar.

