HN Explorer

60 comments

[ 0.21 ms ] story [ 140 ms ] thread
eitland
Seems nice. Apparently Apache Licensed as well.
reactor
Looks like simpler Java frameworks are on the rise now (http://www.pippo.ro/, http://sparkjava.com/, http://www.rapidoid.org/)
moondowner
You can add this one to the list: http://www.takes.org/
edem
About time. Since the advent of java 8 the platform is rejuvenating. This is clearly an example of that.
hyperpallium
Is it? You could write a sinatra-like microframework in java a long time ago (I did). Just use methods instead of lambdas.

Though, perhaps 8 has inspired framework developers, and - more importantly! - attracted a more adventurous userbase?

edem
At least I feel like. 8 brought some really needed upgrades (for example we have a new form of multiple inheritance). It is not perfect but I think with the Stream api and the lambdas they simplified things enough for people to at least give it a try.
frostmatthew
> attracted a more adventurous userbase?

That statement seems accurate without "a more adventurous" - I think with Java 8 more people are using Java because they want to instead of because they have to.

e.g. professionally I've used Java more than any other language, it's hands down the language I'm most familiar/comfortable with, yet when I start a side project for myself I've never considered using Java (usually using Ruby or Scala). With Java 8 removing many warts and bringing in a lot of great improvements I'd actually consider using it for a side project.

haylem
I'm not sure I would consider it on the rise or a recent trend, considering we had a all sorts of these things over the past 6-7 years already (and more, if you include other JVM languages in the mix).

It sure is nice to see a bit of competition though. But I'm a bit afraid of too much fragmentation and proliferation, when sometimes fixing or improving good frameworks might be time better spent. It was (and still is) a bit annoying when every week brings about a dozen new web frameworks, a new UI toolkit, a new stack acronym, etc...

Oh well... I guess you can't really tell what's time well spent, and you can't really product how frameworks will compete and improve evolutionarily.

dodyg
hmmm...

public User signin(String username, String password) {

    String pwd = EncrypKit.md5(username + password);

    return model.select().eq("username", username)

    .eq("password", pwd).fetchOne();

}
tluyben2
You mean: as framework creator you should make your documentation reflect the latest security standards right? Just to make sure.
onion2k
I think dodyg's point is more that someone using MD5 as a password hash is unlikely to have created a modern, secure, well-designed framework. If there's a problem as significant as poor password security then there's very likely to be other more subtle problems as well.
mikkom
As I'm not up to the current security research, what is problem with using md5 hash of name+password? Is the missing salt problem you are refering to?

Brute forcing md5 is easier than some other hashing algo because of collisions?

(And I would disagree that knowing that how to properly hash passwords means that the whole framework itself is poorly designed)

jfim
MD5 is pretty cheap to compute. According to this Stack Exchange post[0], a GPU can do billions of hashes per second, so a short/weak password would be quickly cracked.

[0] http://security.stackexchange.com/questions/38134/what-are-r...

mikkom
If someone has local access then it's easy to crack any passwords (of any hashing algo). However if the cracker has local access and/or full access to DB then weak password hashing is one of the least problems..

Making password checking slower is very easy if the cracker doesn't have local access. Just sleep for XXX ms at every hash check and double it for every incorrect attempt (per IP).

superuser2
Password hashes are stolen in a variety of ways, when attackers find a way to dump arbitrary files or get results of arbitrary SQL strings, even one byte at a time. Yes, if that happens the site is toast, but 99% of its users have used that password somewhere (everywhere) else. That's not your fault, but using a better hashing algorithm is so trivial that it makes you an asshole to betray your users like that.
mikkom
Okay so the original comment was probably about cracking MD5's then. Thanks for clarification as this was not clear from the original comment.
superuser2
MD5 is cheap enough to brute force now that we're talking "moderate annoyance" instead of "heat death of the universe" territory.
onion2k
Speed is the problem. ocl-hashcat can test in the region of 6 billion MD5 hashes a second on a decent GPU. With a random salt and, say, an 8 character password it'd take a long time, but not so long it's impossible. On a site that includes rules like 'Must have an uppercase letter', 'Must include a number', and 'Must include a special character' you actually reduce the size of the space and consequently make the password easier to brute force. With those rules in place there's 159,655,911,367,680 possible passwords[1], so brute forcing at 6 billion hashes a second it'd take just over 7 hours. Maybe double that for the overhead of adding in the salt and managing the list of attempts, etc.

The point is it's achievable. If someone gets a dump of the database it can be turned back in to usable accounts. If you use something much slower they can't. There's no benefit to using MD5. On the other hand, using a better hashing algorithm protects user's passwords from brute force attacks. Why wouldn't you want that?

Quite a good article about cracking a well designed database of bcrypt'd passwords - http://arstechnica.com/security/2015/08/cracking-all-hacked-...

[1] From http://math.stackexchange.com/a/410885

mikkom
Okay I understand this much better now. I was assuming this was about remote access exploit not a local one.

Point taken. Use SHA-? instead of MD5.

onion2k
Yep. SHA-256 is a good bet at the moment, or SHA-3 if it's an option.
franciscop
Not really, bcrypt is the only bet, SHA-256 is also too fast
mudetroit
If we are going to be correct about this then let's actually be correct and not just say bcrypt is the only bet. You want a system that manages work rate. Off the top of my head that also includes scrypt and pbkdf2.
franciscop
That's right, I wrote what I used in the past
PeCaN
No! Use a proper key-derivation function (bcrypt, scrypt, pbkdf2), not a hash function.

SHA family, including the rather unrelated but exceptionally nifty SHA-3 (Keccak), are still hash functions and are still really fast to compute (good if you need to verify the contents of something, bad if you need to store secure information). A decent GPU can still crack SHA hashes effortlessly, and a dedicated attacker will have some good FPGAs (in which case you'll be cracked in hours). Use a function that is meant for storing passwords.

mikkom
:-) Bcrypt it is then.
sah2ed
If you haven't already, you should consider opening a pull request.
memonkey
I love Java and I love playing with lightweight Java frameworks.
dmacvicar
I fail to see the difference with http://sparkjava.com

We are using Spark four new code in our product and we are happy with it.

tluyben2
It would be the forever (especially in Javascript frameworks); why don't more people combine forces instead of doing their own thing? But then coders have opinions which do not fit the other frameworks (like they don't like the deps or coding style or usage patterns) and then they roll their own while the alternatives are perfectly fine for most.
debarshri
I have been using spark since 2013. One thing that I see that this framework provides in DSL for DB like operations. In spark you have to configure out of the box
atonparker
A very important one I can see is that Blade targets back to Java 6, whereas Spark only targets Java 8. This makes it available on slow moving platforms like Google App Engine.
sscarduzio
No offence, but this is basically the poor man's Finagle. Except Finagle is Netty based, and this is Jetty based.

Anyway, this API is really as terse as one can get with Java. Great developer-UX job!

dangoldin
That's the first thing I looked at - whether these were Netty based. We've been using raw Netty for our core application and it's been amazing.
sbanach
Quick question: What's the draw of using Netty vs pure java.nio? The latter (Selectors, Socket/DatagramChannels, ByteBuffers etc) seems reasonably straightforward to use, so I've never really looked at a framework - am I missing out?
cryptos
I'm a bit tired of these sinatra like web frameworks these days. Repetitive url patterns are not that elegant. Why not simply building the API around the fundamental REST concept, the resource? And what about proper content negotiation?

JAX-RS has a nice API without much boilerplate and it is more powerful than most "micro web frameworks".

pron
Which is why my favorite "micro"-"framework" -- is Dropwizard, which is fully JAX-RS.
shadowfox
> JAX-RS has a nice API without much boilerplate and it is more powerful than most "micro web frameworks".

This is true. But it is usually much more intimidating for people starting out though. What the micro-frameworks offer is a quick turnaround time.

xaduha
JAX-RS is just a specification, but implementations of it are not that fast, compared to other Java frameworks.
true_religion
I suppose it's because if your legacy products are already built with what's essentially a HTTP-RPC protocol, you're not going to want to build a REST-inspired framework.

I think REST is like the 3rd normal form of databases. In theory it's great, but in practice people only try to get close enough to the abstraction.

gd78
Could someone please explain me where the benefit is over using some embedded tomcat/jetty, weld, jersey, hibernate/jdbc? Setting up such a project cost me 30 min and gives me full flexibility choosing the stack I need for my project.
debarshri
none actually. I think these kind of frameworks essentially reduces lot of boiler plate code. Your code might look a bit cleaner.
atomashpolskiy
Speaking from my experience, benefit accumulates with the increasing number of applications under your authority, esp. in case each of these applications is some variation of CRUD Web Forms / Report Generation / Data Processing & Migration (read: typical enterprise environment) and shares most of its' dependencies with other applications, while still having a unique configuration.

In such environment, having the means to create a vanilla project configuration and then extend/customize it a tiny bit for each app is immensely helpful.

Now, of course, this can be achieved without bootstrapping frameworks, but the real game-changing feature is that you get a single "executable jar" artifact for deployment:

- VERY convenient and straightforward to use with containers such as Docker

- if you don't use Docker, 100 jars are still easier to maintain than, say, a cluster of 100 Jetty instances

- possible to use CLI commands to run short-living daemon jobs; no need for a separate job infrastructure (schedulers, triggers, executors and such), just use shell & cron

Besides that you usually get:

- pre-packaged health-check and monitoring tools

- if bootstrapping framework is popular enough: community support for plug-and-play modules/plugins that leverage some particular framework/technology (e.g. Bootique framework is an excellent example of modular approach: https://github.com/nhl/bootique)

eip
>but the real game-changing feature is that you get a single "executable jar" artifact for deployment

Like a war file?

alimbada
Looks like NancyFx. After having worked a little with Java/Spring recently and coming from a C#/.NET background it's nice to see the Java world is finally starting to discover the benefits of Keeping It Simple...
mindcrash
If you'd like a micro framework with batteries included, but still want to be able to completely switch stuff around as you go http://jodd.org/ is really worth a look, I think.
[deleted]
(comment deleted)
ilamparithi
It's good that they are targeting from Java 6. Most of these latest micro frameworks only supports Java 8. Will be really helpful for people who are stuck with Java 6/7.
cname
> REST style routing interface

I'm fairly certain there is no such thing, and parsing parameters out of the URL path has nothing to do with REST either.

paulddraper
Sort of. URL "routing" is necessary for REST, as opposed to an RPC (or GraphQL) style POST to a single URL.

But yes, other than arbitrary URL routing existing, there is nothing that makes it have a "REST" style.

cname
REST only requires uniquely-identified resources. There's nothing in that stopping you from having a single endpoint that takes query parameters to identify those resources.
paulddraper
Yes, but that doesn't invalidate what I said. It still counts as "routing" on the request URI.

(Instead of, say, routing to application logic primarily based on a header or the entity like GraphQL).

There's zero difference between path and query string, other than one is meant to be hierarchial and the other is not.