6

I aware that byte is not a proper type enough to contain result of read method.
So, read method returns int type value.
But i think a short type is more efficient type than int.
It could contain the value of range -256~ 255.
Why does read method return int, not short?

crazy_rudy
  • 533
  • 2
  • 4
  • 19
  • 6
    Nobody really uses `short`s... – arshajii Oct 18 '13 at 15:02
  • 3
    "But i think a short type is more efficient type than int." - In what context? For a method call, with the value being stored in a local variable afterwards (which may well end up being a register) I would be surprised to see any significant difference. – Jon Skeet Oct 18 '13 at 15:04
  • i really want to know short is more efficient type than int, is that right? – crazy_rudy Oct 18 '13 at 15:04
  • First off, I feel the `java.io` package, in general, is not a well-written API. Secondly, in regards to short vs. int efficiency, check out http://stackoverflow.com/questions/14531235/in-java-is-it-more-efficient-to-use-byte-or-short-instead-of-int-and-float-inst – bdkosher Oct 18 '13 at 15:06
  • 1
    @crazy_rudy Actually, internally, `short` is represented the same as `int` in the Oracle JVM (it could be more efficient in other VMs, because it's implementation dependant, but in practice, `short` and `int` are always the same). The only place where you should consider `short` is when creating a huge `short[]` array. In that case, the VMs generally use the real two-byte shorts instead of `int`s internally (and that saves space). – Petr Janeček Oct 18 '13 at 15:07
  • Also note that File, FileInputStream etc. are legacy APIs. It's recommended to use the new NIO.2 File API if possible. – Puce Oct 18 '13 at 15:21
  • @Puce Some people need to stay backwards compatible with 1.6 or even 1.5 Heck, there are commercial solutions out there that require certain patchlevels of 1.3 or 1.4 – Ingo Oct 18 '13 at 15:36
  • @Ingo I know, that's why I wrote "if possible". I don't think everybody is aware of this new API and people are quite used to the old File API. – Puce Oct 18 '13 at 16:55
  • @Puce No, it isn't recommended. Don't post misinformation here. – user207421 Oct 18 '13 at 22:07
  • @EJP Well, the official Java tutorial from Oracle updated the File tutorial and only uses the new NIO.2 File API. http://docs.oracle.com/javase/tutorial/essential/io/fileio.html And I read that there are issues with the current java.io.File which are fixed with new API. So indeed like e.g. java.util.Date and soon java.util.Calendar, java.io.File although not deprecated is a legacy API. – Puce Oct 19 '13 at 11:47
  • @EJP here some further readings: http://www.oracle.com/technetwork/articles/javase/index-139843.html#1 – Puce Oct 19 '13 at 11:53
  • @EJP And yes, even the Java tutorial calls it "legacy code": http://docs.oracle.com/javase/tutorial/essential/io/legacy.html – Puce Oct 19 '13 at 12:36
  • 1
    @Puce The 'File' class is referred to as 'legacy' in your citations, not the entire java.io package. – user207421 Oct 19 '13 at 21:54
  • @EJP I never said the entire java.io package, but the FileXyStream/Reader/Writer also belong to the legacy API, AFAIK, since it's recommended to use `java.nio.file.Files` now to create streams/ reader/ writers etc. for files now from `Path` objects. – Puce Oct 20 '13 at 09:02
  • @Puce That's not stated in your links. The inference is yours alone. – user207421 Nov 09 '13 at 00:37

5 Answers5

8

Java documentation on primitive types suggests that shorts should be used instead of ints to "save memory in large arrays":

short: The short data type is a 16-bit signed two's complement integer. It has a minimum value of -32,768 and a maximum value of 32,767 (inclusive). As with byte, the same guidelines apply: you can use a short to save memory in large arrays, in situations where the memory savings actually matters.

Since in this situation memory savings do not actually matter, using int is a more consistent choice.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
2

There are several reasons:

  • You can easily read more than 32 KB worth of data and with a short type this would cause an overflow
  • Performance of short equal to the performance of int due to the "bitness" of processors. Modern CPUs take numbers of 32 or 64-bits, which fits both int and short. There was a performance benefit when running code on old 16-bit processors. Long time ago...
oleksii
  • 35,458
  • 16
  • 93
  • 163
1

That's because read returns the number of bytes read, there is the following method defined in InputStream:

public int read(byte[] b) throws IOException

Reads some number of bytes from the input stream and stores them into the buffer array b. The number of bytes actually read is returned as an integer. This method blocks until input data is available, end of file is detected, or an exception is thrown.

The maximum length of an array is about Integer.MAX - 5, since you can do operations with arrays then the return type is an int.

Alfredo Osorio
  • 11,297
  • 12
  • 56
  • 84
  • Since OP's talking about value ranges, he's clearly asking about [the other `read()`](http://docs.oracle.com/javase/7/docs/api/java/io/FileInputStream.html#read%28%29). – Sergey Kalinichenko Oct 18 '13 at 15:09
  • @dasblinkenlight but as long as you can read from an array, and the array can hold as much as an integer, it is not possible to return a short. – Alfredo Osorio Oct 18 '13 at 15:14
  • 1
    But that's irrelevant here, because he's talking about a `read` that takes no parameters, and returns a single `byte` as an `int`. OP wants to know why it isn't a `short`, because the byte would fit into `short` just as well, and also provide a `-1` for the `EOF`. – Sergey Kalinichenko Oct 18 '13 at 15:16
1

Read method returns int which signifies number of bytes read from the file, its a design decision taken while writing the API, now lets ask same question other way around:

How many maximum bytes we can read ?

•short: The short data type is a 16-bit signed two's complement integer. It has a minimum value of -32,768 and a maximum value of 32,767 (inclusive). You can use a short to save memory in large arrays, in situations where the memory savings actually matters.

•int: By default, the int data type is a 32-bit signed two's complement integer, which has a minimum value of -231 and a maximum value of 231-1.

Assuming we will have enough memory to hold bytes, int serves a better candidate over short and hence the API design. However API leaves the decision to user to decide how many bytes to read based on resources available.

Also, read method calls native code and on the native language side, these primitive data types are mapped to the closest matching native language data type.

Cheers !!

Sachin Thapa
  • 3,559
  • 4
  • 24
  • 42
1

The real reason is that the abstract class that FileInputStream inherits from is also the base for InputStreams that are supposed to read characters in any encoding, and it has a method

public int read();

that is used in character reading streams to read a single character.

As we all know, a char is an unsigned integer type of 16-bit.

Hence, a short could not be used, because it only has 32k (or 15 bits worth) positive values, but we need 64k (or 16 bits worth) for characters.

And we need (-1) to signal end of file.

It is the same story with Readers of all kinds and sorts.

Ingo
  • 36,037
  • 5
  • 53
  • 100
  • The inheritance is indeed the underlying reason, but the method only has to return a 'byte' or a sentinel, not a 'char' and a sentinel, so the argument from 'char' doesn't apply. It applies to Readers. – user207421 Oct 18 '13 at 22:10