Jason Koonce

Ranch Hand
+ Follow
since Oct 30, 2010
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Jason Koonce

Look over your if...else's again. I went over them and found one last extra else statement. After that, it ran just fine for me.
13 years ago

Cheryl Scodario wrote:Hey Jason! Thanks as always. I am just wondering what does a byte-code looks like? Because I feel like so far I have been using text file that contains strings. But I did use InputStreamReader once, but I don't remember why?



To be honest, I don't know. I was told it was something to do with how you save your file. My instructor said that if you saved it as .ser instead of .txt with a serialized method. I opened up the file in notepad just to see and it had all of the letters and numbers I typed plus a lot more stuff that looked like it was code-shorthand for the object. But none of it really made much sense.

All I can say is, when deciding how to save your file, in a non-school environment (school should always tell you what they want from you) and your employer/task manager for any project you are working on doesn't tell you what to save it as, look at the program requirements, how the information was previously handled and see what works best. Of course, I know this place that might help too. Lots of great coders get together to give people like me and you advice. It's called The Java Ranch!

Good luck!!!
13 years ago
Ok, it looks like the line 19, the part that confuses you, is something for you to play with. I do not have this book, but from what I can gather from the program, try commenting out the part that confuses you '//' and then run the program and see what happens.

another thing you can try is to change the 'if' statement in line 22 to false instead of commenting out line 19. Go back and forth a couple of times and see what the changes are. Ask yourself what you think the changes will be in the program before you run it, that sort of thing.

Good luck!
13 years ago

Campbell Ritchie wrote:You might do well to look at a book like this one. The same publishers have one about C#, but there is a more recent edition than that described in our reviews pages.



Thank you! I really appreciate that. That is almost exactly what I was looking for, something to get my feet wet and make the boss happy, but nothing to difficult for me to spend alot of time on, I'm hoping!
13 years ago
Seems the exam is retired, but using some of the information I was able to see where and how I could start. Thanks!
13 years ago
Not sure where to post this, so I am posting here....

I have just started learning Java a while back, and plan on staying with it, but my employer has asked me to learn a little .NET. Well, I don't know anything about .NET, where to go to learn any of it, and what is its general advantages and disadvantages (other than being a Microsoft product). The general tasks will be desktop applications with a little web applications thrown in with a splash of Database thrown in for good measure. I have noticed that .NET seems to be tied to either ASP, VB, and/or C#/C++.

Basically they have applications already made, I will be helping maintain them and possibly update them from time to time. Someone help, I am more lost than Dorothy ever was!
13 years ago
Here is a lesson in both the InputStream and API, so sorry for the rough posting ahead of time!

from the API: <quote> "An InputStreamReader is a bridge from byte streams to character streams: It reads bytes and decodes them into characters using a specified charset. The charset that it uses may be specified by name or may be given explicitly, or the platform's default charset may be accepted.

Each invocation of one of an InputStreamReader's read() methods may cause one or more bytes to be read from the underlying byte-input stream. To enable the efficient conversion of bytes to characters, more bytes may be read ahead from the underlying stream than are necessary to satisfy the current read operation.

For top efficiency, consider wrapping an InputStreamReader within a BufferedReader. For example:

BufferedReader in
= new BufferedReader(new InputStreamReader(System.in)); " </quote>

Now, below that is a bunch of methods, class summaries and things like that. Basically, what this is, is a small description in semi-plain English about what the class does. In this case it takes byte code and translates it to characters for other readers to make use of. In other words, a serialized non-text file that was stored as byte-code.

Hope this helps!

Ok, so the methods contained in the class are methods you may or may not need to use. It just depends on what you need to do with the object or file that you are using. For instance. the close() method closes the file when your done with it preventing memory leaks and such.

Should you see a description that you like, but can't figure out how to implement the method, use Dr. Google by typing in the method and 'examples' after the method name. I also add 'Java' before the method to, so I usually try 'Java method/class example' to help me figure out how to implement, but only after reading the API so I actually learn it.
13 years ago
Good questions! Since I am still learning, this is actually challenging me to answer correctly, so in truth I hope I am giving good explanations.

The FileReader reads files, but to read code, as in objects, you need a BufferedReader. Ok, here is an example:

Let's say you have a string that says: "I have a long eared dog." That is a String of characters and spaces, right? FileReader can use that and pull it from a file for you to do with whatever you like.

BufferedReader, though, can play with serialized objects. Instead of the above string you now have an array of strings: String dog[] = [ "I ", "have ", "a ", "long ", "eared ", "dog." ]; Buffered reader can not only read the String portions of that array, but can actually pull the array out of your stored file for you to use and manipulate as if you had written it directly into your code. This allows you to manipulate files or use files in your code that are of similar type, but specific to different people/needs. A FileReader would have looked at each part as a String whereas the BufferedReader is a little more advanced. The funny thing is the parameters for the BufferedReader would be something like this:

BufferedReader read = new BufferedReader( FileReader( dog.txt ) );

Just because it is more basic in its capabilities doesn't mean it isn't just as important. Understanding their different roles and capabilities are very useful. I would suggest learning how to read the API's so that you can better understand how these two classes, and other classes work together. It will eventually make everything a lot easier for you, and it is definitely a learned skill to read the API's!

Good luck and I hope this clears it up a little!
13 years ago
I am normally a figure it out myself type, but I have to admit, a good book on the subject made my understanding happen leaps and bounds.

As for abstract classes, polymorphism and other inheritances, it will all depend on what it is that you want to accomplish. Interfaces, superclasses, and creating your own packages to import can all have their place for what will make your job easier to do and others to understand.

If I can ever help, I will do my best. I am still just learning, but I always find it easier to learn by helping others. Enjoy the ranch, it is a great source!!!
13 years ago
One way of looking at the differences is in steps. With FileReader you read what? Just the characters, right? so what do you read should you have something other than simple characters? What if you tried storing multiple lines, serialized objects, or arrays? The stored information would simply read as a sentence for the FileReader.

BufferedReader, on the other hand, is more diverse in its capabilities. Using the information it receives from the FileReader it translates that information into meaningful code as well as Strings, should there be any, for you to then convert and manipulate in your program without adding a lot of additional, already been done for you, code.

In the above cake example, it is similar to building a box-mix cake and a cake from scratch with over 200 ingredients, some of which are scarcer and harder to find than others. Some of those ingredients can be used up by dumping in the box cake and then adding your applesauce-extender for that extra large cake!
13 years ago
Welcome to the Ranch! You will get a more official welcome soon I am sure, but in the meantime to answer your questions:

When creating a new object you have to tell the JVM what the object is of, so, by not providing a class before blackberry, it doesn't know what rules to follow for that object. As your programs become larger, this is even more important because of the multitudes of classes and objects created.

The second is about Polymorphism...a discussion better left for when you understand objects a little better and ready to learn inheritance. However you have started learning Java, take it one step at a time. You can also use the Java Ranch site here as well. They have several tutorials that will better explain these concepts.

As for having access, yes and no. It all depends on how your code is written. I am sure I will be corrected on this one, but one is an object of the MobilePhone class with an "is-a" relationship to the Phone class, whereas the second is simply an object of the MobilePhone class that may or may not happen to inherit some of the values of Phone.
13 years ago
Hi, I think your code in lines 237 through 253 may be suspect. See if something there helps you get it in the right direction
13 years ago

Hansjoachim Vonhortenschiem wrote:So, in my minds eye, I can envision an object consisting of members that are part of that objects blueprint (class), members that are inherited from the parents blueprint(thereby becoming part of the childs blueprint), and those members of the parents blueprint that, though part of the child object, are not part of the childs blueprint. These last members still occupy a space in memory and are accessible via parent provided accessor methods.

The upside is that you can have a unique instance of a parents private instance variable to compliment a child object (assuming you have a way to access it).

The downside is if the same unique instance of a parents instance varaible is hugh(!) in memory and you have no use for it whatever.

It just seems hard to believe that Java-Authors would allow such a system in which memory could be wasted in such a way......



You almost have it, the memory allocation is actually part of the Child's requirement. The Child's use of that information is part of the Child, the Child cannot exist without the parents portion. It would otherwise be a programmable immaculate conception, which just like in the real world, we can't make happen. So, the Parent information is part of the child and the memory is not wasted.

My question to you is, have you learned about protected variables and methods? As in public, protected, and private...once you get to that stage you should discover how to indirectly access your parents private variables in a secure way that leads to better programming habits and very little if not no memory being used for no reason. About that stage you should also learn how to release that memory for the garbage collector. I will research the forums and tutorials for a better explanation of this, in the meantime I learned mine in the Deitel 8th edition book, one I highly recommend.

Hope this helps.
13 years ago
There is only one object you may have created, but as I understand inheritance, child1 and child2 is indeed an object that is an object of both ChildCon and an object of ParentCon. Basically, you cannot have a child without a parent but you can have a parent without a child(at least in this example, or you have a fur-baby).

Think through what 'extends' actually does. Now, riddle me this Java-man, what does your ParentCon class inherit even though you didn't type extend or any other inheritable statement?
13 years ago
Thank you, that would be great!
13 years ago