3 ms·
Javax.cache: The new Java Caching Standard
- scanr 15y agoThis 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 15y agoIt's been stuck since 2001?! Any ideas why?
- fleitz 15y agoBecause 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 15y agoThe 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 15y agoIf 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".
- Nrsolis 15y agoWhat's your perfect language? I'm genuinely interested.
- fleitz 15y agoMy fav language is F# (preferred over OCaml because of VS and the #light syntax), but for webdev I usually use ruby/RoR because of the functionality available through gems. Making facebook/twitter integration work on ASP.NET MVC was more work than it should be last time I tried, and I hate all the hoops you have to jump through to make jQuery / json work with ASP.NET. Mostly I like F# because of the pipe and composition operators, inferred typing, records, active patterns, and a very succinct way of defining classes. Pipe Operator: Seq.init 100 (fun x -> x*2) |> Seq.reduce (+) Creates a sequence of numbers from 1 to 100 multiplies them by two and then adds together. Composition operator: let add x y = x+y let mul x y = x*y let addFiveMultiplyBy20 = add 5 >> mul 20 Define a class type User(firstName,lastName,email) = property x.Name.get = x.firstName + x.lastName I'm a little rusty on the class syntax so it might be off. Btw, the class that that would create would be fully generic with a requirement that the class of firstName and lastName have the (+) operator defined. So you could use the code: let user1 = new User("Foo","Bar","foo@bar.com") let user2 = new User(42,24,new EmailAddress("foo@bar.com")) As well you could do this: let (+) (x:string) (y:int) = x + y.ToString(); let (+) (x:int) (y:string) = x.ToString() + y; let user3 = new User(42,"Bar","foo@bar.com");
- 15y ago
- Uchikoma 15y agoAfter 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.
- fleitz 15y agoFully 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.
- jbooth 15y agoYup, 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).