• Post Reply Bookmark Topic Watch Topic
  • New Topic

mark(int readAheadLimit) in BufferedReader  RSS feed

 
Tyson Lindner
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
from http://docs.oracle.com/javase/7/docs/api/ wrote:
public void mark(int readAheadLimit)
throws IOException
Marks the present position in the stream. Subsequent calls to reset() will attempt to reposition the stream to this point.
Overrides:
mark in class Reader
Parameters:
readAheadLimit - Limit on the number of characters that may be read while still preserving the mark. An attempt to reset the stream after reading characters up to this limit or beyond may fail. A limit value larger than the size of the input buffer will cause a new buffer to be allocated whose size is no smaller than limit. Therefore large values should be used with care.


What does it mean that the reset "may" fail? I'm having some trouble understanding the point of the parameter. It seems like the idea is to ensure that the characters get stored in memory, not create a limit on what can actually be read. It says that large values should be "used with care" but if the buffer is larger than the mark value initially, won't the use of mark be completely pointless?
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tyson Lindner wrote:
What does it mean that the reset "may" fail? I'm having some trouble understanding the point of the parameter. It seems like the idea is to ensure that the characters get stored in memory, not create a limit on what can actually be read.


The java.io.BufferedReader class IS-A java.io.Reader instance. And since with the Reader class, it "may" fail, then for the BufferedReader, it also "may" fail. Of course, this is arguable (as we don't what the implementors were thinking when they created the class).


Tyson Lindner wrote:
It says that large values should be "used with care" but if the buffer is larger than the mark value initially, won't the use of mark be completely pointless?


There are many methods in the api, where passing certain parameters serves little to no purpose, but that doesn't mean that the method is pointless -- after all, what happens when you pass a read ahead limit higher than the buffersize?

Henry
 
Paul Clapham
Sheriff
Posts: 22844
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tyson Lindner wrote:It says that large values should be "used with care" but if the buffer is larger than the mark value initially, won't the use of mark be completely pointless?


The buffer and the mark value are used for different things. The buffer says "Read 9000 chars at a time from the data source". The mark value says "Save the last 1000 chars because I might need to go back and read them again". Your theory there might be that the mark/reset code will use data from the buffer if it's available, but if it isn't then it will fall back on the regular method, which is to stash the last 1000 chars somewhere. Or perhaps your theory is that the reset method would have access to whatever chars had already been read from the current buffer. Or perhaps something else.

At any rate the buffer and the mark/reset data are different concepts as far as the user of the class is concerned. Did you find anything in the documentation which said that the two could be tied together in any way?
 
Tyson Lindner
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:Your theory there might be that the mark/reset code will use data from the buffer if it's available, but if it isn't then it will fall back on the regular method, which is to stash the last 1000 chars somewhere. Or perhaps your theory is that the reset method would have access to whatever chars had already been read from the current buffer. Or perhaps something else.

At any rate the buffer and the mark/reset data are different concepts as far as the user of the class is concerned. Did you find anything in the documentation which said that the two could be tied together in any way?


Yeah its in the original post:

A limit value larger than the size of the input buffer will cause a new buffer to be allocated whose size is no smaller than limit. Therefore large values should be used with care.


Its the "used with care" language that is throwing me off. It seems to imply that creating a limit value larger than the size of the input buffer is risky and maybe you should avoid doing it, but it seems to me that's the only reason why you set a limit in the first place.
 
Tyson Lindner
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
There are many methods in the api, where passing certain parameters serves little to no purpose, but that doesn't mean that the method is pointless -- after all, what happens when you pass a read ahead limit higher than the buffersize?


Right, but other than that...
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tyson Lindner wrote:
Henry Wong wrote:
There are many methods in the api, where passing certain parameters serves little to no purpose, but that doesn't mean that the method is pointless -- after all, what happens when you pass a read ahead limit higher than the buffersize?


Right, but other than that...


Not sure what you are trying to say... are you saying that other than calling the method with valid parameters, and hence, the method will do something useful, it will do something pointless? If so, I agree.

Henry

 
Tyson Lindner
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Tyson Lindner wrote:
Henry Wong wrote:
There are many methods in the api, where passing certain parameters serves little to no purpose, but that doesn't mean that the method is pointless -- after all, what happens when you pass a read ahead limit higher than the buffersize?


Right, but other than that...


Not sure what you are trying to say... are you saying that other than calling the method with valid parameters, and hence, the method will do something useful, it will do something pointless? If so, I agree.

Henry



I was asking if there was a function for the parameter other than X, and your response was that the parameter does X...
 
Paul Clapham
Sheriff
Posts: 22844
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tyson Lindner wrote:

A limit value larger than the size of the input buffer will cause a new buffer to be allocated whose size is no smaller than limit. Therefore large values should be used with care.


Its the "used with care" language that is throwing me off. It seems to imply that creating a limit value larger than the size of the input buffer is risky and maybe you should avoid doing it, but it seems to me that's the only reason why you set a limit in the first place.


No, the reason you would set this limit thing is because you plan to use the "reset" method to roll back the Reader and re-read some of the data you already read before. It has nothing to do with buffering at all; notice that the mark() and reset() methods are declared in Reader, not BufferedReader. The limit controls how far you can go back. As for "risky" and "use with care", I don't know. Perhaps they are pointing out that to set the limit, you're going to be allocating memory, and this might cause you to run out of memory.
 
Tyson Lindner
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:
No, the reason you would set this limit thing is because you plan to use the "reset" method to roll back the Reader and re-read some of the data you already read before. It has nothing to do with buffering at all;


How does the statement "will cause a new buffer to be allocated" have nothing to do with buffering?


notice that the mark() and reset() methods are declared in Reader, not BufferedReader.


Yeah but Reader is abstract and for at least one of the other subclasses mark() and reset() are actually completely useless.
 
Paul Clapham
Sheriff
Posts: 22844
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tyson Lindner wrote:How does the statement "will cause a new buffer to be allocated" have nothing to do with buffering?


Look, don't ask me to defend the word choices made by the documentation writers. The fact is that a BufferedReader differs from other Readers by reading its data sequentially in clumps called buffers. And Readers which support the mark() and reset() methods might have various ways of doing that. In BufferedReader they may have co-opted the buffering to support mark and reset for all I know, but the two functions are unrelated from a design point of view.

Yeah but Reader is abstract and for at least one of the other subclasses mark() and reset() are actually completely useless.


Yes. That's why the "markSupported()" method exists. For example if you look at StringReader you'll see that markSupported() has been overridden to return true, and that the documentation doesn't attempt to warn you that use of the mark/reset methods might use extra memory, because clearly you don't need to save copies of the already-handled data when you always have all of the data available to you.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!