Damon McNeill wrote:
Antonio Moretti wrote:
I know how to parse a CSV. I just used the split() method and put each value in a array and took it from there. I just wondered if there was another way of reading the file in other than line by line, which to me, suggests a lot of disk operations if the file is long. That was my question all along.
No. How else would one read a file other than line by line?
Damon McNeill wrote:Scanner basically is a parser that reads Java objects from a input source (file, or string). What are the Java objects? Integers, Strings, Floats, Doubles, basically the primitive types.
You need to understand the Scanner API.
So basically the API is that you have an input source and you scan to see ifHasNextX, where X is some type. Then if that's true, you get the object with nextX. Say X = "Int".
Unfortunately that doesn't parse CSV. You would need to use ifHasNextInt() -- for example -- and nextInt() with a combination to parse out the separating commas between those items.
Jesse Silverman wrote:Everything in this discussion is awesome, with the exception that I am virtually certain that Scanner is most decidedly not deprecated.
For some reason, presumably just "too much to potentially be on the exam!" Scanner use is not covered on the OCPJP exams (but Console is) but that just puts it on a list of things that are still important in Real Life that won't be found on the exam. It has a couple of weird behaviors until you get used to it, but it definitely hasn't been widely displaced by something better.
Damon McNeill wrote:I thought Scanner was deprecated?
What is the structure of the file? If you just want the raw bytes I think you could use ByteArrayInputStream.readAllBytes(), perhaps wrapped in a BufferedInputStream.
A suitable structure to read the file into objects in memory depends totally on the structure of the file (unless you just want the raw bytes). I suppose that's why they were using the Scanner.
Eventually you'll have to parse out the contents of the file into a suitable in-memory object structure but until we know the file structure, or even better, the logical structure, its impossible to say.
Jesse Silverman wrote:...Would you more appreciate answers specific to the "almost lost art" of menu-driven console applications or general design guidelines that presume very few applications are using a menu-driven console approach?
Jesse Silverman wrote:Now what would you pay? But WAIT, there's MORE!!
This would be too much info for most "Beginning Java" threads, but I know the OP has a strong thirst for Deep Knowledge of Java from their posting history.
Some more words about Encapsulation in Java.
Most good programmers realize the tremendous long-term benefits of Strong Encapsulation for projects that will get large, will live a long time, or both.
They are seeking it however they can get it.
Just how you can go about getting it has evolved a lot over Java's long history.
Modern Java now finally has the Java Platform Module System (sometimes still called Project Jigsaw).
Let me describe briefly the problem it solved and then I will leave it to you to work out in code that targeted Java 8 and earlier the places and ways and workarounds they used to try to deal with the fact that it wasn't there for us yet.
In Java, you will very commonly see all but the smallest projects split into many packages.
The idea was supposed to be that everything that used a default accessibility (unfortunately spelled "" because there was no way to say it aloud!) can be seen by all other classes in the same package.
Well, that worked, except that you will also see most larger packages split into "sub-packages".
But that doesn't mean what it seems to for people coming from other languages.
Let's take an example using some "famous" Java packages we should all know about:
It would be reasonable to think that maybe java.nio.file can access those package-friendly, default or "no access modifier specified" components of java.nio, right?
"But NOOOOOO..." as John Belushi would have said, as far as access to each other goes they might as well be in:
But let's say they need to access stuff in each other, not sure for the example I gave because I am rushing, but it is VERY common.
So what did we used to do?
Anything that code in ANY other package in the world needed to access, even a "sub-package" that we just learned gets no special access privileges compared to any other package in the world, needed to be marked public or it couldn't be accessed.
But now, ANYONE who knows the package name can access it. Oh, no!
Too bad. There wasn't really a solution to this, we tried to do things like calling it "something.unsafe", "whatever.internal" or, in places I worked (this is not a joke) "mypackage.donotuse".
Did people listen? Nooooo...
This caused much pain and suffering. We needed to make changes or improvements and couldn't because there were people accessing stuff we didn't want them to, but they did and now it was OUR problem!!
So now we have the concept of modules, a higher level of organization than packages.
Modules can decide what of the multiple packages they contain can be seen by the outside world, and, in fact, by which modules if we know of a "Safe List" of those.
So all the implementations and stuff we might want to change can be safely marked public in the code and used within the module, and, optionally, some things can be shown to all or just select users of the module.
This is all wonderful and terrific and you should learn all about it.
BUT...this only came along relatively very recently!! Java was around for no less than 22 years before we got these much-needed options for encapsulation.
All but the newest code projects you may see were started long before modules were actually usable (the Jigsaw project started way back but there were many difficult roadblocks to overcome before it actually saw the light of day and we could actually use it).
You will see many, many things in older code bases used to Desperately Seek Encapsulation for good reason that had no language support in Java for "modules" (JPMS is known both by the compiler and the JVM, it took a long time to get there but "the whole Java System" knows about, and respects them now)...
Some of these will involve Nested or Inner Classes.
Some of them would look neater or easier or cleaner implemented in other ways now that we know about and can use Modules to organize our code.
But what would we say "You should have waited another 16 years to release your popular open-source project so that it could use JPMS?"
So the point is, there are a lot of better ways to organize code and achieve great encapsulation in Modern Java using modules that we would be dumb not to avail ourselves of now.
But we can't fault others for not using what wasn't there yet for all the years before they had access to it.
Various different attempts to achieve such results might look clunky, awkward or complex BECAUSE THEY WERE. But it wasn't their fault.
Having a very full knowledge of Java includes recognizing those paradigms and idioms so as to be able to work productively with such code.
It would be a Very Bad Idea to rely on such clunky solutions in new code that doesn't have to run on Java 8 or before, but there are billions of lines of Java and probably millions of classes (and probably even packages and sub-packages) that were in production and getting used heavily before we had any of these nifty ways to do things.
So, it is a bit like hand-cranked cars, horses-and-buggies or churning your own butter, except that you will actually see these things in Real Life Java Code.
Especially regarding dependency management at runtime and encapsulation as enforced by the compiler and JVM, best practices in the old days and now for new code that knows it is on say, at least Java 11 look VERY differently.
I'm not sure how much of this directly touches on Nested and Inner Classes, but some of it indeed does, and we did bring up Encapsulation, the notion of "Okay, it is great. So how do I get it?" has changed a LOT between "Classical Java" and "Modern Java"...
Jesse Silverman wrote:You don't need to provide methods in your enum, and I had never done this before in my life before learning this relatively recently in Java and C# about the same time.
Jesse Silverman wrote:Your first priority is to figure out which things you can do with enums is on the exam.
Then how to do those things correctly, and spot incorrect usage attempts.
The lowest priority is how you want to describe this behavior in brief.
The full description is way beyond the scope of the exam, and can be seen in the JLS.
Junilu Lacar wrote:
Antonio Moretti wrote:I need to see the power of doing this thing.
One advantage of doing this is that you can substitute one implementation for another at a later time. If you haven't violated the Liskov Substitution Principle (LSP), then the code should still work even if you use a different implementation of List. This may not seem like a huge advantage if you don't intend to change the implementation in production but it can help when you're testing. By programming to an interface, you can use mocks or stub implementations of the interfaces instead of the actual implementation. Reasons for wanting to do that include having more control over the behavior of the dependency and it can make test setup easier/simpler.