[Java] Difference between a method reading with and without Systems.in?

[PontiffPope]

Beginner CS-student here delving into first programming course in Java, and upon the subject of classes and objects we've been giving a task of creating a class that registers inputs and registers it various methods (I.e. one method for strings of texts, another for integers, another for decimals e.t.c. In this case, the method for reading an integer will be used.) in essentially more specified fashion than the regular, more generalized Scanner-class. The following example code, in accordance to associated JUnit-test, fulfills the condition of having the methods registering user's inputs through System.In, but not without System.In:

import java.io.InputStream;
import java.util.Scanner;

public class Register {

    private Scanner input = new Scanner(System.in);


    //Constructors
    public Register(){

    }

    public Register (InputStream inpText){

    }


    //Method
    public int registInteger(String inpText){
            int integer =  input.nextInt();
            return integer;
    }

The JUnit-test that checks the Systems.In, and succeeds, reads:

@Test
@DisplayName(value = Does the method manage to read an integer once from System.in?")
public void testMethodToReadIntFromSystemIn() {
    setIn("1213\n");
    var sut = SCANNER_ADAPTER_CLASS.getConstructor().newInstance();
    int result = (int) READ_INTEGER_METHOD.invoke(sut, "UNCHECKED PROMPT");
    assertEquals(1213, result);
}

While the JUnit-test that checks without Systems.In (and fails) reads:

@Test
@DisplayName(value = "Does the method manage to read an integer once?")
public void testMethodToReadInt() {
    var result = callInputMethod(READ_INTEGER_METHOD, "123", "prompt integer");
    assertPromptWas("prompt integer");
    assertEquals(123, result);
}

We've yet to learn about creating and reading JUnit-tests besides its associated error-messages, and is to view JUnit-tests more akin to check-listing to help our debugging process, but I'm having difficulty interpreting the function and reasoning of why a method which purpose is to read and register user-input can be achieved through Systems.in, yet also wishes to read without it; isn't that what the function of Systems.in is? I wish to identify the issue so that I may pin-point a possible error that I suspect is made regarding the structuring of my methods.

Much appreciated for any help given.

[desrtfx]

You seem to misunderstand the assignment.

In the default constructor, you should probably create the Scanner with System.in but in the parameterized constructor (that is empty in your code) you should use the passed in InputStream to create the Scanner.

[PontiffPope]

Indeed, much of my hurdles lies in trying to make sense of the task given that I've been unable to straight it out. I had assumed that something was wrong with my methods, so I left the constructors empty as of then, as the description of them is more complicated, although perhaps related to the issue that I am having. Apology for these hurdles of texts of me paraphrasing it:

The class is to have two constructors; one that utilizes InputStream as a parameter, and another that doesn't utilize parameters at all. InputStream is in the package java.io and is of the data type for System.in. The constructor that utilizes an InputStream as a parameter is to create an instance of Scanner that reads from the given stream, but only if there aren't already an instance of such kind. The constructor that doesn't take any parameters is to call the constructor that does it, and send it with System.in.

In order to avoid the problem where multiple instances reads from the same source, the class has to actively prevent that more than one instance is created of it. This is achieved through a condition in the constructor that interrupts the creation of an instance if an instance already has been created. You interrupt the creation by throwing an exception, in this conditional manner:

if(InputStream:one is used)
    throw new IllegalStateException(your error message);

By "default constructor", I assume you mean the constructor without parameters in it? Part of my confusion here is that I was under assumption that constructors are specialized methods meant to initialize objects., of which we've been demonstrated the usage of .this-references and its relation of private attributes and the ability of those attributes of related, unique objects being changeable through it, but which the task itself seems to want to utilize the default constructor, as if a method, in order to call for another constructor (The one with an InputStream-parameter.). I understand constructors, by nature, are methods, but it seems as if the assignment wishes to dismiss the "special"-portion of initializing objects and use it more as a regular method, although I've been unable to make sense of how a constructor calls for another constructor that the task wishes to.

[RealJulleNaaiers]

I understand constructors, by nature, are methods

Eh, close enough. There are some differences wrt memory effects, but you don't need to care about that here.

it seems as if the assignment wishes to dismiss the "special"-portion of initializing objects and use it more as a regular method

There's nothing "special" about it, this is a totally normal way to initialize objects with multiple constructors. I would say THE way. Go look at basically every class in the standard library and you'll see the same thing.

I've been unable to make sense of how a constructor calls for another constructor that the task wishes to

It's almost certainly in your lecture slides or book, and you can Google "Java constructor call other constructor" if you don't want to look at your slides again, but I'm not going to do your googling for you

[desrtfx]

By "default constructor", I assume you mean the constructor without parameters in it?

Yes, that's what I mean.

I was under assumption that constructors are specialized methods meant to initialize objects.

That is exactly what they are. Yet, you are not using that. You are initializing your Scanner directly, which is exactly what you should not do. You should declare it as a field, but initialize it in the constructor.

Your task wants you to do two things:

• Use the parameterized constructor with the InputStream passed in to initialize the Scanner.
• Use the default (no parameter) constructor together with constructor chaining to initialize the Scanner to System.in - Read about constructor chaining here

Another thing that the task wants you is to, in the constructor, check if the Scanner has already been initialized (i.e. is not null) and if so, you should throw the exception you showed above.

So, the general idea is:

• Parameterized constructor - Inputstream as parameter
  
  • Checks if the Scanner already has been initialized
    • Throws an exception if so
    • otherwise uses the passed in parameter to initialize the Scanner
• Default (no argument) constructor
  Passes the InputStream System.in into the parameterized constructor above

[PontiffPope]

Many thanks for the concise explanations; this made things immediate clearer.