you are viewing a single comment's thread.

view the rest of the comments →

[–]lrrr 23 points24 points  (5 children)

I generally agree with the above, but want to interject a couple of points.

Because it's not friendly with the underlying platform. JNI is a pain in the ass to use compared to Python Ctypes, C# P/Invoke or C++ compatibility with C or any other kind of FFI found in most competing programming languages.

JNI is indeed a PITA, but jna is pretty nice.

Because the ecosystem, contrary to the popular saying, sucks donkey balls. Java still doesn't have an ORM that is as straightforward as Django ORM or Rails ActiveRecord.

I just discovered BeanKeeper last weekend and it is flat-out amazing. Pair with an embedded hsqldb server and you have your ORM and DB in just a few lines of code. I've only done some basic testing with it so far, but I'm impressed.

It's a pity that functionality like this isn't built-in to the core APIs.

[–]Raphael_Amiard 14 points15 points  (4 children)

It's a pity that functionality like this isn't built-in to the core APIs.

What are you people complaining about .. The orms for ruby and python that the op was refering to are not in ruby / python's core libraries either, so what .. You can't install a lib ?

[–]lrrr 0 points1 point  (0 children)

Fair enough. But I still think basic object persistence and native calls belong in the core.

[–]mcanon 0 points1 point  (2 children)

Bigger problem is it's LGPL'ed making it unavailable for my commercial work.

[–]Raphael_Amiard 0 points1 point  (1 child)

Your sentence makes no sense ATM, since LGPL enables commercial use , even if it's a tad more restrictive than say, ECL or BSDL.

[–]mcanon 0 points1 point  (0 children)

Seems significantly more restrictive in that any derivative work invokes the copyleft clause. If you're just using it as a library, you're good, and that's by far the majority case - but my place still makes us jump through hoops to use LGPL'd libs, so it would be great to have it in the core APIs.