Antonio Moretti

Ranch Hand
+ Follow
since Aug 10, 2021
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Antonio Moretti


It seems that BufferedReader was what I was looking for, as it has a larger buffer whose size is determine by the class itself. It reads characters, so the parsing has to be handled explicitly, which for a csv file is simple enough. However it seems that Scanner's buffer is big enough for small files anyway.

4 days ago

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?

I'll let you know when I find out.
4 days ago

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.

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.
4 days ago

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.

I put each line from the csv as an object in an ArrayList. All I was thinking here was to reduce the number of times the file was accessed. Or does Scanner put it all in a buffer anyway?
4 days ago

Can someone please show me how to use StringBuilder with String.Format features, so I can use the format specifiers? Is this a thing? Or should I just use normal concatenation?

Thanks T.
4 days ago

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.

It's a CSV file. Where did you read that Scanner was deprecated?

My idea was to get the whole file in somehow, store in some tank in memory, then parse it from there rather than read it in line for line. I know we can read in characters and into a large buffer, but where to put them after that?
4 days ago

We have been taught to use the Scanner class + FileReader to read a file from disk, and this is great except that it has to keep reading small bits from the file. I was wondering how to do to read the whole file in as one big chunk. I know you can use buffered reader, but what is a suitable data structure to put it in once it's been read in?

4 days ago

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?

Yes, I would be most interested!

I think the problem with Java is that Swing is a bit hard to learn for beginner. (You know the man Deital? He made two books: Early Objects and Late Objects. It seems there are two approaches to this learning). And then we have Java FX, which is also difficult, and now, seems less relevant. That leaves us with browser GUI - the most cumbersome of all if we take into mind of all the build tools and frameworks. We will learn Swing starting next week, but I have enjoyed console applications. I also ordered Huw Collingbourne's book on text adventure programming. Looking forward to that.
1 week ago
I have a class that runs a console application that shows the user menus and does various things based on their menu choices. I seem to be faced with a dilemma regarding organizing things. So I am it better to call methods from other methods, building up a stack, or is it better to have each method to return to a manager method? Right now I have a method run() that's calling the other methods. OK, some methods are nested, but the general pattern is a shopping list of calls in the run method, waterfall style. I am just wondering if this is good.

For example, I have a "menu" method that displays a menu that is called from the run() method. This validates and returns the user's choice to the run() method where it is used in a switch to determine the next method to call. But it seems I could also just call the next method from the menu method, without returning, and so on. I don't really know how to do. Can anyone advise please?
1 week ago

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"...

Fantastic information. I have pasted this into a Word document for use in my Java notes for future reference! Many thanks for the time!
1 week ago

Today we have been going through nested class types, and the teacher was using the diagram on this page:

I know that anonymous classes are often used in event handling, but I couldn't see why I'd want to use a static inner class, an inner class or a method-local inner class. I understand the mechanism and scope of these, but can't imagine ever needing to use one. I wonder if anyone can help me here? For example, point to me to a source that explains the use, with examples? The teacher just said they are used when we want to structure and organise our code that way...which did not help me much.

1 week ago

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.

What about getter methods? For example, in an of days of the week, we could the number of days to a private int field 'days'. We'd want this to be immutable, so private. So it would seem natural to me to provide a getter method to that otherwise the instance would need a public field.
1 week ago

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.

While learning Java, I rely on analogies and a concepts that go deeper than Schildt. For example, in that old book "The Heads First Java", I was really able to grasp polymorphism because of the way it was explained with diagrams. I'd like to have that level of understanding of enums but HFJ doesn't explain it. From what I can gather from here, the enum Book in my example is like a class, and the fields it contains are like instances of that class. Is this correct? And only once instance of each allowed?
1 week ago
If you have an enum like Book which for example, has the constant PAPERBACK, is it correct to consider the PAPERBACK its own datatype? As if it is an object field? I am puzzled because I don't really understand how we can call constructors on them, for example, when I look at this code, it seems like PAPERBACK and HARDBACk are types and each instantiated with one int instance variable set to the value. Am I right in thinking this?
1 week ago

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.

Isn't there a big risk you will violate Liskov if you are just doing List as the reference variable every time you make an ArrayList object? Teachers say we should do this but do not give good explain why. Also, as rule of thumb be taught to go for the highest abstraction, so here why not use Collection?
2 weeks ago