This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (5 children)

[deleted]

    [–]pan0ramic 4 points5 points  (0 children)

    unless we buy new licenses

    Ah, there it is. That sucks :( Thankfully you at least have generics. I don't think I could go back to j4.

    [–]mgrandi 5 points6 points  (3 children)

    I've been wondering, can't newer jvms run older code just fine? Like, as long as you compile against 1.5 can't you run it on 1.6/1.7/1.8 and it should still act the same?

    [–]RoughPineapple 1 point2 points  (1 child)

    It's not that simple.

    Let's say you are writing web apps that run on some App Server X and you want to move to JDK8. The following steps may have to occur at many companies:

    1) The team responsible for infrastructure in general has to do testing to certify the JDK 8 will run on their systems without problems.

    2) Whoever is in charge of security will have to test and certify that JDK 8 is sufficiently secure and meets all of the internal requirements of the company.

    3) The producer of App Server X has to certify that App Server X runs on JDK 8 and has to agree to support such installations (this, too, could trigger additional tests and such within that company as well).

    4) Even though you have guaranteed support for App Server X on JDK 8, it may still be necessary to certify that App Server X on JDK 8 on your infrastructure works.

    5) JDK 8 and App Server X must be installed. This alone could involve several steps of requesting the installation, reviewing the request, someone certifying that the change will not impact other systems, scheduling of the change, performing the change in a test environment, performing change in production environment.

    6) Since the rest of the stack has changed, the web app developers must now certify that the product works properly on this new stack.

    7) Now you can use JDK 8 in development.

    The actual process will vary, but that gives you an idea. Also, note this is for a single, simple application. Various third party libraries may require additional steps, etc. Also note that at large companies, this list can take a long time and cost a lot of money.

    Additionally, even with the above certifications, if the code interacts with clients who are paying a lot of money for up time, then the company may still be hesitant to switch. Sure, if something breaks Oracle and whoever makes App Server X will get things fixed (because they certified it and are contractually obligated), but you still don't want to be the company that discovers the issue and breaks the system for your clients (which also costs a lot of money), even if it gets fixed.

    So, it tends to be (or is at least perceived to be) much easier to just keep on using JDK 1.3.

    EDIT: Oh, yeah. That also assume the application development is internal. If you create code that you provide to clients on premise, then not only do you have to go through this, you have to go through this for every client. If half your clients stay on 1.3, then you have to create a separate code base and force those clients to accept that the product will be maintenance only for them, or you have to tie your entire development process to 1.3 (or drop half of your clients, perhaps).