3 ms·

My understanding is that the vast majority of Java development is done in shops where conformance to coding and pattern "standards" is valued as a way of allege

My understanding is that the vast majority of Java development is done in shops where conformance to coding and pattern "standards" is valued as a way of allegedly making the code base easier to read and understand (I am not agreeing with this, just stating what I believe they believe). If my understanding is correct, which shop is going to allow people to start using these new techniques, when they already have a code base full of workarounds? Unless someone is going to sit down and refactor their humun-gi-normous code base, they will in effect be creating a second dialect of Java in their shop if they start using traits and closures instead of whatever they were already doing with Java's existing feature set. I just can't see this having any more than a token impact. Now Java users can say, "Sure we have closures. We don't use them here, but they exist and if we wanted to, we could use them. But we don't need them, so it's no big deal."

spullara 16y ago
I think the question here is whether or not it will defend against wholesale abandonment of Java to things like Scala and Clojure. To make the complete switch you might have to rewrite some code. With the Java improvements you can even keep a lot of your old code designed to work with inner classes and just use that code more effectively with the new closure and method handle syntax and implementation. There are many shops that probably haven't fully adopted generics from Java 5 in their own code but they benefit from the libraries that have moved to them.
Sandman 16y ago
Why wouldn't they use closures and other new stuff in Java? It's the same like it was with generics - prior to 1.5 we used raw types with casting, but when generics were introduced we started using them instead. When you encounter some older code in your codebase that still uses raw types instead of generics, you just rewrite that portion of code. No problem with that. I mean, couldn't your point be made about any language that introduces new features? When that happens, do developers decide to rewrite the entire codebase? I don't think so.
- TeHCrAzY 16y ago
  Do you really rewrite working and tested code just to use new or more convenient features of the language? I don't see that being a good option, nor one that most developers would take.
  - jabits 16y ago
    You bet! Every chance I get. If I am in a section of code for some sort of change, I will definitely take the opportunity to update/improve the current state of affairs. Doesn't mean you need to go through and rewrite the entire thing. For example, a recent requirement of mine was to revise some xml processing to create sitemaps. As part of the changes, I rewrote the logic to use xml LINQ (c#) and the resulting function is much cleaner, and will be easier to maintain going forward. It also makes routine maintenance changes more palatable.
  - Sandman 16y ago
    If your code is covered with tests, why would you be afraid of rewriting it?
    - fizx 16y ago
      Hah!
  - gnaritas 16y ago
    If the semantics are identical, you don't need to rewrite them, a good IDE will do that for you with a simple code reformat whenever you happen to be doing work in that file.
mquander 16y ago
Well, you could use the same argument against any feature at all! Besides, I can point at zillions of Java applications that are not written by huge mystery corporations with legions of slaving programmers. There's no point holding back on improving a language just because you think some people might refuse to use your improvement.
- raganwald 16y ago
  I applaud your optimism and suspect we see things for ourselves in a similar light. However, every improvement of this sort added to a language is like a feature added to a product. It is not "free:" It increases the surface area of the language, requiring programmers to learn more to use it. Every "improvement" must be analyzed in light to whether the benefits outweigh the costs. My conjecture is that the costs will outweigh the benefits for the kilo-jillions of shops that are "mystery corporations with slaving programmers," as you put it. As an aside, I think that the complexity of the language is already getting out of hand. Although features like this can be found in "little" languages like Javascript, they were in from the beginning and form part of the language's substrate. Libraries, frameworks, everything a Javascript user touches will make use of anonymous functions with lexical scope. More complex features are built on these features. This matters because when a programmer learns how a function works in Javascript, he learns how everything works. Whereas when adding the same feature to Java, it's just being bolted on the side. So when a programmer learns how these new so-called closures work, all he learns is about a feature that isn't being used as a component of anything else, it's just a feature. We add complexity but get very little in return, much less than from the same feature in a language like Javascript. I am not trying to get into a flame-fest over Java, but I do think that there comes a time when any product matures, and "improvements" should be viewed with extreme caution because the product has reached a point of greatly diminishing returns. I suggest that Java is in that place.
  - ebiester 16y ago
    Undoubtedly, there will be maintenance projects that will develop this attitude, the places I've worked usually took a while to move to a new version, but once they moved they had no problem integrating the new features. Essentially, this will replace the horrible callback syntax we have and have been using for a while. The new features will be integrated slowly, but they will be used.
RickRoll 16y ago
Maybe you should go read Corporate Drone News instead :D /jk As ppl move along they learn new things. New patterns, language features, hacks appear. It's INSANE to think you can't do something differently without changing all the old code.

spullara 16y ago

I think the question here is whether or not it will defend against wholesale abandonment of Java to things like Scala and Clojure. To make the complete switch you might have to rewrite some code. With the Java improvements you can even keep a lot of your old code designed to work with inner classes and just use that code more effectively with the new closure and method handle syntax and implementation. There are many shops that probably haven't fully adopted generics from Java 5 in their own code but they benefit from the libraries that have moved to them.

Sandman 16y ago

Why wouldn't they use closures and other new stuff in Java? It's the same like it was with generics - prior to 1.5 we used raw types with casting, but when generics were introduced we started using them instead. When you encounter some older code in your codebase that still uses raw types instead of generics, you just rewrite that portion of code. No problem with that. I mean, couldn't your point be made about any language that introduces new features? When that happens, do developers decide to rewrite the entire codebase? I don't think so.

TeHCrAzY 16y ago
Do you really rewrite working and tested code just to use new or more convenient features of the language? I don't see that being a good option, nor one that most developers would take.
- jabits 16y ago
  You bet! Every chance I get. If I am in a section of code for some sort of change, I will definitely take the opportunity to update/improve the current state of affairs. Doesn't mean you need to go through and rewrite the entire thing. For example, a recent requirement of mine was to revise some xml processing to create sitemaps. As part of the changes, I rewrote the logic to use xml LINQ (c#) and the resulting function is much cleaner, and will be easier to maintain going forward. It also makes routine maintenance changes more palatable.
- Sandman 16y ago
  If your code is covered with tests, why would you be afraid of rewriting it?
  - fizx 16y ago
    Hah!
- gnaritas 16y ago
  If the semantics are identical, you don't need to rewrite them, a good IDE will do that for you with a simple code reformat whenever you happen to be doing work in that file.

mquander 16y ago

Well, you could use the same argument against any feature at all! Besides, I can point at zillions of Java applications that are not written by huge mystery corporations with legions of slaving programmers. There's no point holding back on improving a language just because you think some people might refuse to use your improvement.

raganwald 16y ago
I applaud your optimism and suspect we see things for ourselves in a similar light. However, every improvement of this sort added to a language is like a feature added to a product. It is not "free:" It increases the surface area of the language, requiring programmers to learn more to use it. Every "improvement" must be analyzed in light to whether the benefits outweigh the costs. My conjecture is that the costs will outweigh the benefits for the kilo-jillions of shops that are "mystery corporations with slaving programmers," as you put it. As an aside, I think that the complexity of the language is already getting out of hand. Although features like this can be found in "little" languages like Javascript, they were in from the beginning and form part of the language's substrate. Libraries, frameworks, everything a Javascript user touches will make use of anonymous functions with lexical scope. More complex features are built on these features. This matters because when a programmer learns how a function works in Javascript, he learns how everything works. Whereas when adding the same feature to Java, it's just being bolted on the side. So when a programmer learns how these new so-called closures work, all he learns is about a feature that isn't being used as a component of anything else, it's just a feature. We add complexity but get very little in return, much less than from the same feature in a language like Javascript. I am not trying to get into a flame-fest over Java, but I do think that there comes a time when any product matures, and "improvements" should be viewed with extreme caution because the product has reached a point of greatly diminishing returns. I suggest that Java is in that place.
- ebiester 16y ago
  Undoubtedly, there will be maintenance projects that will develop this attitude, the places I've worked usually took a while to move to a new version, but once they moved they had no problem integrating the new features. Essentially, this will replace the horrible callback syntax we have and have been using for a while. The new features will be integrated slowly, but they will be used.

RickRoll 16y ago

Maybe you should go read Corporate Drone News instead :D /jk As ppl move along they learn new things. New patterns, language features, hacks appear. It's INSANE to think you can't do something differently without changing all the old code.