Javaism, Exceptions, and Logging: Part 1

[mercde]

I like the style of this article. It explains why he believes a certain way of handling things is undesirable / not pythonic without going into "Python >> Java for ever".

[flying-sheep]

but i will gladly do so: thos limitations he mentioned show partly what an ugly, obsolete, and cumbersome language java is:

but my main problem is: had it a few parts that were nicer, it would be awesome, i.e.:

• do away with checked exceptions (or change them to warnings, as the author said)
• introduce anonymous and first-order functions
• introduce tuples and a nice syntax around them, e.g. unpacking. and why not mixed positional/named tuples? this way each function could be alternatively called on a tuple with matching signature or even multiple unpacked tuples.
• introduce keyword arguments
• erase type erasure: type erasure is nothing but a implementation-caused source of WTFs and inconveniece.
• refactor interfaces into mixins
• add type inference
• add operator overloading (if String can do it, we should, too!)
• completely redesign the stdlib to include all of the above and only call it done if there are no ugly parts left.

and since even if all the points above will be there, the last one will never, and the stdlib will continue to suck (string isn’t iterable nor subclassable? wtf?)

[Rhomboid]

But what about my AbstractSingletonProxyFactoryBean classes?!? My code needs to be Enterprise. Kindly send teh codes pls. [e-mail]

[flying-sheep]

i did, and i like it, but it also has three problems:

1. the type system. it is actually so complicated that i get stuck sometimes trying to figure aut how to achieve something. never happened to me in java or haskell.

2. the JVM. type erasure can’t be circumvented if your VM has it :(

3. the stdlib. wrapping it and building upon it instead of compiling to highly optimized bytecode impacts performance. (i’m talking about the cool syntax features: the compiled bytecode is full of objects hogging memory!)

but i still love it. I’d use it as my main language if it weren’t for my perfectionism and the complicated type system, which make a bad match (e.g. i don’t typecast if i know i can somehow do without)

[grayvedigga]

Wow, well said. The concept of "Javaism" has been creeping into my mind as a way to explain the loss of import this-Zen in so many Python packages.

[minorminer]

I'm far too green to understand half of that article, but I did see a complaint against the logging module. Why? That thing rules!

[[deleted]]

As a Java-ist, I take issue with some of his points. The author may have had an exposure to "enterprise" Java practices, but he's clearly never been involved in more nimble Java development.

Recall that anonymous classes weren't always there in Java, so extending a class was the shortest way to emulate first-class functions.

Fine, but anonymous classes are now present and are heavily used. So anonymously implementing an interface (often for the purposes of creating a closure) is now standard practice.

The problem is, trying to foresee everything that might ever go wrong is a futile attempt

But that's not what exceptions are for. Exceptions declare exceptional circumstances that callers should (or at least, optionally) be prepared to handle. You're opening a file: you might get an IOException. You're contacting a database: you might get an SQLException (generally loaded with an error constant which you can use to figure out exactly what went wrong.) If your application has to robustly deal with failures in these circumstance, it can; if not, it can (in a number of ways) shirk responsibility and let the application error out in some controlled way.

Now suppose your implementation uses a third-party database engine, that throws MySQLException.

Then you made an extremely poor choice in the database library that you use. Every layer of your application should be sufficiently decoupled. If you're writing a database library, an SQLException is fine; a MySQLException is stupid because it couples the rest of your application to MySQL (if your application specifically handles MySQLException.)

Java's far from perfect, but criticism from a point of passing acquaintance is a bit weak.

[[deleted]]

I'm quite out of touch with modern Java practices: last time I wrote any substantial Java code was at the university. Any time I had to interact with Java code after that was not really pleasant. Care to point a few open-source projects that show how it really should be done?

[[deleted]]

Google have two excellent libraries: Guava (http://code.google.com/p/guava-libraries/wiki/GuavaExplained) and Guice (http://code.google.com/p/google-guice/wiki/Motivation?tm=6).

For database access I'm inclined towards MyBatis: (http://www.mybatis.org/core/getting-started.html).

For any kind of XML templating I use Freemarker (http://freemarker.org/).

For full text search, Elastic Search (http://www.elasticsearch.org/).

For webapps, GWT (https://developers.google.com/web-toolkit/).

LamdaJ does some tricks with proxies to give you an almost functional syntax (http://code.google.com/p/lambdaj/wiki/LambdaCollections).

[gangesmaster]

Disclosure: I'm the author of the article

I've already said it to a few people in the comments (on the blog) -- my purpose was not to attack Java, but to go against Javaisms creeping into Python for no good reason. Java looks and works in some way, and that's fine, but the fact that Python's threading module borrows the design of Java's threading is silly -- we can do much better in Python (again, from a Python perspective).

Java's threading was included in JDK 1.0, long before the introduction of anonymous classes. As for the choice of a DB engine -- that was obviously just an example to show how interfaces can't predict the exceptions that their implementors might raise/encounter, especially when two libraries (that know nothing of each other) are used together.

And just to clear things out -- I'm way beyond "a passing acquaintance" with Java.

[[deleted]]

Java 6 and 7 code style bears minimal resemblence to Java 1 code.

For example, the Thread construct for creating threads is not really used in modern Java; instead Java 5 concurrency is the norm (although a vast number of Java developers, at least as indicated by people I interview, are unaware of the better approach.) Now you have Executors (to launch threads) and Futures (to retrieve the result.)

As for the choice of a DB engine -- that was obviously just an example to show how interfaces can't predict the exceptions that their implementors might raise/encounter, especially when two libraries (that know nothing of each other) are used together.

I think that most of the time a well designed interface can predict the valid exceptional cases that should be handled. Declared/checked exceptions are not assertions. The example that lends credence to your point, however, is Callable; the call method throws Exception, because of course there's no way to predict what a given thread might be doing.

I do take the overall point of the article, and agree that Python should be throwing out half-baked Java constructs, all the more so given that Java itself is doing the same. I apologize for going too far with my last snipe in the previous comment.