4 ms·

The saddest thing is that Java never implemented support for Objective-C 'Categories' so Java programmers are forever doomed to write classes called StringUtil

The saddest thing is that Java never implemented support for Objective-C 'Categories' so Java programmers are forever doomed to write classes called StringUtil full of methods that really should be on the String class. After 20 years of Java programming this still annoys me. That and making 'byte' signed.

javajosh 11y ago
To me, the worst thing about Java is the tooling and OS integration. Compare what it takes to invoke a node program with what it takes to invoke a Java program. Or what it takes to do basic file IO in either of those. It's crazy, and it will never get better. The best Java can do is wrap everything in a build system ("just add an exec compiler plugin, configure for your main class, and invoke mvn with special arguments!") or an IDE ("just create a run config through the following 20 step process..."). It's true that if you spend a lot of time in Java these things fade into the background, but these are exactly the things that shouldn't fade. You'll never "whip up a quick script" in Java because of these problems.
- spiralpolitik 11y ago
  Java was never designed to "whip up a quick script". Today as in 1995 there are better alternatives to do that. Also Java was designed to abstract away from the underlying OS to provide "write once, run anywhere" so its "as designed" that OS integration is lacking. Personally I think the tooling is the best part of Java. Having an IDE helps you build more robust software by providing far more context than a text editor ever could. The build systems have reached the point that its very easy to do the right thing to build robust software. Compared with what came before (make, imake, configure etc) the tools are much better.
- oldmanjay 11y ago
  Sure, node CAN be faster to get going. So what? Shell scripts are even faster to bootstrap than node. Will you switch over to doing everything in bash instead? Also, yes, I whip up quick scripts in Java all the time, because sometimes it's the closest hammer to my particular nail. Your entire comment can be summed up as "I don't really understand Java, and I don't like it" which is not a terribly compelling argument.
swolchok 11y ago
Objective-C categories are a land mine. 1) You have no way of knowing that your category method isn't going to collide with another method. That method could be one of Apple's private ones, or it could be a method from a category used by another library you included in your app, or it could be even be from a category used in a jailbreak tweak. In all these cases, it's entirely possible that the colliding method doesn't have the same size arguments or return type as yours, in which case you are going to get extremely difficult to debug crashes. You also don't have guarantees around whose categories win. 2) As a class developer, you have no way of preventing categories from messing up internal guarantees of your class. Want it to be immutable? Too bad, some developer you've never talked to added methods in a category that require local state. Want to add and use a new private method? Too bad, that name is already taken by some random category, and now it looks like your code is breaking everything because it was just committed. Prefixing category methods is a partial fix, but lots of folks aren't aware that they should do that.
- LinaLauneBaer 11y ago
  Collisions are very very rare. In over 10 years of Objective-C development I have maybe seen it once. Also: clang got much better at detecting collisions at compile time (where possible). That said: Swift extensions are safer because private categories cannot collide.
  - swolchok 11y ago
    Try OBJC_PRINT_REPLACED_METHODS sometime. It's frightening. (http://stackoverflow.com/questions/9466732/in-objective-c-how-to-prevent-name-collision-in-category-methods http://stackoverflow.com/questions/9466732/in-objective-c-ho...)
  - spiralpolitik 11y ago
    This has been my experience as well.
thoran 11y ago
On the other hand, when you do have categories in a language and not the smartest people in the language's community, you do have real problems: You end up with conflicting definitions of homonymic methods because every one wants his own "toJson" crap. And everyone tries to monkey patch every other components. Ruby is plagued by this disease. Haxe and Scala (and probably many others) have a nice solution to this problem. You can add "methods" to existing classes but only you can see them. You never really change the semantic of something that does not belong to you.
- jmgao 11y ago
  Ruby is hilarious because importing a library in the standard library (or importing a library that uses it) can break division: https://bugs.ruby-lang.org/issues/2121 https://bugs.ruby-lang.org/issues/2121

javajosh 11y ago

To me, the worst thing about Java is the tooling and OS integration. Compare what it takes to invoke a node program with what it takes to invoke a Java program. Or what it takes to do basic file IO in either of those. It's crazy, and it will never get better. The best Java can do is wrap everything in a build system ("just add an exec compiler plugin, configure for your main class, and invoke mvn with special arguments!") or an IDE ("just create a run config through the following 20 step process..."). It's true that if you spend a lot of time in Java these things fade into the background, but these are exactly the things that shouldn't fade. You'll never "whip up a quick script" in Java because of these problems.

spiralpolitik 11y ago
Java was never designed to "whip up a quick script". Today as in 1995 there are better alternatives to do that. Also Java was designed to abstract away from the underlying OS to provide "write once, run anywhere" so its "as designed" that OS integration is lacking. Personally I think the tooling is the best part of Java. Having an IDE helps you build more robust software by providing far more context than a text editor ever could. The build systems have reached the point that its very easy to do the right thing to build robust software. Compared with what came before (make, imake, configure etc) the tools are much better.
oldmanjay 11y ago
Sure, node CAN be faster to get going. So what? Shell scripts are even faster to bootstrap than node. Will you switch over to doing everything in bash instead? Also, yes, I whip up quick scripts in Java all the time, because sometimes it's the closest hammer to my particular nail. Your entire comment can be summed up as "I don't really understand Java, and I don't like it" which is not a terribly compelling argument.

swolchok 11y ago

Objective-C categories are a land mine. 1) You have no way of knowing that your category method isn't going to collide with another method. That method could be one of Apple's private ones, or it could be a method from a category used by another library you included in your app, or it could be even be from a category used in a jailbreak tweak. In all these cases, it's entirely possible that the colliding method doesn't have the same size arguments or return type as yours, in which case you are going to get extremely difficult to debug crashes. You also don't have guarantees around whose categories win. 2) As a class developer, you have no way of preventing categories from messing up internal guarantees of your class. Want it to be immutable? Too bad, some developer you've never talked to added methods in a category that require local state. Want to add and use a new private method? Too bad, that name is already taken by some random category, and now it looks like your code is breaking everything because it was just committed. Prefixing category methods is a partial fix, but lots of folks aren't aware that they should do that.

LinaLauneBaer 11y ago
Collisions are very very rare. In over 10 years of Objective-C development I have maybe seen it once. Also: clang got much better at detecting collisions at compile time (where possible). That said: Swift extensions are safer because private categories cannot collide.
- swolchok 11y ago
  Try OBJC_PRINT_REPLACED_METHODS sometime. It's frightening. (http://stackoverflow.com/questions/9466732/in-objective-c-how-to-prevent-name-collision-in-category-methods http://stackoverflow.com/questions/9466732/in-objective-c-ho...)
- spiralpolitik 11y ago
  This has been my experience as well.

thoran 11y ago

On the other hand, when you do have categories in a language and not the smartest people in the language's community, you do have real problems: You end up with conflicting definitions of homonymic methods because every one wants his own "toJson" crap. And everyone tries to monkey patch every other components. Ruby is plagued by this disease. Haxe and Scala (and probably many others) have a nice solution to this problem. You can add "methods" to existing classes but only you can see them. You never really change the semantic of something that does not belong to you.

jmgao 11y ago
Ruby is hilarious because importing a library in the standard library (or importing a library that uses it) can break division: https://bugs.ruby-lang.org/issues/2121 https://bugs.ruby-lang.org/issues/2121