Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Javax.cache: The new Java Caching Standard

gregluck.com

Post reply on HN
Print view View original

1–10 of 16 posts

Re: Javax.cache: The new Java Caching Standard

#2

Post by 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.

Re: Javax.cache: The new Java Caching Standard

#3

Post by vetler »

scanr wrote: post #2

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 - Suppor…

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

Re: Javax.cache: The new Java Caching Standard

#4

Post by fleitz »

vetler wrote: post #3
scanr wrote: post #2

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 - Suppor…

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

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.

Re: Javax.cache: The new Java Caching Standard

#5

Post by 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.

Re: Javax.cache: The new Java Caching Standard

#6

Post by fleitz »

Uchikoma wrote: post #5

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 po…

Fully agree in practice one of the best things for SQL database abstraction is an internationalization library, for when the ORM fails, or you need to tune a query.

Re: Javax.cache: The new Java Caching Standard

#7

Post by jbooth »

Uchikoma wrote: post #5

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 po…

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).

Re: Javax.cache: The new Java Caching Standard

#8

Post by jbooth »

fleitz wrote: post #4
vetler wrote: post #3

Earlier quoted context omitted.

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

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.

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.

Re: Javax.cache: The new Java Caching Standard

#9

Post by fleitz »

jbooth wrote: post #8
fleitz wrote: post #4

Earlier quoted context omitted.

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.

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 stand…

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".

Re: Javax.cache: The new Java Caching Standard

#10

Post by Nrsolis »

fleitz wrote: post #9
jbooth wrote: post #8

Earlier quoted context omitted.

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 stand…

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).…

What's your perfect language? I'm genuinely interested.
Post reply on HN