1

00:00:00,900  -->  00:00:06,120
OK we are not done with the chapter on let's look at some of the important points we covered in this

2

00:00:06,120  -->  00:00:07,680
chapter.

3

00:00:08,040  -->  00:00:15,020
We began with looking at what streams are and we said streams are of two types byte streams uncocked

4

00:00:15,030  -->  00:00:21,750
or streams to process character data like text classes that fall under characteristics are used and

5

00:00:21,750  -->  00:00:29,190
the process non-current or Deda Lexa images crassest underbite streams audio's input stream an output

6

00:00:29,190  -->  00:00:36,450
stream or abstract arsis that syllabus based classes for all byte oriented input and output streams

7

00:00:36,450  -->  00:00:37,390
.

8

00:00:37,410  -->  00:00:43,470
Similarly a reader and writer are abstract base classes for our characters and oriented input and output

9

00:00:43,470  -->  00:00:45,730
streams.

10

00:00:45,980  -->  00:00:50,870
And here is how you would read and write bytes or extremophile.

11

00:00:51,480  -->  00:00:57,280
So this diagram captures everything for both bytes as well as text on the left.

12

00:00:57,330  -->  00:01:00,800
You have a job program and on the right there is the fine.

13

00:01:01,440  -->  00:01:07,710
If the file is something like an image then for reading we use a buffered input stream which would be

14

00:01:07,710  -->  00:01:14,420
chained to a file input stream but could read text from a file instead of buffered input stream.

15

00:01:14,460  -->  00:01:21,420
We use a buffer reader and we change it to an input stream reader which just don't change when file

16

00:01:21,420  -->  00:01:23,280
input stream.

17

00:01:23,280  -->  00:01:31,010
So for reading text we have one extra class which is the input stream reader which is a bitch bus that

18

00:01:31,020  -->  00:01:37,760
is it acts as a bridge for converting bytes to characters not to write bytes to be a file.

19

00:01:37,860  -->  00:01:42,290
We use a buffered output stream which will be changed when final output stream.

20

00:01:42,930  -->  00:01:49,910
But to write characters to a file then instead of buffered output stream we use it buffered writer visually

21

00:01:49,920  -->  00:01:57,780
bitching to an output stream later which is indention to file output stream recolored buffer classes

22

00:01:57,870  -->  00:02:04,500
provide the benefit of buffering and this kind of chaining is an implementation of Decrypter design

23

00:02:04,500  -->  00:02:06,380
Pakhtun.

24

00:02:07,440  -->  00:02:14,010
One of the most common activities in Igle is to read books from fifes and here's how you would do it

25

00:02:14,010  -->  00:02:15,150
.

26

00:02:15,150  -->  00:02:19,160
Here we are using a cry with resources syntax and bedacht.

27

00:02:19,470  -->  00:02:27,390
We do not need to have the finally block with the clean up or so it is much more cleaner try with resources

28

00:02:27,530  -->  00:02:27,780
.

29

00:02:27,900  -->  00:02:32,840
Take it off closing off those streams implicitly as we see here.

30

00:02:33,000  -->  00:02:35,550
Always use a string builder when reading.

31

00:02:35,560  -->  00:02:36,630
From fine.

32

00:02:37,010  -->  00:02:44,790
Do not use a plus operator for concatenating which we know is a very expensive node that we use read

33

00:02:44,790  -->  00:02:52,750
line method or buffer reader for reading a line of text from the underlying character stream.

34

00:02:52,870  -->  00:02:57,370
And here is how you would read text entered by a user in the console.

35

00:02:57,900  -->  00:03:02,210
Only difference here from reading from a file is that he had to be replaced.

36

00:03:02,250  -->  00:03:07,600
File input stream system in recolor in the demo.

37

00:03:07,800  -->  00:03:15,570
We also discussed how this can be done using the scanner class from Java dog Udal package scan and also

38

00:03:15,570  -->  00:03:20,910
provide some additional convenient methods for reading primitives.

39

00:03:20,930  -->  00:03:27,680
And here is how you would write extremophile you would use the right method off before writer.

40

00:03:27,840  -->  00:03:33,560
In this case input the right method can be either a string or a character in it.

41

00:03:33,990  -->  00:03:37,560
That is right as an ordered method.

42

00:03:38,500  -->  00:03:46,530
And here is how we serialize NDC realized Java objects for serialising we use object output stream that

43

00:03:46,530  -->  00:03:51,900
just change a buffered output stream which is and don't change a file that put string on to write an

44

00:03:51,900  -->  00:03:52,850
object.

45

00:03:52,860  -->  00:03:58,070
We make use of the write object method of object or string class.

46

00:03:58,110  -->  00:04:00,620
Also the class of the object will be serialized.

47

00:04:00,810  -->  00:04:08,400
Must implement Serializable interface and allies realize we simply use the corresponding input stream

48

00:04:08,410  -->  00:04:15,560
process and we use the read object method of object input stream to read an object.

49

00:04:15,570  -->  00:04:21,480
Important thing here is that we should read the objects in the same order in which they were serialized

50

00:04:21,480  -->  00:04:22,920
.

51

00:04:22,920  -->  00:04:27,000
Not that Beaufort's means here are used only for performance reasons.

52

00:04:27,240  -->  00:04:29,750
So it is not required to use them.

53

00:04:30,610  -->  00:04:34,550
And here are examples where serialization would be useful.

54

00:04:34,620  -->  00:04:41,520
I think first one is probably the more typical use case serialization can be very helpful if you how

55

00:04:41,520  -->  00:04:47,030
high traffic dynamic web pages that are not frequently updated.

56

00:04:47,040  -->  00:04:50,710
That is how most frequent databases read operations.

57

00:04:50,730  -->  00:04:55,020
Dan did Data bestride operations in such cases.

58

00:04:55,020  -->  00:05:03,240
You can serialize Jawa objects to either disk or you can cache them using something like memcached and

59

00:05:03,270  -->  00:05:09,090
serialized objects can also be transmitted across DBMS.

60

00:05:09,090  -->  00:05:13,910
No you want your classes to wall not break because you don't know the process.

61

00:05:14,010  -->  00:05:19,510
Then you can declare a constant Silverbush an ID and B have seen you going over Demel.

62

00:05:19,860  -->  00:05:23,760
There are few cases where it Mistal break D.C. delegation.

63

00:05:23,850  -->  00:05:32,370
So in general you need to be very careful when evolving Serializable causus new toy is one topic which

64

00:05:32,370  -->  00:05:33,540
we don't discuss.

65

00:05:33,700  -->  00:05:37,190
And that's because stree my way is most commonly used.

66

00:05:37,830  -->  00:05:41,150
But I may also cover this topic sometime in the future.

67

00:05:41,820  -->  00:05:48,220
It is mainly useful for High-Speed and especially when handling large files.

68

00:05:48,240  -->  00:05:55,650
This is possible because no classes have tighter coupling with operating system on modeler.

69

00:05:55,740  -->  00:06:03,630
They also permit you to use all Freep memory that is memory outside of them and that would be useful

70

00:06:03,990  -->  00:06:09,370
as that area is not subjected to garbage collection on so there is no real estate.

71

00:06:09,410  -->  00:06:13,810
I am moving on data during regular GC cycles.

72

00:06:14,280  -->  00:06:19,780
Stream my work has also been re-implemented with and I will take it one day offspeed.

73

00:06:20,010  -->  00:06:26,740
In fact input stream reader relies on and I will on for reading next line by line.

74

00:06:26,760  -->  00:06:31,560
I think you would be better off using stream my role as it is also really fast.

75

00:06:32,160  -->  00:06:39,510
Moreover if you are using a for this you would have to write some custom or so rigorously my work is

76

00:06:39,510  -->  00:06:45,660
pretty fast too and in some cases where the files are not very large stream my work can be faster than

77

00:06:45,930  -->  00:06:46,990
I will.

78

00:06:47,000  -->  00:06:53,730
In general the recommendation is to actually benchmark for a particular situation to see which approach

79

00:06:53,730  -->  00:06:57,240
is better but if fights are not very large.

80

00:06:57,240  -->  00:07:01,910
I think you can go 4st my will also for reading next to line by line.

81

00:07:01,950  -->  00:07:07,770
You can simply go get stream I will but when you're dealing with really large files then you might think

82

00:07:07,770  -->  00:07:09,260
about unable.

83

00:07:10,050  -->  00:07:10,860
So that's about it.

84

00:07:10,860  -->  00:07:15,710
With the chapter on I hope you and you are learning about performing input and output.

85

00:07:15,900  -->  00:07:16,380
Thank you