About Question enthuware.ocpjp.v7.2.1552 :

[renatumb]

I am confused with this question, because in its options/answer,

new OpenOption[]{StandardOpenOption.READ, StandardOpenOption.DELETE_ON_CLOSE}
This is an invalid combination.

But READ and DELETE_ON_CLOSE to be an invalid combination, depend on where they are used...
For example, in the method below, they can be used together

Code: Select all

Files.newByteChannel( Path, StandardOpenOption )

So, I think the value(s) of StandardOpenOption is totally dependent of the method where it will be used..

[admin]

You are right. This seems to be valid combination.
Unfortunately, even though the API documentation for StandardOptionOption does not mention which combinations are valid and which are not, the exam includes questions on this aspect. "Depends on the implementation" is indeed correct, but it is not an option.

HTH,
Paul.

[laura90_m@yahoo.com]

For this question, in the answer is:

new OpenOption[]{StandardOpenOption.READ, StandardOpenOption.SYNC}
This is an invalid combination.

I tested this for

Files.newByteChannel(Paths.get("test.txt"), StandardOpenOption.READ, StandardOpenOption.SYNC);

where the file "test.txt" exists. It seems to work, no exception thrown.

[admin]

Yes, this is a problem. We were trying to provide a simple way for the candidates to answer this type of questions but the issue is that the API does not clearly specify which combinations are valid and which are not. Further, they work on some machines and not on others.

So we have now added this statement to the explanation that it is not really possible to determine with certainity which combination will work and which will not work.

thank you!
Paul.

[The_Nick]

READ AND SYNC

Ideally, this should be an invalid combination but it works in some cases.

Should I thick it as a valid answer or not in the real exam?

The_Nick

[admin]

It is really not possible to suggest what to do this such as case. Your guess is as good as any others. But if since it works fine on your platform, you have a strong ground to mark it as valid.

HTH,
Paul.

[jowfornari]

How come READ and DELETE_ON_CLOSE is a valid combination? (2nd option)

Even the question explanation states that "Thus, READ and TRUNCATE_EXISTING (or WRITE, APPEND, or DELETE_ON_CLOSE) cannot go together."

Thanks in advance.

[admin]

Please read this discussion from the top. It is mentioned above.

[codecodecode67]

It really depends on what you're using to open the file with, so I believe this question should be changed. If you're using a BufferedReader, WRITE is an invalid option to add. If you're using a BufferedWriter, READ is an invalid option to add. READ & SYNC may work in some cases for BufferedReader but will never work for BufferedWriter. Whereas APPEND & CREATE_NEW works for BufferedWriter given that the file does not exist (marked as a wrong answer in this question).

What I'm getting at is that with the current phrasing of the question - disregarding whether a Writer or a Reader is being used - the valid combinations cannot be determined.

Please let me know what you think.

Thanks

[admin]

The Javadoc API descriptions of these constants do not mention that valid combinations depend on how the file is used.

HTH,
Paul.

[codecodecode67]

That may be so but if you look at the underlying code:

Code: Select all

BufferedWriter br = Files.newBufferedWriter(writeFile, Charset.forName("UTF-8"), new OpenOption[] {StandardOpenOption.APPEND, StandardOpenOption.CREATE_NEW});

If you go into method newBufferedWriter, then into method newOutputStream from the below snippet:

Code: Select all

Writer writer = new OutputStreamWriter(newOutputStream(path, options), encoder);

then newOutputStream again from the below snippet:

Code: Select all

return provider(path).newOutputStream(path, options);

you'll see the below code is used every time you create a BufferedWriter using java.nio.Files:

Code: Select all

public OutputStream newOutputStream(Path path, OpenOption... options)
        throws IOException
    {
        int len = options.length;
        Set<OpenOption> opts = new HashSet<OpenOption>(len + 3);
        if (len == 0) {
            opts.add(StandardOpenOption.CREATE);
            opts.add(StandardOpenOption.TRUNCATE_EXISTING);
        } else {
            for (OpenOption opt: options) {
                if (opt == StandardOpenOption.READ)
                    throw new IllegalArgumentException("READ not allowed");
                opts.add(opt);
            }
        }
        opts.add(StandardOpenOption.WRITE);
        return Channels.newOutputStream(newByteChannel(path, opts));
    }

where the default options are CREATE and TRUNCATE_EXISTING, which are not added if at least one option is added by the user, and WRITE is always added as an option regardless. Plus you can see that it fails if it detects READ is being used.

[admin]

Assuming that you have quoted code from Java standard library classes, they are free to make changes in the code as long as they stick to what is guaranteed by the their Javadoc API description. So making inferences by looking inside the code is not a good idea, imho.

HTH,
Paul.

[jelofka]

Hi,

if new OpenOption[]{StandardOpenOption.READ, StandardOpenOption.SYNC} is OK for
v7.2.1552, it should be ok for v7.2.1551 as well or at least somehow modify one of these two questions (or explanations) in order to avoid inconsistency. Just a suggestion.

KR
Matjaz

[sir_Anduin@yahoo.de]

I agree,
the questions enthuware.ocpjp.v7.2.1551 and enthuware.ocpjp.v7.2.1552 has a different validity for the same option.