#Would this way of writing to a file work?

1 messages · Page 1 of 1 (latest)

remote linden
#

?

tribal skyBOT
#

<@&987246399047479336> please have a look, thanks.

tribal skyBOT
#

While you are waiting for getting help, here are some tips to improve your experience:

Code is much easier to read if posted with syntax highlighting and proper formatting.

If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.

Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.

remote linden
#

Here, what's the use of BufferWriter? I was under the impression that just the Outputstreamwriter would be enough? Isn't this like a writer of its own which does the same thing? Can anyone confirm that to me?

image.png
#

Isn't it redundant to add BufferedWriter, in other words?

tribal skyBOT
#

File IO in Java should be done preferably with NIO (Java 7+), revolving around the classes Files and Path; and not with the old interface File, BufferedReader, FileReader and similar.

NIO is simple to use. The path to a file is represented using the Path class:

Path path = Path.of("myFile.txt");

All file operations can be found in the Files class:

// Reading
List<String> allLines = Files.readAllLines(path);
// or as a single string
String content = Files.readString(path);
// or with a stream
try (Stream<String> stream = Files.lines(path)) {
  stream.forEach(System.out::println);
}

// Writing
Files.write(path, lines);
// or as a single string
Files.writeString(path, "hello world");
// or with extra options
Files.writeString(path, "hello world",
  StandardOpenOption.WRITE,
  StandardOpenOption.CREATE,
  StandardOpenOption.APPEND);

If you need more control over the process, you can fallback to the old interface, but prefer using the bridge methods from NIO (Files.newBufferedReader, Files.newInputStream, path.toFile() and similar) to benefit from advantages such as correct encoding and better error detection.

Here is a simple example of how to read a file line-wise with the old interface

try (BufferedReader br = Files.newBufferedReader(path)) {
  String line;
  while ((line = br.readLine()) != null) {
    System.out.println(line);
  }
}

it is way more verbose than NIO but it gives more control.

You must not forget to close file handles, even in all exceptional cases. Closing a handle manually is very hard, which is why you should always use try-with-resources for this to let Java automatically close the handle for you:

try (SomeResource resource = ...) {
  ...
} // Automatically closed here, even in exceptional cases
Quinteger • used /tag id: nio ·
remote linden
#

@next warren Unfortunately, I have to understand specifically what I'm given, regardless of my own personnal preferences

next warren
#

BuffereWriter is a decorator class for any other Writer which has an internal buffer

#

The reason it is used is because otherwise every write operation would incur an IO operation

#

With a buffer, their amount is reduced and you write more data at once

#

Since they only happen when the buffer is full

remote linden
#

Sorry, can you refomulate this for someone with less than 1 year of programming experience

#

A buffer I know is a sort of memory holder

#

temporary memory holder

next warren
#

file writing slow

#

many times file writing - many slow

remote linden
#

oh

next warren
#

fewer times file writing - fewer slow

remote linden
#

said this way, it makes sense now. The very act of writing takes time

#

is this right

next warren
#

Yes, it essentially makes no difference whether it's a byte or 4 kilobytes

#

Not on this scale, at least

#

It's the file access itself which is slow

remote linden
#

you mean, it would still take take the same amount of time regardless of what we write

next warren
#

Yes

remote linden
#

ok

#

So, BufferWriter corrects this problem?

next warren
#

And by writing bigger chunks you make fewer file accesses

remote linden
next warren
#

Yeah

#

Just don't forget to flush it when you're done

remote linden
#

Ok, I get it now, I assume it's the same way when we do reading from a file, it takes time as well

#

you mean to close the stream?

next warren
#

Closing as well, but I mean flushing

remote linden
#

what is flushing

next warren
#

Although it might auto flush it when it's closed

#

I don't remember

remote linden
#

ok, i think closing will be enoughin my case lol

next warren
#

Flushing is writing any remaining data that's in the buffer

uncut bluff
uncut bluff
#

closing it would flush everything left

remote linden
#

Ok, thanks for confirming it, btw, what was just said for writing holds for reading as well right, the very act of reading takes time etc

remote linden
# next warren I don't remember

Although in theory, would it be possible to just write directy without the Writer? As in, you would get no problem I assume? (outside of slowness)

next warren
next warren
#

Just know the implications

uncut bluff
remote linden
#

some basic stuff

remote linden
# next warren Yeah

ok, thanks for confirming it. I jsut remembered that Outputstreamwriter does character by character, as opposed to whole lines

#

so I can imagine it would be quite problematic