So, I was writing a Java class earlier today that reads in stored compressed log data for a program I’m working on, and apparently, in Java 8u112, java.io.ObjectInputStream.readLine() is deprecated.
Why, Oracle, why would you deprecate the method that automatically reads in an entire line of a stream? Thanks to this method *existing* , I was able to easily slurp in lines of my zipped log file (after uncompressing them using java.io.GZIPInputStream()) and then use the logfile’s contents as program data like I wanted to.
Without the readLine() method, I would have had to McGuyver one together myself, which would have been both memory inefficent and also very hacky and I’d not be surprised if there was an edge case or two missed by whatever I ended up implementing.
I understand deprecation, and why it is a good thing inside the Java API as we move forward with new development. However, there are always going to be good business cases for reading in lines of data which is separated by the platform’s newline character from a file, whether it is represented by literal character data or object data.
Heck, if Oracle wants to move “utility” methods like this out of the core I/O classes in java.io, that’s fine with me, but in that case, move them to a new home inside of a class in the java.util package and update the javadoc to point to it, and also update the Java bytecode compiler (javac) to tell the user this information when they compile with -Xlint:deprecation (which is waht is already suggested to the developer when the compiler detects the use of a deprecated method inside of the code being compiled).
So, the questions are: why are we deprecating convenient methods that are obviously going to be more efficent than anything developers could build by themselves and why isn’t the compiler smart enough to point the developers to these convenience methods if they get ‘deprecated’ in their original classes but moved to other package classes inside the Java API as provided by Oracle?