Why do I need to close the AmigoOutputStream and not the BufferedReader stream ? I have never seen this before? What happens to BufferedReader stream?

public class Solution extends ArrayList<String> {

    public static void main(String[] args) throws Exception{
        ArrayList<String> javaStandardArrayList = new ArrayList<>();
        javaStandardArrayList.addAll(Arrays.asList("one two three four five".split(" ")));
        Solution myArrayList = new Solution();
        myArrayList.addAll(javaStandardArrayList);

        System.out.println("Outputting original java ArrayList:");
        System.out.println(javaStandardArrayList);
        System.out.println();
        System.out.println("Outputting my ArrayList:");
        System.out.println(myArrayList);
    }

    @Override
    public String toString() {
        if(size() > 0){
            String x = " one thousand";
            StringBuilder sb = new StringBuilder();
            sb.append(get(0) + x);
            for(int i = 1; i < size(); i++) sb.append("\n"+ get(i) + x);
            return sb.toString();
        }

        return "";
    }
}

Here I just extended Solution class so that it is an ArrayList and created an overridden toString() method. In the main method I created a standard ArrayList and filled it with some values. Next I created a Solution object (which is now an ArrayList with all the same exact functionality other than the modified toString()) and filled it with the same values. Then I output both of the objects to show the difference. Its simple to do and you can extend nearly all the classes in Java to add functionality as you need or desire.

OK, so let me see if I understood this: the AmigoOutputStream interface basically replaces the original OutputStream abstract class(I also saw, write, flush methods). But then we have to close the InputStreamReader which is a different class. However, I suppose it doesn't matter the type of Stream open because close() applies to all subclasses of Reader class?

It doesn't replace, per say, it is more like a copy of it. Interfaces, though, don't actually do anything by themselves. If you look at the code in the AmOutStr interface you are going to see a few methods, but no actual code. Interfaces are sort of like contracts that state that whatever class implements the interface MUST implement the methods that the interface declares, and must also make them as public (you'll get a red squiggly if you remove 'public' from any of those methods in the class). It is important to understand, however, that there is no guarantee that the implemented methods MUST do anything, least of all what you expect. Example:

class myClass implements AmigoOutputStream {
    public void flush() throws IOException {
        System.out.println("It's my code, I'll do what I want");
    }

    public void write(int b) throws IOException {
        System.out.println("If you think this is writing anything, you're wrong");
    }

    public void write(byte[] b) throws IOException {
        System.out.println("I laugh at you!!!!");
    }

    public void write(byte[] b, int off, int len) throws IOException {
        System.out.println("I actually want to write this, but there is no file to write to??");
    }

    public void close() throws IOException {
       System.out.println("Inside myClass.close()");
    }
}

There is nothing stopping you from writing whatever you want in those methods, or any other programmer from doing so. Following standard and good coding practices, however, means you should be naming and using things meaningfully, and if you create a class that implements an interface with "OutputStream" in its name with those methods, it better work as an OutputStream.

You could actually take that code I shared, paste it below line 35 of your code in the QuestionFileOutputStream file (outside the class). Then inside the QuestionFileOutputStream class add a main method:

public static void main(String[] args) throws Exception {
    AmigoOutputStream test = new QuestionFileOutputStream(new myClass());
    test.flush();
    test.write(3);
    test.write(new byte[0]);
    test.write(new byte[0], 0, 3);
    test.close();
}

Line 2 declares a variable of the interface, which is perfectly acceptable, then creates an object of QuestionFileOutputStream. Interfaces cannot be made into objects themselves, so you would need to make a valid object from a class that implements the interface, with that class does. Now the constructor takes an AmigoOutputStream object, which myClass (which has some actual functionality) is also. Then you run the code. The QuestionFileOutputStream delegates all the actual work to the object passed into the constructore, which is the useless myClass. This is just an example. In real life if you were using a class, such as some random OutputStream, that did what you basically wanted it to do, but you wished it could do just a little bit more to be perfect. You could follow the steps in this task: - Create a class that implements the same interface of that object - Make a constructor that takes that object to use in your class - Copy all the methods but pass the actual work off to the original object - Add the functionality that you desire

Thanks, it is a bit clear now and the example your provided was really cool , I copy-pasted it into my IDE and it worked ! 😁 One thing is still unclear to me:

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String lineRead = br.readLine();
if (lineRead.equals("Y")) amigoOutputStream.close();

How is line 1 closed by line 3 when amigoOutputStream is a standalone interface, with it's own close method? This bit is a bit fuzzy. I apologize if you have already explained this, I probably haven't understood, and if you have, I will look at your answers tomorrow again because today, after 4 hours of studying I am 'a bit' fuzzy. 😁

Line 1, the BufferedReader, is not being closed. The AmigoOutputStream object is being closed.

// line 3 of the code from your original post way above
private AmigoOutputStream amigoOutputStream; // << this is being closed

The BufferedReader would still be open in memory until the program ended or Java's garbage collection disposed of it. You can add a line to close it, which would probably be for the best:

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String lineRead = br.readLine();
if (lineRead.equals("Y")) amigoOutputStream.close();
br.close();

the task won't validate when closing the reader (afair). I have commented that out in my solution, too.

OK, now I understand completely, thank you!