

Javax.cache: The new Java Caching Standard - codebungl
http://gregluck.com/blog/archives/2011/10/javax-cache-the-new-java-caching-standard/

======
Uchikoma
After 15 years of Java and a proponent of Java APIs I'm no longer sure this
standard APIs are a good idea.

1\. Most of them are leaky abstractions

2\. If you use them, you should nevertheless shield yourself from them (See
Uncle Bob), so you abstract over an abstraction

3\. Because of 1, you need to rewrite your app to the semantic of each
implementation of the abstraction (Portlet API, Java Content API JCR).

Case in point: You can use Derby for development and MySQL for production and
you will get into trouble as although you use JDBC, the SQL over the wire has
different syntax. And using ORM doesn't help you either (JPA), it has the same
problems just one meta-level up.

~~~
jbooth
Yup, I've never seen a designed-by-committee java API that was announced with
a list of vendor implementations be anything besides disastrous. They're
trying to sell containers as opposed to solve problems. Probably the last one
that was any good was the Servlet API. (I guess JPA is ok but it's like take 4
on that particular problem).

------
scanr
This is great. This is a pretty old, no brainer JSR that seemed to have got
stuck in committee for ages. A few highlights:

\- The standard is DI friendly (rather than just having a singleton way of
getting a CacheManager, which is how a lot of the other JSRs behave, making it
difficult to have different implementations in the same VM)

\- It's got compare and swap from ConcurrentHashMap built in, which is great

\- Support for write-through and write behind

\- There's no support for asynchronous gets / puts but that's not too
surprising.

\- It's not clear how to set a per entry expiry

It'll be interesting to see how this maps onto something like memcached.

~~~
vetler
It's been stuck since 2001?! Any ideas why?

~~~
fleitz
Because Java is designed by committee and this is a bike shed issue. It's so
simple that everyone understands it and thus no progress can be made.

~~~
jbooth
The best parts of Java were very notably not designed by committee. They were
designed by Josh Bloch, or the edu.oswego team, or maybe Gosling. The best
apache projects usually started off as written by one person or a small group.

The shitty parts, like J2EE, are designed by committee and more than that each
committee has an implementation that they're going to sell right out of the
gate. It's supposed to be a standard that solves problems, but each player has
an incentive to try and lock you in, and is more concerned with selling
software than solving problems.

~~~
fleitz
If line noise, conflation of initialization and allocation, needing to box
primitives for something as simple as an array, inability to pass functions,
inability to define operators, and inability to overload operators, are it's
best parts I'd hate to see the parts designed by committee.

Any _language_ that forces me to write

    
    
      BigNum five = new BigNum(5);
      BigNum seven = new BigNum(7);
      BigNum fiftyFive = five.add(seven).multiplyBy(five);
    

Is not something I'd worry about the "best parts". I'll leave the whole
language for enjoyment of programmers who are more "enterprise ready".

~~~
jbooth
Wow, I wish I could downvote responses to my own comment. In what way does the
standard "I'm too cool for Java" rant address the point I was making?

Yeah, type inference would be an improvement, it's also not that big a deal.

If you're dealing with integers you can quite easily do

int fiftyFive = 7*5.

And operator overloading, unless you're specifically doing numeric
computation, is usually a very bad idea. Makes you feel clever, and makes your
code unmaintainable.

~~~
fleitz
Yeah, I've coded java, around the 1.4 days. I'm not too cool for it, I just
don't care for it. Nor do I care for its philosophy. My rant addresses that
most of "the best of" java also sucks. Albiet it sucks less than the stuff
designed by committee.

I've coded erlang, but not haskell. Like both syntaxes much better than java.

Ok, point ceded on integers, now what do I do if I want to use a positive
integer in excess of 2^63?

2^63 seems like a weird cutoff to me for positive integers, but keep in mind
that features like this are the "best of" java according to you. I bought a 64
bit chip, I'd like to use more than half it's integer range.

~~~
jbooth
2^63 isn't a weird cutoff for signed integers, it's exactly what it should be
:)

Bigger than that, you're out of the range of the primitives that they coded
into the language, or into most languages for that matter, so you're going to
use to use some library construct to handle multi-word numbers. That's one of
the few cases where operator overloading might help you, but frankly if your
program is primarily doing high-end numerics, you should probably be coding in
C which is much less friendly on all counts.

I don't actually prescribe Java for web dev, strong-typed languages are
generally bad for web dev and the lack of type inference and some other
syntactical shortcuts make Java even more of a pain for that type of stuff. It
got a lot better with 1.5 on a couple of the niceties, but if what you're
doing maps better to a scripting language, use a scripting language.

As far as the philosophy goes.. as I've worked on more projects in my life
I've learned to distrust everything clever. Sometimes Java can be a bit too
restricting, and Scala seems to be an unabashed improvement in terms of
promoting better programming practice, but super clever things like monkey-
patching and operator overloading for the sake of brevity can be very
unpredictable when you need to fix a bug in someone else's code and do it
quickly.

~~~
fleitz
I'll fully agree with you on monkey patching, I think the extension method
system on .NET is a far better idea.

Operator overloading can be used stupidly but then again so can just about any
feature. Operator overloading is no more clever than method overloading.

~~~
jbooth
Well, I guess we just disagree on the operator overloading.. I agree that it's
fundamentally the same in one sense, but in another sense it's much more
likely to sneak up on you than method overloading, especially if you're in an
environment that doesn't allow monkey-patching. It's always fairly obvious
which version of collection.add() you're invoking, and can be much less
obvious which version of '+' you're invoking. IMO you need a much bigger
productivity win to justify operator overloading, and aside from numerics,
it's usually not there.

