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.
Java's enterprise system has actually trended towards the convention-over-configuration of RoR since it was heavily revamped as JavaEE 5 (and obviously renamed). JavaEE today is heavily dependent on meta-programming and containers like TomEE and JBoss can be built in minimal configurations.
I think Jodd is interesting in the same way NodeJS is interesting. If you're more comfortable building your framework from the ground up, you end up adding only those pieces you require. If you're happier having an entire application server at your beck-and-call, start with a full application server and (if necessary) remove what you don't need.
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.
I haven't done much with the other JVM languages except play around with them (did work with a small jython project about 10 years ago...). Have you encountered any impedance mismatch? Or weird cross language bugs?
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.
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?
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 ..
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.
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.
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.
I completely agree that much of the verbosity allows the language to express more, e.g. looking at a method signature in Java I know its visibility, what (if anything) it will return, what types I can/should pass it, and what exceptions it can throw...compare that to Ruby where the signature alone doesn't tell me any of that.
But there's also a lot of verbosity that adds no (or very little) value, e.g. System.out.println() instead of something like just println() or the several lines of boilerplate needed to run something in a new thread.
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!
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.
I just got use it on Linux via Mono and gotta say, it is a pretty nice language. I used to dismiss it because of Microsoft's influence and its being tied to thier .NET. But recently due to Microsoft open sourcing part of it, hopefully Mono will pick up some more change, and I think there is some space for server side C# on Linux.
We, another team not related to Locke1689, are bringing the CoreCLR to FreeBSD. 'Gotta prevent linuxims like #!/usr/bin/bash from infiltrating the codebase.
Discussion and project planning is happening here:
The .NET team has always been on friendly terms with the Mono team. I'd imagine the Mono devs will either keep doing their thing or will merge into the mainline at some point. There's Java VMs that are even commercial, as in people pay for them. I'd imagine that there's certainly enough space for a couple competing CLR platforms.
Merge - Xamarin are getting out of the language game and instead focusing purely on mobile. As much as possible the new MIT licensed .NET will replace pretty much all of Mono that isn't Mobile (iOS/Android/Mac) related.
Why is C++ so successful? Because it contains a lot of features. Ask random C++ developers what their favorite feature of C++ is and you will get a very wide spectrum of answers.
I see Java libraries a bit like this: they are not liked because of the number of features they have but because I definitely need some of these features, and as long as I can use them without having to understand the rest of the library, I'm good.
Guava is a very good example of this: an assortment of convenience functions from a very wide range of domains that you can use without ever having to read or understand the entire Guava documentation.
Having small libraries is pretty much a guarantee for subtle bugs because the author went for the 80%/20% approach and then moved on to the next project. Joda is a good example of that: time libraries are extremely difficult to get right, and yet getting them right is absolutely critical. I will gladly pay the price of including the entire Joda library in my application even if I use 10% of it just for the certainty that it's battle tested, something I very much doubt the collection of libraries presented here does.
I'd also add operator overloading, though that tends to go hand in hand with templates. The fact that I can write numerical code that works for say, any type that implements addition and scalar multiplication, is wonderful.
In Java, as far as I know, this would be utterly impossible, because implementation of interfaces must be explicitly mentioned. Even though Double implements addition and scalar multiplication, it could not be used in such a function because it doesn't explicitly state that it implements such an interface.
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.
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:
Spring Boot certainly makes it very easy to get started, and to grow your system in the way that Spring envisions. For getting started, there's even the Initializr:
However, as soon as you want to go off the beaten path (eg to have two databases), Spring starts to become an obstacle rather than an assistance. In this respect, it's similar to Rails or any other large, opinionated framework.
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!
I generally choose Grails (although the move to 3 is going to be a bit bumpy without all the plugins from the 2 field).
The primary deficiency I've found is startup time - when I move to other systems, I remember - oh yeah, projects can start up immediately, or in < 3 seconds, not 50. I know 3 is better in this regard, and I'm looking to migrate one project to it next month.
Grails never got the mindshare because it was jumping in to a full ecosystem. Rails, by comparison, was essentially the only game in town if you wanted to do Ruby - there weren't any other major competing frameworks.
The other big strike against Grails is... "it's different!". Most shops that are large enough to see big benefit from Grails and similar frameworks also tend to be rather stodgy and slow to change (perhaps with good reasons, but slow anyway). The sort of people who champion 'new' tech largely migrated away to completely other ecosystems (rails, node, etc). Grails/Groovy are 'different' in a scary way for "slow to change" shops, and "not different enough" for the folks who are always looking for "new/shiny" stuff to dig in to and promote. It was/is too "middle of the road", I think, to benefit from the advocacy often required for adoption. And in a crowded JVM-tech field, that hurts.
That said, it's still a great stack, and I still recommend it for many situations.
Groovy is much slower than Java, dynamically typed (even with optional typing), with spotty IDE support and with Thoughtworks recently dropping its support of the entire project, the future of the language is quite uncertain, even though it was picked up by Apache.
I would feel more comfortable picking Kotlin despite its newness: it has everything Groovy offers but it also fixes all the problems I listed above.
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.
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).
People interested in 'lightweight' Java EE should check out Adam Bien's web site: 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.
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.
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/ is a good example for Clojure.
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.
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.
Clojure lets you write code that's much closer to the problem domain, with a lot less boilerplate.
The JVM doesn't automatically mean something has to be bloated. A small Clojure web app will compile to a roughly 30 meg runnable standalone jar. That's pretty light in my book. On top of that, you get excellent performance.
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:
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.
Modern spring is amazing. Look into it. It's no longer the configuration hell it was 10 years ago. Everything is convention
Over configuration. It's easy to run and configure.
Not quite. Although i don't know C++ well enough to be sure.
Spring started life as a dependency injection framework, and that still constitutes the central part of it. Dependency injection is the mechanism by which components of an application are created and assembled, and so there was a natural expansion of Spring into providing those components. Spring now provides a web framework, plumbing for database persistence, batch processing, and all sorts of other things:
AIUI, Boost is a collection of libraries. Spring is much more frameworky than that. The general approach with Spring is to add a particular module to your project, sprinkle a few magic annotations on your code, then watch in wonder as lots of sophisticated stuff happens, exactly as Spring's designers foresaw. Usually.
There are two main alternatives to Spring. Firstly, Java EE, which is similar in spirit, smaller in extent, and the product of a decades-long standards process involving some of the world's most ponderous companies, but really not as bad as that might suggest:
And in fact, i'd describe Spring as an alternative to Java EE, rather than vice versa.
Secondly, not using a framework at all, and just putting everything together yourself. To a large extent, Dropwizard etc are the result of people doing this, then posting the reusable bits of their application to GitHub.
Java's equivalent of Boost is probably some combination of Apache Commons:
The difference is that if you're using Spring, then you are writing a Spring application. Every part of your code will be pervaded by Spring, and you will have to do things in the way Spring prescribes. If you're using Commons or Guava, your application is your own, and those libraries will crop up here and there, where you choose to use them.
They do, and I think more unsettling is the fact that they are completely serious about doing these things. The widespread use of IDEs that autocomplete probably leads to a feeling of indifference ("I don't have to type it all anyway.")
Also related is the forced convention of requiring one directory nesting level per package name component, resulting in deeply-nested mostly-empty directories that have a tendency to easily exceed filesystem limits.
Here's another ridiculous class name found in different project (AspectJ):
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.
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.
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.
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.
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?
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.
> 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?
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.
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
I have some free time today (kids stayed over at Grandma & Grandpa's last night, and wife is at an event all day), so I decided to have some fun, running with your idea to create a Twitter bot that generates “Show HN”-style headlines:
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...
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.
"Is it due to us simply wanting to reinvent things"
After observing myself and a couple of developer friends over the last few years, i can most definitely say yes. We are addicted to building our own things, creating layers after layers of abstraction, frameworks, tools, because it makes us feel like we're creating something.
What saves some of us, is to have a greater satisfaction seing someone else actually use our things, than creating that thing. And so the goal becomes more "what do people need" rather than "what would i have fun building today".
To be fair, the Java ecosystem is quite mature, whereas Go and Rust are relatively young languages, and we still need people to develop all the amenities of modern programming for those languages. Yet Another Java(Script) Framework is more deserving of that sort of comment than The First Couple of Rust|Go Frameworks of Their Kind are.
I think I can attach another insight into this. The underlying malaise is probably related to the human condition. Humans are fundamentally a medium for our collaborative works (in this context) and two factors causes these rebuilds.
1. A need to cut your teeth on a solved problem when diving in to a new category of thinking.
2. The high cost of transferring a model of thinking between two humans, especially over a vast amount of time. I think 3 years is vast compared to maybe 100 work hours to model and implement the core of a problem.
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.