4 ms·

None of these points are valid: 1. Dependency management is probably a lot easier with Maven than with C++ or Python. Hope that needs no reference... 2. No id

by fnl 9y ago

None of these points are valid: 1. Dependency management is probably a lot easier with Maven than with C++ or Python. Hope that needs no reference... 2. No idea why, but Java is backwards compatible. So not updating to the latest version is only laziness. 3. Having much smaller containers or virtual machine disk sizes should lower your AWS/Google/Cloud... bill a (little, but whatever) bit and therefore make your CFO happy...

misja111 9y ago
You're wrong about point 2. Java has backward compatibility but there are a few exceptions. On top of that, the library's that come bundled with the jdk have a few backward incompatibilities of their own. These might be small things to fix when your codebase is small, but for enterprises with codebases of millions of lines, these issues turn an upgrade in a major challenge. Apart from that, there is another reason why companies don't upgrade and that's because they are locked to a certain java version by their application server. Upgrading to a new java version would require upgrading the application server as well, which would cost a lot in terms of licensing and which would introduce some risks and overhead of its own.
- raducu 9y ago
  I can confirm all of what you said. That's the reason application servers AND big monolithic applications NEED to die and they need to die right now. Just have clear defined boundaries for services, deploy them inside a docker/rkt whatever container; just let whatever legacy application run with java 1.4 until you replace it completely.
  - fnl 9y ago
    Well, that is a good thing: You still can buy regular support for Java 6, which was released more than 10 years ago. So if you really think updating your monolith to Java 9 is worth less than paying for that support, you can do so. Not all software generates such a huge margin that updating it would be a viable option for your business. How many other languages provide such long-term support for releases that are a decade old, even if you were willing to pay for it?
  - he0001 9y ago
    Not saying that monoliths needs to die, but you won’t get defined boundaries just by going with microservices/Docker. And from personally updating a “monolith” to java 9 was a pretty straightforward (yes some of it entirely unrelated, were actually put in a separate container). If you did modules from the start “monoliths” could be broken down into ms if needed just by deploying them separately.
- mrighele 9y ago
  I will also add that libraries that operates at bytecode level (such as AspectJ) may be incompatible with newer JVM versions. This can be a problem since they are often used by higher level frameworks to do their "magic" (one example being Spring) [1]. The solution is that you have to update either the library (which may not be compatible with the framework using it), or the whole framework. [1] https://stackoverflow.com/questions/23801950/spring-4-and-java-8-invalid-byte-tag-exception https://stackoverflow.com/questions/23801950/spring-4-and-ja...
- fnl 9y ago
  Yet, all that is besides the point: In essence, those reasons would apply to any installation you have once you run it long enough. I.e., those particular problems are not Java-specific, and in fact, I would even dare speculate that such issues are through the bench worse in any other language than Java. ADDENDUM: Yes, C++ is technically even more backwards compatible - if your code base and all dependencies was/were 100% standards compliant (har har). But again, for me, the main point is that most newer languages first have to prove they can keep up to such levels of backwards compatibility (e.g., see the Python 3 fiasco...).

by fnl 9y ago

misja111 9y ago

You're wrong about point 2. Java has backward compatibility but there are a few exceptions. On top of that, the library's that come bundled with the jdk have a few backward incompatibilities of their own. These might be small things to fix when your codebase is small, but for enterprises with codebases of millions of lines, these issues turn an upgrade in a major challenge. Apart from that, there is another reason why companies don't upgrade and that's because they are locked to a certain java version by their application server. Upgrading to a new java version would require upgrading the application server as well, which would cost a lot in terms of licensing and which would introduce some risks and overhead of its own.

raducu 9y ago
I can confirm all of what you said. That's the reason application servers AND big monolithic applications NEED to die and they need to die right now. Just have clear defined boundaries for services, deploy them inside a docker/rkt whatever container; just let whatever legacy application run with java 1.4 until you replace it completely.
- fnl 9y ago
  Well, that is a good thing: You still can buy regular support for Java 6, which was released more than 10 years ago. So if you really think updating your monolith to Java 9 is worth less than paying for that support, you can do so. Not all software generates such a huge margin that updating it would be a viable option for your business. How many other languages provide such long-term support for releases that are a decade old, even if you were willing to pay for it?
- he0001 9y ago
  Not saying that monoliths needs to die, but you won’t get defined boundaries just by going with microservices/Docker. And from personally updating a “monolith” to java 9 was a pretty straightforward (yes some of it entirely unrelated, were actually put in a separate container). If you did modules from the start “monoliths” could be broken down into ms if needed just by deploying them separately.
mrighele 9y ago
I will also add that libraries that operates at bytecode level (such as AspectJ) may be incompatible with newer JVM versions. This can be a problem since they are often used by higher level frameworks to do their "magic" (one example being Spring) [1]. The solution is that you have to update either the library (which may not be compatible with the framework using it), or the whole framework. [1] https://stackoverflow.com/questions/23801950/spring-4-and-java-8-invalid-byte-tag-exception https://stackoverflow.com/questions/23801950/spring-4-and-ja...
fnl 9y ago
Yet, all that is besides the point: In essence, those reasons would apply to any installation you have once you run it long enough. I.e., those particular problems are not Java-specific, and in fact, I would even dare speculate that such issues are through the bench worse in any other language than Java. ADDENDUM: Yes, C++ is technically even more backwards compatible - if your code base and all dependencies was/were 100% standards compliant (har har). But again, for me, the main point is that most newer languages first have to prove they can keep up to such levels of backwards compatibility (e.g., see the Python 3 fiasco...).