Blade: a Java Web Framework(github.com)
github.com
Blade: a Java Web Framework
https://github.com/biezhi/blade
14 comments
Looks like simpler Java frameworks are on the rise now (http://www.pippo.ro/, http://sparkjava.com/, http://www.rapidoid.org/)
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.
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.
About time. Since the advent of java 8 the platform is rejuvenating. This is clearly an example of that.
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?
Though, perhaps 8 has inspired framework developers, and - more importantly! - attracted a more adventurous userbase?
> 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.
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.
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.
You can add this one to the list: http://www.takes.org/
As well as Jodd [0], Play [1] and many more [2, 3].
[0] http://jodd.org/
[1] https://www.playframework.com/
[2] http://www.gajotres.net/best-available-java-restful-micro-fr...
[3] http://www.javaworld.com/article/2995526/developer-tools-ide...
[0] http://jodd.org/
[1] https://www.playframework.com/
[2] http://www.gajotres.net/best-available-java-restful-micro-fr...
[3] http://www.javaworld.com/article/2995526/developer-tools-ide...
Play is not minimalistic like Jodd, Spark, Rapidoid, Pippo, Take (that is the name even though the domain name is takes.org) are.
Very happy to see this trend catch up with Java.
I can vouch for Dropwizard. Have used in a few tier-1 services and it has worked out fabulously well.
http://www.dropwizard.io/0.9.1/docs/
http://www.dropwizard.io/0.9.1/docs/
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".
JAX-RS has a nice API without much boilerplate and it is more powerful than most "micro web frameworks".
Then you will like JSR-371. This is extending JAX-RS to deal nicely with routing to HTML templates.
https://jcp.org/en/jsr/detail?id=371
https://jcp.org/en/jsr/detail?id=371
Which is why my favorite "micro"-"framework" -- is Dropwizard, which is fully JAX-RS.
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.
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.
> 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.
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.
JAX-RS is just a specification, but implementations of it are not that fast, compared to other Java frameworks.
hmmm...
public User signin(String username, String password) {
public User signin(String username, String password) {
String pwd = EncrypKit.md5(username + password);
return model.select().eq("username", username)
.eq("password", pwd).fetchOne();
}If you haven't already, you should consider opening a pull request.
You mean: as framework creator you should make your documentation reflect the latest security standards right? Just to make sure.
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.
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)
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)
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
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
The password store in Yesod contains nice documentation about how it works. I found it very enlightening and reassuring to read:
https://github.com/yesodweb/yesod/blob/master/yesod-auth/Yes...
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.
Point taken. Use SHA-? instead of MD5.
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.
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.
:-) Bcrypt it is then.
Yep. SHA-256 is a good bet at the moment, or SHA-3 if it's an option.
Not really, bcrypt is the only bet, SHA-256 is also too fast
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.
That's right, I wrote what I used in the past
MD5 is cheap enough to brute force now that we're talking "moderate annoyance" instead of "heat death of the universe" territory.
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...
[0] http://security.stackexchange.com/questions/38134/what-are-r...
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).
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).
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.
Okay so the original comment was probably about cracking MD5's then. Thanks for clarification as this was not clear from the original comment.
Gotta love them securitie
I'm always puzzled when no one mentions Undertow in this sort of threads
I got my eye on it ever since it appeared in those Techempower benchmarks
https://www.techempower.com/benchmarks/#section=data-r11&hw=...
http://undertow.io
I got my eye on it ever since it appeared in those Techempower benchmarks
https://www.techempower.com/benchmarks/#section=data-r11&hw=...
http://undertow.io
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.
We are using Spark four new code in our product and we are happy with it.
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.
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.
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
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...
> 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.
I'm fairly certain there is no such thing, and parsing parameters out of the URL path has nothing to do with REST either.
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.
But yes, other than arbitrary URL routing existing, there is nothing that makes it have a "REST" style.
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.
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.
(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.
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.
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.
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)
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)
>but the real game-changing feature is that you get a single "executable jar" artifact for deployment
Like a war file?
Like a war file?
none actually.
I think these kind of frameworks essentially reduces lot of boiler plate code. Your code might look a bit cleaner.
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!
Anyway, this API is really as terse as one can get with Java. Great developer-UX job!
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.
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?
It's hard to synchronize: http://github.com/tinspin/rupy
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.
I love Java and I love playing with lightweight Java frameworks.
Seems nice. Apparently Apache Licensed as well.
[deleted]