Blade: a Java Web Framework
github.com
github.com
[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...
Though, perhaps 8 has inspired framework developers, and - more importantly! - 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.
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.
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.
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.
public User signin(String username, String password) {
String pwd = EncrypKit.md5(username + password);
return model.select().eq("username", username)
.eq("password", pwd).fetchOne();
}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)
[0] http://security.stackexchange.com/questions/38134/what-are-r...
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).
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-...
Point taken. Use SHA-? instead of MD5.
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.
I got my eye on it ever since it appeared in those Techempower benchmarks
https://www.techempower.com/benchmarks/#section=data-r11&hw=...
We are using Spark four new code in our product and we are happy with it.
I'm fairly certain there is no such thing, and parsing parameters out of the URL path has nothing to do with REST either.
But yes, other than arbitrary URL routing existing, there is nothing that makes it have a "REST" style.
(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.
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)
Like a war file?
Anyway, this API is really as terse as one can get with Java. Great developer-UX job!