Peter van der Linden

author
Ranch Hand
+ Follow
since Sep 28, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Peter van der Linden

Ok Valerie,

Your questions are hard to understand for someone who has not read the specification
you are working from. And I am sure that the instructor intends that part of the assignment
be about helping you gain experience with interpreting specifications.

In general, a map stores key/value pairs.
key can be any type.
value can be any type.
For any specific value of key, there must be no more than one value associated with it.

So a reasonable key might be "full name of someone in my close family" - Arthur Jame Smith
The corresponding value might be "Street address of that person". 122 Main St, Chico, CA.
Both of these might be held as a String type.

Note that the "Street address" cannot be a key, because it is very common for
several family members to live at the same address.

I wonder if you could take a step back, and read up more about types, object, values,
as you work though this assignment. Use whichever Java (or OOP) book you have to hand.

The word "token" might mean anything in this context - a subway token, a magic token
(like a cookie), a compiler token (a lexeme).

You are very close to grasping this whole thing, just need to read up a bit more, play around
with the code a bit more, read the API a bit more, try some things a bit more, and then
formulate your questions.

Cheers!

Peter
14 years ago
Hi Valerie,

You phrased your questions very clearly, and I am sorry that you have not found anything
helpful in the Java books that you have looked at to date.

When you have a programming problem, a good approach is usually to try to break it
down into a series of smaller programming problems that are easier to solve. You pretty
much very nearly did that in the questions you posed. All you need to do is "connect the dots".

You can read all about TreeMap in Chapter 16 of Just Java, along with all the other
collection classes, but in case you don't have a copy handy, I'll remind you of some details:
1. TreeMap is just a Map, with a Really Cool underlying data structure.
We won't get into that data structure now (and don't ever need to) but it is called
a "red/black tree" if you want to look it up and learn about its amazing properties.

2. You put things into a map by calling put(key, value). E.g.
myMap.put(myKey, myValue);

3. You check if something is in a Map either by trying to put it in and seeing what you get back,
or by calling
myMap.get(myKey);

So that deals with the Map part of things, yes?

Counter sounds like it should be an int, rather than some class.
Add one to it with counter++;

So all you need to do is get very clear on what the key is and what the values are for
the data you want to store in the Map. (That's what maps do - store pairs of key/values).

And get rid of the bugs in your prototype code, like creating a new treemap every time
you call the token count constructor. You probably only want ONE treemap for the
whole program.

Hope this helps! Cheers,

Peter
14 years ago

Peter, your tip is interesting too... but it's kinda difficult decision for me to tear the book into pieces and make several small parts..



I appreciate your point of view Ko Ko.

What works best for me is to section the book vertically through the spine,
rather than laterally or vertically across the front... Badda Bing! Thank you! I'll be here all week!
Oh wait - looks like it is the end of the week already!

Cheers,

Peter
14 years ago
Sun, like every honest software company, has always wrestled with the conflicting goals of
"get the new stuff out there!" versus "fix the old stuff people are heavily using!"

That text can be summarised as:

OLD RELEASE MODEL
- feature release, 2-3 years apart
- maintenance release, 8-10 months apart
- update release, 3-4 months apart


NEW RELEASE MODEL
- feature release, 1.5 - 2 years apart
- maintenance release, no more of these
- update release, 2-3 months apart

So Sun is saying "we will make the biggest releases and the smallest releases come out
TWICE as frequently, and we will do this by taking effort that formerly went into the
medium-sized releases".

Here is what Sun should do, and what I think they will end up doing in any case:
1. there will be a release, 3 times a year, at or near the end of Feb, June, Oct.
this release will usually be a dot-dot release with just bug fixes in it.

2. periodically, marketing will announce a feature release. That will take the place of
the next dot-dot release.

Inside Sun, there will be
two "trains" under development - the next feature release, and the next
dot-dot bugfix release. The bug-fix release code base is brought over into the
feature release at daily or weekly intervals. But no code ever goes from the feature
release into the bugfix release.

In this way customers can be assured that the dor-dot release is stable.
And that the feature release never "drops" a bug fix.
These two attributes are critical.

We'll see. It's good that Sun has planned out how they will make releases. They
now have a target to stick to.

Cheers!

Peter
14 years ago
Hi Ko Ko,

I wrote some early chapters based on Java 5 version Beta 1.
As soon as Beta 2 came out, I switched to that. I recompiled and
retested all the code examples, and I think I got almost everything that
changed.

There was just one API change that I did not find in time; it had to
do with getting a Scanner object (old way: use a factory method;
new way: just use a constructor). I put that in the errata sheet which
I maintain at http://afu.com/jj6
And it has been corrected in the second printing, which is the one flowing
into stores now (Yes! A second printing already!)

As far as I know there have been zero API changes between Beta2 and FCS.
But if anyone does find something, I would love to hear about it.

Cheers,

Peter
14 years ago


How would you say your book deals with this? [trading off simplicity for comprehensiveness]



You raise an excellent point here Gregg, and it touches on the answer I mentioned yesterday
when a forum member asked "How did you choose which 'static' things to put in this chapter,
and which 'static' things to defer?"

I answered that there are several tradeoffs, (just as you are pointing out) and you have to
pay attention to all of them, and not let one specific goal drag you away too far from the
others.

My perspective differs a little from yours - I wouldn't say most of the Swing books suffer
from giving you the basics but not the best practices. Most of the Swing books I have seen
go too far in the other direction - in an effort to write down every nugget of information
that has been hard won, they bloom up into one thousand plus page gigantic volumes.

Tip: When I have a book like that that I want to carry about and read, I take a box cutter
knife, and cut it into several more manageable sections of 250-300 pages. I then
reinforce the binding with duct tape, and viola - a big violin! No, I mean, voila - a series of
much smaller texts that are individually easy to carry around. They look a bit funny on your
bookshelf, but having unworn books on your bookshelf is a sign you didn't need to buy it
in the first place.

So yeah, I acknowledge the issue and say there is no perfect answer. One thing I sometimes
do is explicitly say when there is more to a topic than we touch on. That way the reader
knows that another more specialized book will give additional information. Realistically,
the most we can do with some large libraries (such as the servlet library) is to say "this is
how the mechanics of it work. This is a working example that you can put on your system
and play around with. This is a set of steps and things you need to know." I think most
people will understand that book level treatments, rather than chapter level treatments,
will be able to delve into best practices to greater depth.

I am currently working on a book to bring Windows users to Linux, and I am explicitly
including "sidebars" in there that outline Best Practices. But it is simpler to do in a Linux
book, because many of the practices in the Windows world are so poor. I am thinking of
things like security precautions, and regular backups.

Hope this helps, cheers!

Peter
14 years ago


how can I get rid of the Thousands-separator in a Long data type object?
I have looked all over NumberFormat, and can not find a function to accomplish this.



It doesn't work quite like you think it does.
You generally don't want to use NumberFormat, unless you are happy with the
default format for your locale, which you are not.

You want to specify your own format, one without "," separators.

Take a look at the API for java.text.DecimalFormat. There is a constructor that
takes a String arg that lets you specify how you want the number to look.
That is the one you want.

Cheers,

Peter
14 years ago

0181 --> 1220
where
the first two digits represent the month
and the second two digits represent the year.

how I can store a number such as 0299 within an integer?



Well, leading zeroes are only meaningful in Strings.
So you're range is actually 181 .. 1220
and ints can hold those without any problems.

A much bigger problem for you is that consecutive dates, like Dec 2003 and Jan 2004
are NOT consecutive numbers ( 1203 and 104, respectively).

This is a horrible way to code dates, and I am sure the instructor set the problem
partly with that in mind to see how you tackle it.

You can read the straight story on all types in Java in my text Just Java. It's
important to get a good understanding of basic types and what they do, so I wrote
that down in some detail.

Cheers aj, you are going to have a lot of fun learning and programming Java!

Peter
14 years ago

Do you think accessing static field, using "this" variable or an instance of the class should be made illegal? So that the possibility to mislead the reader of the code would be low.



As you point out Ko Ko, some compilers already issue a warning when a static method is
qualified by an object reference. I think the piece that needs tightening up is the JLS - the
Java Language Specification.

It should definitely outlaw the practice of using an object reference to reach a static method or
data item. And then all compiler writers and programmers would know wher they stand.

However, this is probably not seen as a priority compared with, say, improving run time
performance. So it probably won't happen any time soon.

Cheers!

Peter
14 years ago

Also, I had thought a clone was a copy, but from what I've read, I'm now starting to think it's a copy but one that shares the same memory address as the obj being cloned. Is that correct?



Eeeek! No! A clone is a copy of some object. That means that all the data fields in the object
get copied to a fresh area of memory, and the address of that fresh area is returned from
the clone() method.

Now... some of the data fields that were copied might themselves be a reference to some other
object. What do we do with them? Do we follow the reference to that other object, and also
make a copy of *it*? And what if that second object that we just copied also contains references
to a third object?

Making copies of an object and copies of everything it refers to, and so on is termed a "deep copy".
Making copies only of the first object data fields, and sharing the objects that it refers to
is termed a "shallow copy".
Shallow copies are done by default in Object.clone().
But you have the ability to override Object's version of clone() and provide a deep clone if you
wish, or a shallow clone() or indeed anything in between.

Hope this clears it up.
Cheers,

Peter
14 years ago

Could you clarify a bit the reason(if there is) why you didn't try to cover all static data, static methods, static blocks and static classes into chapter-6, which is titiled as Static, Final and Enumeration Types?



Hi Ko Ko,

You raise a good point here, which is "how does a writer decide what to cover in a chapter"?

The answer is that it is a tradeoff with many competing elements. The two starting points
are that you know there is some amount of material relating to topic A that you want to cover.
And you know that readers cannot tolerate a chapter longer than a certain length, no matter
how interesting you try to make it.

So those represent the boundaries for the material - one pushing to get more in, and the
other pushing to keep it smaller and more manageable.

The chapters before this one cover most of the other elements in the Java type system, so I
knew that it was time to introduce enums. However, I had not covered static or final yet.
And since enums are final static objects, that was absolutely necessary groundwork, and in fact
a logical place to put them.

However, I certainly didn't want to bring in all the other uses of static too, like static imports,
static blocks, and static classes. They are not necessary to understand enums, and they
would balloon the chapter up in size. So you make a deliberate decision to postpone that
part of static, and just deal with the things people need to understand enums.

Every writer makes this kind of tradeoff (though they all make different decisions about
what to split off and to where). One of the ways to judge a book is to look not only at
what it covers, but also at how consistently it covers it, and in what order. Whenever I look
at a new programming language book, one of the first things I look for is an explanation of
associativity (assuming the language uses associativity to parse its expressions). This is a
topic that is often poorly understood and poorly explained. But it is *essential* for a proper
understanding of how expressions are evaluated. Try it! Pick up your favorite programming
book (not just Jave book) and look for the description of associativity!

Cheers,

Peter
14 years ago

Do you have any other name that should be used rather than the name "static"? I just would like to know your personal opinion on its name...



Hi Ko Ko,

Well, you have put your finger on the key issue! It is a lot easier for me or you or anyone
to point out a flaw, than it is to provide a solution which is obviously better.

We are looking for a word that suggests "unlike all the other fields, this one is not part
of an object". A word like "independent" or "class-level" or even "belongs-to-class"
could possibly suggest that.

It would also be good if the same word could be used with static blocks to suggest
"there is only one of these", perhaps a qualifier like "one_time" or something.

Or maybe there could be a special section in a class labelled as the "belongs_to_class" or
"one_only_for_the_whole_class"
section in which all the static things go. Or maybe we should have the special section
called "one_for_each_object" and it contains all the non-static things. Or maybe have both
sections and try to find shorter names for them.

There probably isn't a perfect solution for this, but I still think "static" (the name) sneaked
into Java from C, when it should not have even been in C (as a name, not a feature) in the
first place!

Do other people have any suggestions on changing this name to make it easier to understand?

Cheers,

Peter
14 years ago


by Sun Microsystems Press as in the cover of the book on the book's home page at Sun site
or
by Pearson Education as in the Product Details section of the book's home page at Amazon site
or
by Prentice Hall as in your message above



Well, as you might expect, the answer is "yes".

When I worked at Intel in 1981 the company was a lot smaller, and success was by no
means as assured for them as it is today. In fact I was working on a project that was very
secret and very risky technically. I spoke to one of the executives about how an area of it that
was going well seemed to have a lot of people taking credit for it, including some people
that didn't seem (to me) to have made much of a contribution.

The exec (now an Intel VP) looked me in the eye and said "Success, Peter, has many fathers,
while failure is an orphan". I knew at once what he meant! When something is going really
well, everybody wants to associate themselves with the action and get a bit of credit for
themselves and their group.

Hmmm, what made me think of that? Anyway, getting back to your point, since the very
first edition nearly ten years ago (yikes!) Just Java has been published by Sun Press.
And Sun Press is a joint venture between Sun Microsystems and Prentice Hall. Similarly, there
has been a lot of consolidation in the publishing industry, and Prentice Hall is now owned
by Pearson Education. Pearson Education is a wholly owned subsidiary of Pearson - the
international media company. I haven't looked to see if they claim credit for Just Java on a
website somewhere, but well you know, if not they probably soon will.

Fact is that Just Java has been a very successful technical book indeed. And this is
because it gives you, the reader, information you need, in a way you can use it. Just Java
has been in print for about 9 years, when most technical books have a half life measured in
months. It has been published in countries around the world (you should see my mailbox!),
and been kept up-to-date with Java's evolution over six major releases 1.0 to 1.5, corresponding
to the six editions of the text.

I like to get feedback from readers, and I do my best to include the top suggestions. I also
get great input from the Java classes I teach at nearby beautiful Foothill College in Los Altos
Hills. And I was deeply honored to find the text was one of 3 books nominated for Java Book
of the Year in 2002. The new sixth edition (fully up to date with Java 5) has just been
nominated for Java Book of the Year for 2004.

So fingers crossed for good luck, and that is why so many groups in the publishing chain
are pointing out their involvement!

Cheers,

Peter
14 years ago
> And what else should I consider -- from a Java SE perspective --
> in making "the switch" to Mac?

I use the Mac a lot. My main desktop system is a Mac. What's not to love about the Mac ?
Since Apple changed to Berkeley Unix with MacOS X (what, 4 years ago now?) MacOS is just
Unix with a really cool GUI.

And the hardware is better styled and better quality than the junk you get in the PC world.
And Apple actually carries out hardware and software innovation, unlike Microsoft which
just talks up a big story about it. And if you do have a problem, you go to one vendor to
straighten it out, not suffer a lot of finger pointing about "it's the sw/no it's the hw."

And every Mac on the market today comes with video creating software, so you can take the
video you shoot and turn it into CDs/DVDs. If you live a long way away from your family,
that's a cool way to stay in touch. Don't even talk to me about the nightmare of
integrating add-on video cards, drivers and software to a PC.

And I love the free video chats I can do with my brother and sisters in England, using the
iSight camera. No need to run up phone bills. Yes sirree! Love them apples!
Apple is the great big secret of the IT world for people who actually want to get stuff done
rather than fritz around with goofy service packs and the like.

Coming back to Java ... since Apple is just Unix, there should not be any hidden issues for you.
Apple has invested a lot in Java, and done an awesome job of integrating it with their
desktop GUI (actually a finer job than Sun has done of integrating Java with Solaris!)
I can't think of any issues.

But there is a terrific book from O'Reilly called MacOS X for Java Geeks that well repays
a study.

Lets hear it for enthusiasm for platforms! Yay!
Cheers,

Peter
14 years ago
Also....

One other thing to watch with removeRange()

It is one of those devastating routines where the arguments are not (lower, upper),
but (lower, upper_plus_one). In other words, you have to give it an upper argument of
ONE BEYOND WHERE YOU WANT TO DROP FROM THE LIST!

Say you have a Vector of strings:
"egg salad", "labrador", "poodle", "dalmatian", "spaniel", "soup", "cheese"
and you want to take out the range of dogs. You must give the arguments
removeRange(1, 5) NOT removeRange(1, 4); as you might assume.

I don't see enough of your code to know if you got this right or wrong, but it
is a convention that often introduces bugs, and the online API doesn't spell it out
as well as it should.

Cheers!

Peter
14 years ago