This week's book giveaway is in the Other Languages forum.
We're giving away four copies of Rust Web Development and have Bastian Gruber on-line!
See this thread for details.
Win a copy of Rust Web Development this week in the Other Languages forum!

Jim Waldo

author
+ Follow
since Jun 22, 2011
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
6
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 Jim Waldo

Pat Farrell wrote:I just ran into another of the bad parts. Compare the format strings/encodings in java.util.Formatter
to java.text.DateFormat. Why are the meanings of the same character different? Formatter uses capital Y for a four digit year, and a lower case y for a two digit year. DateFormat uses lower case y for both. There is no way to memorize which is which. Sigh.


If this were the worst thing in Java, I would be pretty content. Compared to, say, the security model(s), this is pretty minor.

This is really more an indication that a lot of people (and a lot of companies) have worked on Java and the associated libraries. While the JCP is pretty good at reviewing the big stuff, inconsistencies like this will creak in. Once in, they are hard to fix without breaking some/lots of code (and making a lot of users unhappy). It is worthy of note, and perhaps a sigh and a curse, but it isn't really a biggie...
10 years ago
As the week is coming to an end, I just wanted to thank all of you for a terrific set of discussions. I can't remember a time that I felt more welcomed by a group, or a time when I found the discussion as interesting (and civilized). The ranch is a great place, and I hope to be able to stick around some time as a non-promotional member.

My thanks to you all...
10 years ago

Pat Farrell wrote:Don't let Mr Waldo hear this, but I don't believe you can become highly efficient and effective in any tool by reading a book or article. I believe that the only way is to work in a group with serious code reviews and a mentor that really knows how to do it. Sit at the feet of a great teacher.

One might be able to become really good working solo after many years, depending on your motivation and effort. But by then Java will be replaced by some other cool language.



We are actually saying the same thing...you just did it in a more compact fashion...
10 years ago

jamal elbaa wrote:we are not always need to ask questions but also to criticize.

I find this way of learning Java is not longer used as most people learn it directly without going through C.

note: sory for my bad english



This may well be true; I'm an old guy so I forget that things have changed a lot :-). On the other hand, the book is really targeted to programmers with some experience, so I think it safe to assume that they have at least heard of C++, even if it is just in admonitions that if they aren't good, they will be forced to program in it.

But you make a good point, and I'll try to remember it in the future. Thanks.
10 years ago

prabal nandi wrote:Thanks a lot Jim for the explaination.. Another question related to same.
When 2 objects extending same class (method codes are shared) are accessing same method; how will JVM decide the service? Because we haven't explicitly declared the method as synchronized.



Whether or not this even could be a problem will depend on whether or not you are using multiple threads in your program, and running on a multi-core machine. If you aren't using multiple threads, or are on a single-core machine, then only one thing is running at any one time. The OS (and the underlying hardware) will make sure that you are not going to run into problems.

On a multi-core processor running multiple threads, there is still an easy answer for the code-- the code is simply copied from one core to the other. So you may have two instances of the code running at the same time. But the code is immutable, so there is no problem with synchronization. Since the code is the same everywhere, it doesn't matter how many copies you have.
10 years ago
This is a very deep question. If I had a good, or easy, answer I'd be a hero (or at least a consultant). And it isn't for lack of thinking about this-- I've been worried about just this subject for a long time.

There aren't any particular books that are going to make you a good programmer or a good designer or a good architect, although there are many that might help. I just finished The Design of Design by Fred Brooks, which is an excellent set of essays on what it takes to be a good designer. I'm still sort of happy with my own essay on this topic, written for OOPSLA 5 years ago.

My own view (for those who don't want to slog through the essay) is that the best way to become a good designer (or a good programmer) is essentially to apprentice yourself to a good programmer or designer, and work with them until you master the craft. Programming (and system design) is as much art as it is science, and the way art is taught is by doing art, receiving criticism, and then repeating the cycle. We do the same thing with programming and system design-- you code (or design), it gets reviewed (sometimes in humbling ways), and we repeat. Different people will learn better from different masters, so if you aren't progressing you may need to find a different master. At some times it is like woodworking, at others it is like Zen. There is no single path, but you can tell the difference between those who have mastered the craft and those that are just journeymen.

So my advice, if you are looking to really improve, is to find someone who is a real master and ask him or her to look at what you are doing and give you feedback. If there is no one where you work, look for an open-source project that seems to work (or look for a new job). Read lots of good code, and try to emulate it. Reading books may help, but it won't get you there. Only practice, and patience, will.

Sorry if this sounds overly mystic, but there is something mystical about good programs and good design. Good luck in your quest...
10 years ago

Gabor Liptak wrote:So your book doesn't cover the proposed (and accepted) new Java7 features?



It would have been quite a trick if it had. My book has been out for over a year, and Java 7 just came out. Further, from what I can see, the new features of Java 7 (with the possible exception of NIO.2, which brings to mind Bullwinkle declaring "this time for sure") are not real candidates for being in the Good Parts...
10 years ago
I wouldn't recommend the book as a first introduction to Java. There are some excellent first books out there (the "Head First" series is terrific). After you have programmed for a while you might want to pick up "the good parts".
10 years ago
The code for the methods is shared by all of the members of a class. That is the general answer.

The more exact answer is that all of the code is shared by objects that have exactly the same class. In Java (as with other polymorphic languages) an object can have many classes that it is a part of, and these classes form the class inheritance hierarchy for the object. Two objects that are of the same class will share the code for their methods unless one is a member of a sub-class which has its own implementation of that method.
10 years ago
So, I have to admit that I haven't looked that much at Java 7-- I'm a Mac user, and Java 7 is not yet available for that platform.

Let me turn the question around-- what things in Java 7 do members here think are good, and which just make the language and environment more complex and harder to deal with? Do the rest of you think I should be interested in Java 7?
10 years ago
Well, I tried to compare Java to something that most people think is most like it-- a C based, object-oriented programming language used for large systems. It isn't that one is more famous than the other, or more used (I find the notion of the fame of a programming language mildly disturbing, and if I was going to compare it to the most widely used I'd probably have to pick COBOL, and no good could come of that).
10 years ago
Here's what I tried to do in the book.

First of all, "good" is a relational term, not an absolute-- a language isn't, I argue, good; a language is good for doing some kind of programming task. I then argue that Java is good for doing large-scale, multi-person projects for software that needs to work reliably and has a long lifetime (and, therefore, will need to be changed).

I then talk about the features of the language that make it good for those kinds of tasks. I do talk a bit about the internals, but this isn't a book about the guts of Java. I do talk about good programming practice. And I talk a fair amount about how you design systems for this sort of thing.

Hope that this helps...
10 years ago

Pat Farrell wrote:
I strongly disagree with the honorable gentleman's claim that Java is a viable candidate to be your last language. I sure hope it is not. If the naming convention was not spoiled by experience with other languages, I might believe that a Java++ or SonOfJava could fulfill that role, but I don't see Java doing it. As much as I'd love to, we have to look at all of java, not just "the good parts".

Maybe if you are approaching retirement, you could claim that Java was a last language. I've been in this business close to 40 years, and I've used at least 20 languages professionally. Each rode into town claiming that it was finally the silver bullet. As Fred Brooks wrote, there is no silver bullet. I don't know what language I'll be using to write software in five years. I expect that it will not be Java.



Well, don't take my off-hand comment too seriously. I'm a monogamist in many things, but I'm a polygamist when it comes to languages. I use a lot of Java, but I also use C, Python, Scala, and a bunch of other languages (including the straight bourne shell when feeling really retro).

My point was that Java is a tool that I'm willing to use when the occasion is right. I don't think it is the first tool that one should learn. But once learned, it stays in the toolbox. Unlike some of my compatriots who do language research, I don't think that there will ever be the one true programming language that is good for all things.
10 years ago
This is an interesting thread...

If I had to choose between the JVM and the Java language, I'd pick the JVM. Not that I don't like the language, but the JVM (and some of the associated libraries) gives a very nice abstraction for a computing environment that gives a new meaning to the notion of portable code.

I've got a whole chapter on this in my book (shameless plug), but what the JVM does is to give a high-level abstraction of the machine that provides a layer of homogeneity on top of the heterogeneous mix of machines and operating systems. The JVM has been worked on enough so that the layer of indirection doesn't have that much cost (and, with just-in-time compilers, may actually give a performance improvement). When doing distributed systems (which is what I have been doing most of my life) it means that you can even move code from one machine to another during the running of a program, which changes the game in a way that most people still don't understand.

I find it interesting that most academic computer language research is now targeting the Java Virtual Machine. Even non-academics, like the Scala folks, are using the JVM as a base. I don't think the Java language is going away. But I think there is a good possibility that there will be a wide variety of languages that will use the JVM as their delivery base, so that you can use whatever language you like and still get the portability of the JVM.

This is why I always thought that people who were building highly-optimized compilers for Java that produced low-level machine code (i.e., avoided the JVM) didn't get it. I also wonder if this puts low-level virtual machines, like Xen, in the position of only supporting legacy code.
10 years ago
Well, if we wanted to be totally binary about things, any part of Java that isn't a good part might be considered a bad part. But I'm less harsh than that; I think that the things are talked about in the book are really good, but there is a lot about Java that is somewhere between nearly good and merely ok.

Of course, there are also bad parts, some of which I talk about in the book. I think generics would have been better if there were runtime support for them, but they turned out better than I had feared. The IO library was clunky enough that they got redesigned to new IO (NIO), and I've heard that there is a new new IO package either in the works or part of Java 7 (I use a Mac, so haven't really looked at Java 7 yet). And the graphics packages have always been something of a problem; getting good performance and being platform independent is a real challenge, and it isn't clear that any of the attempts at a graphics library have really been great.

I personally think that the most problematic part of Java is the security model, which is really a series of security models, one grafted on top of the other. The end result is that most people run their programs with a policy that grants all rights to the program, which is the way around things. This just makes Java the same as other programming languages and environments, however, so you can't really blame Java for having tried to do security.
10 years ago