Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We were migrating from Java 6 to Java 7. The project is behind schedule and risks being dropped, in which case it will continue to use Java 6.

What are the specific improvements in Java 7 that we could go back to our manager with and convince him it is important to use JDK 7? Looking for bug fixes that I could highlight in Oracle Java 7 (with respect to Java 6). Fixes in security, performance, Java 2D/printing, etc. will be more sellable in my case. Compiler fixes for example, will not of much use.

[I am going through many sites like Oracle adoption guide, bug database, questions on Stack Overflow].

Update: Thanks for the answers. We rescheduled the update to next release. Closest we got was security. Accepting the highest voted answer.

share|improve this question
4  
You're lucky. Juding from the questions that still regularly pop up on Stack Overflow, some people are still stuck with Java 1.4 (a platform that's 11 years old!). –  Joachim Sauer Jul 16 '13 at 5:14
3  
Why are you doing the upgrade now if you don't already know of some features in 7 that you need? Maybe you are wasting your time and should think about bit more about whether you should justify it rather than how you should justify it. –  Bryan Oakley Jul 16 '13 at 10:51
1  
Is it just me or is the title backwards ? –  Radu Murzea Jul 16 '13 at 15:08
1  
The bigger question is: Why are you having such a hard time upgrading? I was able to upgrade a million loc project in a week to Java 7. I think the answer to your problems is analyzing why you are having such a hard doing the upgrade. –  Andrew Finnell Jul 16 '13 at 15:09
2  
@ Andrew Finnell : Sorry. I did not think it was that relevant. The actual porting was completed in less than a week. Mainly due to sun proprietary api's we used. It was a function specific compatibility affected code than actual number of lines of code( 4million approx). The delay caused was due to various factors like tools support- For example code coverage using cobertura 2.0. is just stabilizing. Another tool was Rational Functional Tester which required an upgrade (we chose not to do). May be I will write a note on overall factors affected the effort.. –  Jayan Jul 16 '13 at 15:16

4 Answers 4

up vote 36 down vote accepted
+50

Java 6 has reached EOL in February this year and will no longer receive public updates (including security) unless you buy very expensive enterprise support.

That should be all the reason needed.

Besides, overwhelming evidence suggests that backwards compatibility for Java runtimes is excellent. Chances are that you just have to replace the Java 6 installations with Java 7 and all applications will just continue to work without any problems. Of course this is not guaranteed and extensive tests are recommended to confirm that there will indeed be no problems.

share|improve this answer
2  
that should be an accepted answer. EOL-date based reasoning has proven to work best for me whenever there was a need to justify particular product updates, particularly including Java. To complete justification, I would also add the note about backward binary compatibility (preferably backed up with some official Oracle statement) and a note about the need to smoke test the update (for the case of eg some unexpected dependencies on hardcoded references to version "6" in application configs) –  gnat Jul 16 '13 at 7:41
1  
it's basically the only reason most companies will upgrade. –  jwenting Jul 16 '13 at 7:56
    
Michael, would it make sense to add notes I mentioned (clarifications on compatibility and smoke testing) into your answer? for the sake of completeness so to speak –  gnat Jul 16 '13 at 14:17
1  
@gnat: done, though I doubt the people who are against the migration need to be told about the need for testing and rather more than just smoke tests, too. There most definitely are sometimes serious incompatibilities. –  Michael Borgwardt Jul 16 '13 at 14:58
    
@MichaelBorgwardt well, telling about that is somewhat tricky thing and it has more to do about being compelling rather than technically correct. I for one learned rather hard way to state stuff like that explicitly and clearly when there are guys "aginst the change". This kind of sends them signal, "we listen and share your concerns, and we worry too", makes them feel valued (as opposed to ignored)... and eventually leads to easier approval of the change :) –  gnat Jul 16 '13 at 15:05

In general, there are a number of fairly broad changes to make things easier on the programmer. Your manager might not care too much about such things, but making programmers spend less time thinking about boilerplate code, and thus have more time to think about the actual goal of what they're implementing, should increase efficiency, decrease bugs, etc., which can be a very powerful argument. Oracle has a fairly extensive list of changes, but it's rather lengthy, so I'll summarize as much as possible.

Language features include:

  • Less boilerplate on Generics. The code Map<String, String> myMap = new HashMap<String, String>(); can be reduced to Map<String, String> myMap = new HashMap<>(). The compiler can infer the Generic types needed on the right side from the left, so your code gets a little shorter and quicker to read.
  • Strings work in switch statements now, using the semantics of the .equals() method instead of ==.
  • Automatic resource management using try-with-resources. This makes code cleaner, but also has an advantage over old-style try/finally-based code. If an exception is thrown in the try statement, and then another is thrown while closing, code which uses traditional try/finally statements will completely lose the original exception, and only pass up the one which was thrown in the finally block. In a try-with-resources statement, the runtime will suppress the exception that the close() calls threw, and bubble the original exception up the stack, under the assumption that this original exception is the one that caused all the problems in the first place. Additionally, instead of abandoning the other exception to the garbage collector, this suppression allows the close-thrown exceptions to be retrieved using Throwable.getSuppressed.
  • Numeric literals can be made easier to read. All numeric literals allow underscores, so things like int n = 1000000000 can be made into a much more readable int n = 1_000_000_000, which is much easier to parse as being one billion, and harder to type wrongly without noticing. Also, binary literals are allowed in the form 0b10110101, making code that works with bit-fields a little nicer to read.
  • Handling multiple exception types int the same catch statement can be done, reducing duplicating code, and potentially making it easier to refactor later.

Every one of these changes is something your manager might not directly care about, but they make it a little bit easier to write correct code without as much effort and thought, freeing your mind to focus a little more on the actual logic you're trying to implement, and they also make it a little easier to read code later, making debugging a little faster.

On the API side, a number of API updates have also occurred:

  • Security-wise, several encryption methods have been added/deprecated, as crypto moves ever forward.
  • File IO has been changed, (this might be a better link, though ) adding some better abstraction in a number of places. I haven't personally dived into the new IO stuff, but it looks like a very useful overhaul, making it much easier to work with the filesystem without quite as much pain.
  • Unicode Support is up to Unicode 6.0, along with a number of other internationalization enhancements.
  • Java2D, which you mentioned in your question, has been improved. Better Linux font support, better X11 rendering on modern machines, and handling of Tibetan scripts.
share|improve this answer
1  
Nit pick: In fact string switch operates "as if it were using the String.equals method" (from the document you linked to). In reality, the compiler is free to optimize so that String.equals is not used ... provided that the net effect is the same. (And, I'd expect that it would use String.hashcode above a certain number of switch cases.) –  Stephen C Jul 14 '13 at 5:32
    
True enough. Most compilers are allowed to do a ton of optimizations that don't change semantics though, so it's often redundant to point out little things like that; I had only specifically mentioned .equals() to be explicit that case isn't ignored. Nonetheless, I've updated the wording a bit. –  Billy Mailman Jul 14 '13 at 5:39
    
String switches are not recommended practice as you're switch on an unbound domain. Switching on Enums is a typical middle ground here as you can have String like representation, but with semantic meaning. Oh and +1 for the complete answer BTW. –  Martijn Verburg Jul 14 '13 at 13:39
    
What are the advantages of using strings in a switch statement instead of integer constants? –  Giorgio Jul 16 '13 at 5:16
3  
the only business reason among those may be the security enhancements. Technical niceties are both debatable and utterly irrelevant for business people. –  jwenting Jul 16 '13 at 7:53

try-with-resources is a feature that's worth upgrading to Java 7 for, all on it's own. Resource leaks / memory leaks are a big risk in Java development and TWR reduces that risk significantly.

I'll add the that new NIO.2 File abstraction and Asynchronous capabilities are also worth moving to if your application has File/Networking I/O features.

share|improve this answer
    
They are also reducing the amount of PermGen needed and using either Heap or native memory instead, I'm not sure on where it will be stored now. This means by Java 8 you won't need to set two max memory parameters. –  Andrew Finnell Jul 13 '13 at 13:16
    
Isn't try-with-resources the same as a try-finally but with less boilerplate? –  jhewlett Jul 14 '13 at 1:34
1  
I think the idea is that less boilerplate means it's easier to get right. –  MatrixFrog Jul 14 '13 at 1:50
1  
Less boiler-plate and correct closing smeantics. They discovered that inside the OpenJDK they were doing it manually wrong about 2/3 of the time.... I suspect other high percentages of this in other corpuses of code. –  Martijn Verburg Jul 14 '13 at 13:38

There may be a reason why you should not switch to Java 7: If you have to use Oracle's VM and your software either runs on embedded hardware or you will distribute it with embedded hardware: Oracle changed the JRE's license so that it's not licensed if above conditions are met; you'll need to buy a Java SE embedded license. See What does "general purpose system" mean for Java SE Embedded?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.