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.
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).
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.
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.
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.
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".
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.
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.
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.
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.
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.
My 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:
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.