Slashdot Mirror
Developing Java Software
Simon P. Chappell writes "It's good to learn a programming language, but it's a far better thing to learn to write programs in that language. What the world needs are less programming language books and more books on programming with the language of your choice. Enter Developing Java Software, 3rd edition by Russel Winder and Graham Roberts. Dr. Winder is the primary author and I became aware of this book when he mentioned it on the Groovy mailing list. Knowing him to be an intelligent and helpful member of the Groovy development team, I rushed to suggest that I could review it for him." Read the rest of Simon's review.
Developing Java Software (3rd edition)
author
Winder and Roberts
pages
885 (19 page index)
publisher
Wiley
rating
7/10
reviewer
Simon P. Chappell
ISBN
0470090251
summary
A good book for learning to write programs with Java.
Developing Java Software is a text book, and is targeted towards university undergraduates, most likely in some form of computer science curriculum. It is also completely suitable for self-learners who want to teach themselves how to write software in Java. The book has been used by the authors when teaching undergraduate classes at University College London, so it has been fully tested in the academic environment.
There are five parts, with twenty four chapters between the first four parts and ten appendixes in the fifth. Each of the chapters are short, most are less than 40 pages, tightly focused and fairly self-contained.
The first part, the longest of them all, starts out with the introduction chapter that no book is complete without. Really, how many people who want to learn Java don't know that it used to be called Oak and was originally designed for set-top boxes? Anyway, after that little excursion, the book moves onto useful stuff like "Programming Fundamentals", introducing concepts like statements, variables and expressions. Next is "Adding Structure" where we discover methods and control structures. Chapter four is "Introducing Containers" and does a good job of covering arrays and the whole slew of container data structure classes in the standard library. Chapter five is a little time off for good behaviour, where we get to spend some time "Drawing Pictures" before heading into chapter six for "Classes and Objects". Chapter seven explains "Class Relationships" while chapter eight introduces us to "Exceptions". Chapter nine is "Introducing Concurrency with Threads". We finish up with chapter ten covering "User Interfaces".
Part two addresses the "Process of Programming" and this is where it really differentiates itself from the rest of the Java book crowd. Chapter eleven gives an overview of "The Programming Process". Chapter twelve begins the process of making that real by addressing "Unit Testing". Chapter thirteen continues the story with "Test-driven Programming Strategies". More practical advice comes in chapter fourteen as they introduce the reader to "Programming Tools".
Part three brings two "Case Studies in Developing Programs". Chapter fifteen introduces the case studies. The first study, "Contacts Book" is in chapter sixteen and the second, a "Pedestrian Crossing Simulation" is in chapter seventeen.
Part four is "The Java Programming Language in Detail". This is the more reference portion of the book and it's seven chapters cover variables, types and expressions, flow-control, classes and packages, inheritance and interfaces, exception handling, threads and concurrency.
Part five is the "Endmatter" and holds ten appendixes.
The first thing to like with this book is that it has an engaging style. The style comes not just from the body text, but also from the notes, tips and references in the margins of the book. As someone who learned Java almost ten years ago, I have difficulty plowing through yet more body text explaining the same old stuff that every other Java book covers; yet, jaded and cynical as I am, I enjoyed the sparks of honesty and humour in the text.
As I alluded to in my opening remarks, this book takes the approach of trying to not only teach Java, but how to approach and actually write programs using Java. The book takes an iterative approach and emphasizes the use of testing tools. Interestingly, they use TestNG rather than the de facto standard JUnit. This is the first book that I've seen that uses TestNG; perhaps JUnit is finally getting some competition?
The book is completely targeted at Java 5. All of the code examples use the new features where appropriate. This makes the book worth considering for those that already know Java but want to finally climb onboard with the latest version.
Naturally, there is a website available at www.devjavasoft.org where all of the source code for the programs in the book may be downloaded, together with answers to the exercises and any updates or revisions of the material in the book.
One of the challenges of writing or updating a book of this size is that it's possible (nay, almost guaranteed) to miss important things. The tip at the top of page 190 is a classic example, where the reader is advised that calling System.gc() will force the Java Virtual Machine (JVM) to perform a garbage collection. This is not, and has never been, true. The most that the System.gc() call will do is let the JVM know that now would be a good time for it to garbage collect, but there are no guarantees that any collection will actually take place. With this being the third edition of the book, I expected errors of this sort to have been caught by now.
Another point to consider is that with this being a textbook the writing style is less like a mass-market book and it also includes questions and exercises at the end of each chapter. I normally avoid books of this sort, although this does seem to be one of the better ones.
I hate being picky about typography, especially with the average level being quite good these days, but this book is set in a smallish font for the amount of text on each page. It is a serif font, but I didn't find it the most comfortable to read. Also, and this is the most egregious fault in the whole book, the program listings are set in a proportional font! I could hardly believe it when I saw it. While I realize that the authors are unlikely to be responsible for the final font selections, I fear that it damages an otherwise strong book and does them a disservice.
This is a good book for learning Java. More importantly, it's a good book for learning to write programs with Java.
You can purchase Developing Java Software 3rd edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Developing Java Software is a text book, and is targeted towards university undergraduates, most likely in some form of computer science curriculum. It is also completely suitable for self-learners who want to teach themselves how to write software in Java. The book has been used by the authors when teaching undergraduate classes at University College London, so it has been fully tested in the academic environment.
There are five parts, with twenty four chapters between the first four parts and ten appendixes in the fifth. Each of the chapters are short, most are less than 40 pages, tightly focused and fairly self-contained.
The first part, the longest of them all, starts out with the introduction chapter that no book is complete without. Really, how many people who want to learn Java don't know that it used to be called Oak and was originally designed for set-top boxes? Anyway, after that little excursion, the book moves onto useful stuff like "Programming Fundamentals", introducing concepts like statements, variables and expressions. Next is "Adding Structure" where we discover methods and control structures. Chapter four is "Introducing Containers" and does a good job of covering arrays and the whole slew of container data structure classes in the standard library. Chapter five is a little time off for good behaviour, where we get to spend some time "Drawing Pictures" before heading into chapter six for "Classes and Objects". Chapter seven explains "Class Relationships" while chapter eight introduces us to "Exceptions". Chapter nine is "Introducing Concurrency with Threads". We finish up with chapter ten covering "User Interfaces".
Part two addresses the "Process of Programming" and this is where it really differentiates itself from the rest of the Java book crowd. Chapter eleven gives an overview of "The Programming Process". Chapter twelve begins the process of making that real by addressing "Unit Testing". Chapter thirteen continues the story with "Test-driven Programming Strategies". More practical advice comes in chapter fourteen as they introduce the reader to "Programming Tools".
Part three brings two "Case Studies in Developing Programs". Chapter fifteen introduces the case studies. The first study, "Contacts Book" is in chapter sixteen and the second, a "Pedestrian Crossing Simulation" is in chapter seventeen.
Part four is "The Java Programming Language in Detail". This is the more reference portion of the book and it's seven chapters cover variables, types and expressions, flow-control, classes and packages, inheritance and interfaces, exception handling, threads and concurrency.
Part five is the "Endmatter" and holds ten appendixes.
The first thing to like with this book is that it has an engaging style. The style comes not just from the body text, but also from the notes, tips and references in the margins of the book. As someone who learned Java almost ten years ago, I have difficulty plowing through yet more body text explaining the same old stuff that every other Java book covers; yet, jaded and cynical as I am, I enjoyed the sparks of honesty and humour in the text.
As I alluded to in my opening remarks, this book takes the approach of trying to not only teach Java, but how to approach and actually write programs using Java. The book takes an iterative approach and emphasizes the use of testing tools. Interestingly, they use TestNG rather than the de facto standard JUnit. This is the first book that I've seen that uses TestNG; perhaps JUnit is finally getting some competition?
The book is completely targeted at Java 5. All of the code examples use the new features where appropriate. This makes the book worth considering for those that already know Java but want to finally climb onboard with the latest version.
Naturally, there is a website available at www.devjavasoft.org where all of the source code for the programs in the book may be downloaded, together with answers to the exercises and any updates or revisions of the material in the book.
One of the challenges of writing or updating a book of this size is that it's possible (nay, almost guaranteed) to miss important things. The tip at the top of page 190 is a classic example, where the reader is advised that calling System.gc() will force the Java Virtual Machine (JVM) to perform a garbage collection. This is not, and has never been, true. The most that the System.gc() call will do is let the JVM know that now would be a good time for it to garbage collect, but there are no guarantees that any collection will actually take place. With this being the third edition of the book, I expected errors of this sort to have been caught by now.
Another point to consider is that with this being a textbook the writing style is less like a mass-market book and it also includes questions and exercises at the end of each chapter. I normally avoid books of this sort, although this does seem to be one of the better ones.
I hate being picky about typography, especially with the average level being quite good these days, but this book is set in a smallish font for the amount of text on each page. It is a serif font, but I didn't find it the most comfortable to read. Also, and this is the most egregious fault in the whole book, the program listings are set in a proportional font! I could hardly believe it when I saw it. While I realize that the authors are unlikely to be responsible for the final font selections, I fear that it damages an otherwise strong book and does them a disservice.
This is a good book for learning Java. More importantly, it's a good book for learning to write programs with Java.
You can purchase Developing Java Software 3rd edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Good advice for Java 1.5 and up, but without autoboxing you'll be using primitives because of their pervasiveness in the JDK.
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!
You know, I bet it's also a good book for learning how to develop applications with Java.
I think after checking this out more on Amazon.com I am going to pass on this particular book. Not only is it $65... $15 more than usual Wrox books (which I personally like) but it also seems to have a lot of condensed information with potentially useless programming situations... I find it hard to believe that the reviewer did not find much wrong with the book and only gave it an 7/10? If we convert that into a grading scale, obviously thats 70%... thats struggling to get points across, and will be adequate for basic points ofr JAVA 5. As a suggestion, I would love to see a review of a good JAVA 6 book, so I know what others have checked out, so I can make an educated decision on what my nice shiney new JAVA 6 book will be.
-- Josh
"Whoopie! Man, that may have been a small one for Neil, but that's a long one for me!" - Pete Conrad
...is Bruce Eckel's Thinking in Java which has already invented the idea displayed here. Thats why you'll see that this book (tij) doesn't fully go into the bare Jave code but mostly reflects on the things which really matter. Knowing what things like Objects are, why objects differ from primitives, etc. Being a Java enthousiast myself it still amazes me how many people "program in Java" yet never learned how to interpret the JDK documentation, especially the so called API documentation.
Anyway, the Thinking in Java book is both available for free download (see URL above) and if you wish a hardcopy (or the latest release) then you can also purchase it. In my opinion this is a much better book which is also presented in a more fair way.
chapter ten covering "User Interfaces".
Was the ink from the first printing dry before Chapter 10 became outdated and deprecated?
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
It's good to learn to write, but it's much harder to learn to write a good review.
Intron: the portion of DNA which expresses nothing useful.
This might be a good place to ask this question. The only Java EE 5 text that I have with me is the Java EE 5 Tutorial. Is there any other (More detailed, better written) book on the same topic that Slashdot readers can recommend?
Funny, I was reading that and thought to myself that it was overqualified. What they ought to say is It is good to learn many programming languages, but it is a far better thing to learn to write programs
How does the Slashdot Effect happen given that no slashdotters ever RTFA?
I can't disagree more. Most programmers already know programming pretty well, and don't need their books on specific programming languages to be diluted with general programming instruction. Each of us is a programming amateur just once (I hope), but learns many additional languages throughout his career, and I think we want those non-newbie books to be concise and get to the point.
Every new programmer must learn to program in some language, but we certainly don't need a large variety of books that cater to people at that stage of proficiency - just one or two good ones.
... is more skilled programmers. I learn new languages from the language specification. Once you know how to write code in one language, and you actually _understand_ what you are doing, picking up a new language is easy.
Any Java book that starts with explaining statements, control structures etc. without first explaining what an object and a class is, does not sound very promising. In the CS educators community there is a movement towards an 'objects-first' approach in teaching JAVA, or more precisily, OOP using JAVA. Any book that typically starts with a 'hello world' program completely misses the point. First teach what an object is, what a class is, only then say something about how you can make these objects work together. This seems to be a much more fruitful approach in teaching students how to think OO, and then to put their ideas into any programming language, which happens to be JAVA in many cases. For a very good book to use in a programming 101 class, see 'Objects First With Java' by Barnes&Kolling (Prentice Hall; 3rd edition; June 2006)
To be fair, the typeface must have been really abysmal. I mean, it knocked 3 whole points off the score of an otherwise perfect book!
I can't recall ever having a grade on anything I've written drop from an A+ to a C- based on what font I used. This guy REALLY hates proportional fonts.
Are you willing to bet the cover price of the book on that?
The Spoon
Updated 6/28/2011
With a preface like this: Knowing him to be an intelligent and helpful member of the Groovy development team, I rushed to suggest that I could review it for him. I assumed this would be a bit of a biased review. I think your assessment is accurate. The review author is ass sucking and complains only when he realised he got a hair in his mouth.
Not saying it's a bad book. I agree strongly with his statement about recent college grads needing more knowledge about how to develop software. It's just hard to take the review serious with the bias that came along with it.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Autoboxing still comes at an instance-construction expense, no matter how well-tuned the implementation.
I'd much rather see signatures that distinguish between intrinsic and box arguments, as it allows fine-grained performance tweaking.
I am rather disappointed that we still don't have unsigned types in Java. It really is critical for providing efficient mapping of XML types, database types, and CORBA/IDL/IIOP interfaces. I'm also going to have to find an appropriate library that will map Java's 64-bit signed millitimestamp intrinsic to local platform libraries/data types. Mapping BigInteger and BigNumber at that lower level is probably inconsistent as well.
XML string types are trivial. Just use a string pattern to validate setter arguments.
I do not fail; I succeed at finding out what does not work.
Which you can't, because like half of java.lang, Integer is final, which means no other classes may extend it. Because, of course, no one would EVER want to add new attributes to Strings. (Like, say, font information, color info, minor things like that.)
"It's good to learn a programming language, but it's a far better thing to learn to write programs in that language. What the world needs are less programming language books and more books on programming with the language of your choice"
Not really, I agree with Steve McConnell when in his book "Code Complete" (2nd edition) says that you shouldn't programm in a language but INTO a language.
Most of the important programming principles not on an specific language but on the way one use them. Don't limit your programming thinking only on the concepts that are supported automatically by your language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives with the programming tools at their disposal. (McConnell 843)
Sigs are for morons... Wait a minute...
Please use "Int" instead of "int"... A good JVM will run this code nearly as fast, but the added bonus is that you make your code way more generic. Java is not C++.
Yeah. While you're at it, make sure to store the value of pi in a variable, just in case the value of pi changes in the future.
For a more indepth idea of what the continue keyword is see http://en.wikipedia.org/wiki/Continue_(Java)
The first example of the use of continue made me want to cry!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Yes, but what good is that if you don't know how to achieve enlightenment. Maybe what is really need is a book that teaches the Java language, AND how to go about the development process in a good way while using the Java language, AND how to achieve enlightenment while going about the development process in a good way while using the Java language. I mean, otherwise, what's the point? Or, on the other hand, maybe you just need a book that teaches Java.
I'm not trying to speak negatively about this particular book's contents, but just comment generally in response to a previous poster's reply. I think what we need less of is books that tell us how to use API's and control structures and logic as such. What we really need is a shift in the way we're taught to program in schools to mimic real world software creation. This book would more appropriately been titled "How to Program in Java" because development in the real world is quite different from just learning the language specifics. Software development is more about the deadlines you need to meet for the customers end and the balance between the most technical solutions and the most feasible ones. Essentially it's about the efficiency you complete a task given constraints of time and resource. We should stop writing books that just walkthrough different languages, and start teaching students in a way that places them in team projects and make them collaborate to complete projects. My undergrad school had only ONE class that was designed in this fashion, yet I would say that almost 100% of my work existence operates in this reality.
So why not just write a class called FormattedText and define a String member variable rather than make String a base class? After all, the methods you'd inherit from String are all relevant only to the actual character content, not formatted character content, and so can be called on the toString method.
A 1 to 10 scale for a book is not the same thing as a 0 to 100 grade in a class. The average grade in most of your classes is probably 70 (undergrad) or 80 (grad); the average rating for a book on a 1 to 10 scale should be 5.
A good JVM will run this code nearly as fast...
Translation: "Lots of JVMs will run this code so slowly that your customers will think their machines have locked up."
In some cases it is possible to control what JVM your customer uses. I once managed a Java dev team that produced great, fast code, including excellent Java3D graphics stuff. But performance on some customer's machines was terrible, because they were running one of those all-too-common JVMs that wasn't so good. My solution was to ship a good JRE as part of our install, hidden away in the application tree and used only by our application (thereby not breaking every other application on the machine that depended on the bad JRE's bugs.) This increased the size of our installer by 15 MB or so, but it was worth it to get a better customer experience. Our support calls dropped to almost nothing after that.
However, not everyone shipping a Java application has this luxury, particularly those writing fo rthe Web. To suggest to those people that they should adopt some particular programming practice because it won't cause major issues with a "good" JVM is like telling a drowning person that water is necessary for life. It's true, but it isn't the least bit relevant to the practical predicament the person is in.
Blasphemy is a human right. Blasphemophobia kills.
My current favorite Java programming book is Java Concurrency in Practice by Broan Goetz and others. It's not for beginners, but if you really want to understand how to write multi-threaded code in Java you need to read this book. Several times, probably, because it's a tricky subject.
Other books I like for Java are Effective Java (though he needs to update it for Java 1.5) and Java Puzzlers.
I don't know of any books that are good descriptions of the Java 1.5 features for experienced programmers. Some people like Thinking in Java, but it seems pretty wordy to me. I originally learned Java from Java in a Nutshell but it's been something like 8 years, so I don't know if the newer editions are any good.
Disclaimer: some of the authors of these books are my co-workers, though I don't know them very well.
Well, personally, I had my grade drop from an expected A+ to an F when I used nothing but wingdings in a 10 page paper...
Slashdot is proof that Sturgeon's Law applies to mankind.
Comment removed based on user account deletion
I'm finally glad to see some truly wise words, not to be mistaken for the more popular cynical opinion I see. I have experienced this myself. With that said, I would hope the title reviewed does focus on how, as you appropriately quote, "accomplish their objectives with the programming tools at their disposal".
The professors' plight: Every year the same material, just a different group of wingdings.
Attention zealots and haters: 00100 00100
So... Why do we need a VM in the first place? Computer hardware isn't that slow these days, but computers do seem slow -- because they run VMs, JIT-compile all the time, etc. I call it "VM hell" that we are all in. No, we, in fact, ain't need no stinkin' Java or .NET (are we).
You might want to check out this cool new markup language called "HTML" (hypertext markup language). It will allow you to bold or italicize words, thus obviating the need for surrounding words with underscore characters to indicate emphasis.
Of course, if you're really 1337, you'll pretend you're on a terminal with non-destructive backspaces and use a construct like this^H^H^H^H____ for underlining.
Sometimes theory has to bend to make room for the practical.
I do not fail; I succeed at finding out what does not work.
Java is not C++.
Neither is it C# - you'll be wanting Integer, not Int, except that for large amounts of number crunching that's a truly horrible idea. Mind you, for large amounts of number crunching Java isn't a particularly good idea in the first place if performance is key.
It's official. Most of you are morons.
I'll be the first to defend the fantastic job dynamic compilation can do (such as automatically inlining calls to virtual function if it decides it can - and uninlining when it can't anymore), or the GC (like the new generation pretty much behaves as allocating on the stack).. BUT.
This is just moronic.
True, javac and the JVM will automatically translate Int(eger)s in ints when they can, and thus it will be as fast... As long as you don't store it in an object, or pass it to a virtual function that the JVM can't inline. Because then it has to create the actual object, it will have to dereference it everytime it's used, and the GC will have to deal with it.
Second, it's not "more generic" in any way, since Integer is final - so you can't specialise - and, OTOH, java will autobox an int as needed - so you're not actually gaining anything -.
Third, using Integer opens you to NullPointerExceptions
This is the kind of "rule", defended through a lack of understanding of what's going on behind the scene, that is causing much of the performance problems some Java programs have.
Learn the libraries to write fast code. Don't concatenate, use StringBuffer-s. Don't use buffer.append("a" + "b") - kinda defeats the purpose :) . Don't copy arrays to add an element, use Vector/ArrayLists. Don't do linear search, use Hashtable/HashMap. Don't insert into sorted arrays/vectors, use TreeSet. Don't search inside a Vector, use HashSet. Learn how to write objects that can be hashtable keys (i.e. they must have proper equals() and hashCode()). Learn how to write objects that can be used inside Tree-s (i.e. they must be Comparable-s that have proper equals() and compareTo()). Learn how to make objects sortable or implement Comparable correctly.
Yeah, kinda basic but you will be amazed what kind of speed improvements you can get by learning these and using them whereever it is appropriate. With the proper data structure (most of them are already in the JDK) your app will fly.
Oh, and don't redraw AWT/Swing like crazy. That's why the app is so slow. Learn how to use invokeLater to avoid deadlocks/bad data, etc.
Learn how to synchronize properly with no deadlocks and what wait() and notify() are for.
Learn char and byte streams and learn memory streams (ByteArrayInput/OutputStream, etc).
Learn to love try-finally for dealing with streams.
Learn to log.
Learn by writing actual app code. Nothing beats that.
First of all, String and the primitive wrapper classes are used by most of the core classes like ClassLoader and Class. If they could be overridden, it would be a gigantic security hole. Also, many crucial mechanisms rely on those classes' immutability, so allowing for the possibility of a mutable subclass would introduce considerable instability.
Second of all, people all too frequently seem to want to use inheritance for every task. Inheritance is not a toy. It's a String and some other data, not a new kind of String or a String with specialized behavior. Subclass when you must, not whenever you can. As someone else pointed out, you're far better off using a class (such as java.text.AttributedString) that aggregates a String and your other attributes of interest.
The Internet is full. Go away.
As a c programmer trying to learn Java I grabbed a couple of books and looked at a lot of online tutorials. The one book that really "opened it up" for me was O'Reilly's "Java Network Programming". Mostly because I was not the least bit interested in writing GUI apps and every other "learn to program Java" book I found figured all you really want to do is learn to write an MS Paint clone. I understand having a real life example to teach concepts (and OO programming in general was hard for me at first) but I have a hard time getting into it if I am totally disinterested in the examples. Network Programming just seemed to present everything better and used examples that I could see relevance in.
The way I learn now is by grabbing good code (various Apache java projects have a lot of good code in them) and reading it, while referencing Sun's online API docs.
Just my $0.02
Finkployd
The disadvantages of VM's are exaggerated IMO, the portability of applications achieved with Java outweighs the disadvantages. (note that this doesn't apply to C# programs written with Visual studio, I'm not sure why C# runs under a VM considering that it was designed for Windows only)
Java may not perform quite as fast as C/C++, but the difference is neglible, and is only noticable in applications requiring alot of processing.
Java programs are however slower to start, since they require that the JVM be started and the JIT compilation to be performed.
The Swing toolkit, IMO, does a huge disfavor to Java in this regard. Because the entire toolkit is emulated, making the GUI slow, contributing to the general perception of Java as slow.
I much prefer the SWT toolkit, since it both integrates better with the native environment and performs better. In fact most people wouldn't be able to tell a Java SWT app apart from a C/C++ GTK/Windows/Mac application.
You don't know as much as you think you know, especially about Strings. To begin with, I suggest you do some Google searches for the phrase "Premature optimization is the root of all evil." Now then...
You don't seem to be aware that the following two lines are either identical, or so close to identical in their execution that you will never be able to discern the difference with any debugger or benchmark:
System.out.println("The product of " + a + " and " + b + " is " + (a * b));
System.out.println(new StringBuffer("The product of ").append(a).append(" and ").append(b).append(" is ").append(a * b));
Details are here.
It is true that in Java 1.0, StringBuffer was always the better way to concatenate. But that was over ten years ago. Modern Java programmers know you don't use StringBuffer unless you're doing frequent concatenations (such as inside a loop). And professional programmers know that readability and maintainability are way more important than saving a few cycles in some logging statement.
Wrong. Concatenation of constants results in a single constant at compile time. In other words, the following lines will compile into byte-for-byte identical bytecode:
System.out.println("Today" + ' ' + "is" + " December " + 13);
System.out.println("Today is December 13");
Feel free to try it for yourself if you don't believe me.
The Internet is full. Go away.
(note that this doesn't apply to C# programs written with Visual studio, I'm not sure why C# runs under a VM considering that it was designed for Windows only)
.NET developers don't need to worry about switching between 32 or 64-bit systems.
It allows the same binaries to run on Windows on different processors -
Java may not perform quite as fast as C/C++, but the difference is neglible, and is only noticable in applications requiring alot of processing.
Actually, it can be the other way around. The more processing, the more chance that the run-time profiling and optimising gets to work, the faster Java runs.
Java programs are however slower to start, since they require that the JVM be started and the JIT compilation to be performed.
The JVM starts fast, and modern Java does not require any JIT compilation before the program starts. Instead the interpreter starts running, and hotspot optimisation kicks in later.
The Swing toolkit, IMO, does a huge disfavor to Java in this regard. Because the entire toolkit is emulated, making the GUI slow, contributing to the general perception of Java as slow.
Was true years and years ago, not now. It isn't all emulated - Swing uses DirectX to write to displays on Windows, for example. I am not actually sure that 'emulated' is meaningful. Swing draws controls using the Windows graphics API. So does every other Windows app. These days, having custom controls is very common (just look at media players).
I much prefer the SWT toolkit, since it both integrates better with the native environment and performs better.
Not true any more either. SWT has a reputation for actually being slower than Swing on at least some platforms, such as X. (Anyway, what does 'native GUI' mean on X-Windows anyway?)
In fact most people wouldn't be able to tell a Java SWT app apart from a C/C++ GTK/Windows/Mac application.
With Java 6, the same is true for Swing - a lot of work has been put into that, especially with the Vista interface.
I'm not the poster of your post's parent, but I did a bit of searching (since I was interested too), and in most cases it seems to be simply that he believed that unsigned types just add complication to little real benefit. He often cites that Java was supposed to be reasonably simple to understand the semantics of, and that unsigned types tend to dilute that. I tend to agree (I never really "got" unsigned types), but here's some indicative quotes:
Source
Source
Hope that's the sort of thing you were looking for. :)
To be fair to Sun and to Swing, they have been improving that library greatly in the last while. The version of Swing which comes with Java 6 (released the other day) is actually really quite good.
Thanks :-) Exactly what I was looking for.
HaHa! It's also a good way to learn how to set your server on fire from 50 people hitting the 'application' at once. Has anyone use docs.sun.com during working hours? It's really like Sun runs this stuff on Windoze. Java is horrible, it's great for the programmer but kills a machine. BTW, does the book discuss how to make the JVM memory footprint smaller?
So, what really goes on with unsigned arithmetic in C?
We did the same thing with our installer when we first had a beta site running Java on Linux. We rolled our own RPM file that would install everything in our directory so it was impossible for the customer to screw it up. Of course I still got support calls about Java on Linux on my personal cell phone at 11 pm on a Saturday evening from that customer, but after 10 minutes of digging it comes out "Well its not really for your product, that works great, which is why I'm calling you to get this other application working."
Have you ever tried to do image processing with signed bytes? This is one of the reasons I have stopped using Java for my personal programming.
That answer makes sense if you assume the only purpose of unsigned types is to perform arithmetic on them. Somehow I doubt Gosling did much real-world embedded development or he would understand that.
In my University, I was taught general concepts: structures, recursion, iteration, abstractions, conditions, logic, programming paradigms, etc., never tied to a specific language. In fact, we used to use a pseudo-language to express solutions to problems.
Real languages (Pascal, X86 assembler, basic, fortran, C, Java, C++, scheme, SQL) were used only in lab practices. It was pre-supposed that you already knew them or you had the basic concepts to learn them.
Whenever I see that someone has been taught an specific language at the university (sometimes a whole semester!), I tend to think that this person will not be able to fullfil his/her position, because he/she has been taugth an specific technology instead of knowledge. It's like a doctor that has been taught how to operate certain medical device instead of how the human body works.
Learn principles and then you'll be able to tell which language is the best at the job.
And as a nice side effect, you'll always be able to catch up with whatever shows up in the ever changing madness of IT.
"Second of all, people all too frequently seem to want to use inheritance for every task."
Actually, these days people all too frequently seem to want to use interfaces for every task.
Most CS departments don't even own drums.
Markup languages are just file formats with delusions of grandeur.
Exactly why I use Integer over int in most cases. With int, you cannot have an undefined value, with Integer you can. Sometimes, the int/Integer may be optional. If there is data there (!= null) I can use it, else I won't. With an int, you can't do that check, it is always defined.
So, like most programming decisions, it all depends on your needs.
"It's good to learn a programming language, but it's a far better thing to learn to write programs in that language.
;-)
And more important than either of these is to be able to successfully modify programs in that language.
Very few of the jobs I've had in several decades of working as a programmer involved writing programs. Far more of the jobs in the real world consist of modifying a program that already exists, either to correct bugs or to add new features. This requires a very different set of tools and talents than developing the software from scratch.
Another way of expressing it is that we rarely actually write programs. Rather, we usually modify programs. And we do this with code that wasn't designed or developed to make modifications easy.
Let's face it; designing is easy. At least, the sort of design that typically comes out of all the methodological fads is easy. That's why people write so many books about it. But they hardly ever tackle the difficult part of programming, which is taking the results of a design and making it actually do what is now needed, which is slightly different from what was needed back then.
And java is one of the languages where the implementation of the design isn't usually done well. As with C++, designers think that their good design will make it all work. When it doesn't, perhaps because the task has changed, and the designers have moved on, the programmers are stuck with trying to make sense of what is often write-only code. It isn't documented, because you don't need that with a good design, right? And code in these languages usually have the property that no line can be understood by itself, because of all the things that are defined elsewhere. And those definitions can't be understood by themselves, because they use things defined elsewhere. Making even the simplest change usually requires a full understanding of every line of the program, because everything depends on everything else.
Maybe some day someone will write a good book on how to modify existing code successfully, without introducing more bugs than were there when you started. This is the really major technical advance that still seems over the horizon, even after decades of mostly bad experience with hacking other people's code.
(One of the most successful techniques I've stumbled across consists of constantly asking myself "What would I like this to look like when I come across it N years from now and want to make a few small changes?" You might be surprised by some of the common mistakes that this helps you avoid. And I've often been happy that I did that, N years after I wrote something.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Try this: And put that in a file called test.java. Run javac test.java. Then run java test. It'll return MININT. You have no way of getting any higher without using a 64bit data type, which is insane.
The sad thing is that I'm fucking wasted and I still get the idea. Gosling's decisions make me mad sometimes.
Slashdot is proof that Sturgeon's Law applies to mankind.
What the world needs is fewer programming language books.
I didn't want to get all Lynn Truss on the lad, but hey, if he can be picky about typography, I can be picky about grammar.
And the culprits are including both user reviews and reviews by professionals, where you would expect the quality of grades being better.
One scandinavian photo magazine, using 1 - 10 grades is actually so bad that you actually have to recalculate the grades. The grades almost always land in the 5 - 10 range, where 5 would mean utter crap. One pretty effective way of dealing with this is to subtract 5 from the original grade and use the result as a grade in the range 1 to 5. So far this "tactic" has worked pretty well.
One obvious reason for magazines and such not giving too low grades are the dependancy of manufacturers actually sending them stuff to review.
Ceterum censeo Microsoftem esse delendam
Right. I replace integers with my own implementations all the time, as the rules of math tend to be so subjective... also (1+2)/5 is so much clearer as new Integer("1").plus(new Integer("2")).divide(new Integer("5"))...
I want to play Free Market with a drowning Libertarian.
I'm not talking about this case, of course. I'm talking about generating a 1 mb XML file, for instance. :)
:) I said: learn about it. Don't memorize, learn.
As for "a" + "b" being evaluated in compile time - yes, but this isn't: (String)myArray.elementAt(i) + " at " + i.
See? I know
One of the main benefits of Java over C++ is memory compacting. Though the newer memory managers for C++ do a great job at arranging the memory pieces in an efficient manner as to prevent severe fragmentation. You are right of course - stl is a great tool, and the others as well.
Actually, System.out.println("The product of " + a + " and " + b + " is " + (a * b)); compiles as System.out.println(new StringBuffer("The product of ").append(a).append(" and ").append(b).append(" is ").append(a * b));
Use StringBuffers or memory streams to build large bodies of text. Use concatenation for dumps / logs / UI (sometimes if you generate 100 UI items via concatenation, it's better to use a StringBuffer and call setLength(0) at the beginning of the loop). Seemed obvious when I was writing the original post.
ohhhh.... a budding flamewar over the best way to do string handling in Java!!!
*gets out popcorn and settles in to watch*
... or java.lang.Math.PI
Gosling has never apparently seen the hoops you have to jump through to emulate unsigned arithmetic with signed types. Yes I am sure the compiler supporting unsigned int's would have been much confusing for us poor inellectually challenged Java devs.
One could get around this problem simply by restricting the effects of the overrides to a subset of classes. For instance, one could restrict it to a certain namespace, or a certain application domain. I should point out that the JVM-based language Nice allows one to override existing methods without incompatibility issues with standard class files, so it's quite possible to have the functionality described without compromising security.
In other people's code, I quite frequently see interfaces with only one implementation.
Yes, I imagine, sometime in the far future, someone *might* possibly think about a different implementation. It happens rarely. In the meantime I have two pieces of code to update every time there is a change to a method signature.
By "emulate unsigned arithmetic", do you mean jumping to the max value when you remove one from zero? Is this something you need to do frequently?
I get a byte from a file. I need to add it to another byte from the file. I need the bytes to be treated as unsigned, otherwise arithmetic operations on them are not going to proceed as expected.
This requires upcasting the byte to an int and doing a bitwise & with 0xFF to wipe out the sign. Then you do your arithmetic with the ints and then downcast back to a byte if need be.
If you think this rare, realize that there are all sorts of byte streams out there that were not created by Java applications, that intend every 8-bits to be interpretted as an unsigned byte.
What a pain. Cheers for that clarification. I realise it's not rare, but it is an interoperability issue rather than a direct issue with Java in and of itself.
There are pleanty of GUI classes to do with formatting et al. The only real issue here, as far as creating a wrapper, is that things that expect 'String's couldn't work with your subclass because there's no way of producing a valid inheretance for it. As ever, there's more than one way to do these things and there are trade-offs in either approach.
Forgive me, but I don't know much about the different flavors of JVMs, since I learned on Sun's and haven't touched any others (unless you count running Azureus on GCJ). Can you give some recommendations about the different JVMs (and the name of the one you chose), or maybe link a comparison chart?
C# doesn't run in a VM. The code is compiled to MSIL then JIT compiled to machine code during execution. There is no concept of a Virtual Machine.
i me
.NET initiative."
This isn't true.
http://en.wikipedia.org/wiki/Common_Language_Runt
"Common Language Runtime (CLR) is the name chosen by Microsoft for the virtual machine component of their
Just because you have JIT compilation does not mean you aren't using a VM. The combination of VM and JIT has been around for decades.
Furthermore, for anyone wanting to know the differences between .NET and Java or wanting some information on how the CLR (.NET VM) works, I found this comparison to be very helpful.
It's not a direct issue with Java as long as you don't intend to do systems programming with it. This is one of the reasons why Java is generally not used for that purpose.
Yeah, along with (generally) requiring a VM, I suppose. I expect it was something of a pain in the ass for the JNode team...
All this is very true.
The flip side is that very often you want a class to do something very similar to a final class String comes to mind for regular expressions and DNA, but there are many possibilities. I'd say there are really more for collections I'd say than for String, but whenever you see static util classes popping up on the same class for different reasons it's clear that isomething is broken in OO land.
You can create a wrapper and manually delegate everything, but I think this happens frequently and brainlessly enough that there should be in-built language support for delegating a particular interface to a member of the class. Then just override what, if anything, it makes sense to override.
Anyways, my 2c.
I have a lot of gripes with Java.
BTW: Referring back to the String example, there's another problem. The interfaces don't come anywhere close to covering the members of String. It's not hard to solve this problem... just create the new interface(s) and declare that String implements it/them. By not creating standard covering interfaces you're not only encouraging, you're more or less demanding a lot of concrete instances of String, when what you really mean is something String-like in some way.
You mean like CharSequence?
The Internet is full. Go away.
When I was doing my Masters, I was knocked down from 10/10 to 7/10 on a particular submission, for the sole reason that I had submitted my listing in proportional as opposed to fixed-width fonts. I of course vowed never to get caught out again or give the lecturer in question any other reason to otherwise penalise me.
I suppose I must credit him with making me think about it, which I had never previously done.
"There is nothing nice about Steve Jobs and nothing evil about Bill Gates." - Chuck Peddle
And don't forget about StringBuilder
Do you really need thread-safe access to your buffer?
Every little helps.
"There is nothing nice about Steve Jobs and nothing evil about Bill Gates." - Chuck Peddle
There's a trend toward imagining that any code you write might be the basis of the world's next big framework. Look at Netbeans and particularly Eclipse: apparently they believe that perfection has been achieved as IDEs so they have nothing better to do than turn them into platforms.
They required us once to use 1.1-compatible libraries (in an OSGI company), so that's stuck in my mind, but yes, you're right of course :) .