Slashdot Mirror
Java Generics and Collections
andrew cooke writes "Java 6 was recently
released, but many programmers are still exploring the features
introduced in Java 5 — probably the most significant changes in
the language's twelve year history. Amongst those changes (enumerations,
auto-boxing, foreach, varargs) generics was the most far-reaching,
introducing generic programming in a simpler, safer way than C++
templates and, unlike generics in C#, maintaining backwards (and
forwards) compatibility with existing Java code." Read on for the rest of Andrew's review.
Java Generics and Collections
author
Maurice Naftalin, Philip Wadler
pages
273
publisher
O'Reilly Media, Inc.
rating
9/10
reviewer
Andrew Cooke
ISBN
978-0-596-52775-4
summary
Guide to Java generics; also includes interesting discussion of collection classes.
Given the history of Generic Java, Naftalin and Wadler's Java Generics and Collections has a distinguished pedigree. In this review I'll argue that this is a new classic.
If you're a Java programmer you've probably heard of generics, an extension to the type system that was introduced in Java 5. They give you, as a programmer, a way to write code even when you don't know exactly what classes will be used.
The obvious example is collections — the author of a List class has no idea what type of objects will be stored when the code is used.
Before generics, if you wanted to write code that handled unknown classes you had to use make use of inheritance: write the code as if it would get Objects, and then let the caller cast the result as necessary. Since casts happen at runtime any mistakes may cause a runtime error (a ClassCastException).
Generics fix this. They let you write code in which the classes are named (parameters) and the compiler can then check that the use of these class parameters is consistent in your program. So if you have a List of Foo instances you write List<Foo> and the compiler knows that when you read that list you will receive a Foo, not an Object.
I'll get to the book in a moment, but first a little history. If you know any type theory — particularly as used in functional languages like ML and Haskell — then you'll recognize my quick description above as parametric polymorphism. You'll also know that it is incredibly useful, and wonder how Java programmers could ever have managed without it.
Which explains why Philip Wadler, one of the people responsible for Haskell, was part of a team that wrote GJ (Generic Java), one of the experimental Java mutations (others included PolyJ and Pizza) that, back in the day (late 90s) helped explore how parametric polymorphism could be added to Java, and which formed the basis for the generics introduced in Java 5.
So if you want to understand generics, Wadler is your man. Which, in turn, explains why I jumped at the chance to review O'Reilly's Java Generics and Collections, by Maurice Naftalin and Philip Wadler.
This is a moderately slim book (just under 300 pages). It looks like any other O'Reilly work — the animal is an Alligator this time. It's well organized, easy to read, and has a decent index.
There's an odd discrepancy, though: Wadler is the generics Guru; this is going to be `the generics reference'; generics are sexy (in relative terms — we're talking Java here) and collections are not; the title has "Java Generics" in great big letters with "and Collections" in little tiny ones down in a corner. Yet very nearly half this book is dedicated to collections.
Generics is a great, practical read. It starts simply, introducing a range of new features in Java 5, and then builds rapidly.
If you are completely new to generics, you'll want to read slowly. Everything is here, and it's very clear and friendly, but there are not the chapters of simple, repeated examples you might find in a fatter book. Within just 30 pages you meet pretty much all of generics, including wildcards and constraints.
If that makes your head spin, don't worry. Read on. The next hundred or so pages don't introduce any new syntax, but instead discuss a wide range of related issues. The chapters on Comparisons and Bounds and Declarations contain more examples that will help clarify what generics do. And the following chapters on Evolution, Reification, and Reflection will explain exactly why.
So the first seven chapters introduce generics and then justify the implementation — any programmer that takes the time to understand this will have a very solid base in generics.
There are even some interesting ideas on how Java could have evolved differently — section 6.9 Arrays as a Deprecated Type presents a strong case for removing arrays from the language. It's a tribute to the clarity and depth of this book that the reader is able to follow detailed arguments about language design. Fascinating stuff.
The next two chapters, however, were my favorites. Effective Generics and Design Patterns give sensible, practical advice on using generics in your work, including the best explanation of <X extends Foo<X>> I've seen yet (so if you don't know what I am talking about here, read the book).
(A practical word of advice — if at all possible, use Java 6 with generics. Java 5 has a sneaky bug).
The Collections part of the book was more along O'Reilly's `Nutshell' lines: the different chapters explore different collection types in detail. I must admit that at first I skipped this — it looked like API docs re-hashed to extend the size of the book.
Then I felt bad, because I was supposed to be reviewing this book (full disclosure: if you review a book for Slashdot you get to keep it). And you know what? It turned out to be pretty interesting. I've programmed in Java for (too many) years, and I guess I've not been quite as dedicated to tracking how the library has changed as I should have been — I learned a lot.
Again, a wide range of readers are welcome. This is more than a summary of the Javadocs, ranging from thumbnail sketches of trees and hashtables to a discussion of containers intended for multi-threaded programming.
The way I see it now, this part is a bonus: the first half, on generics, makes this book one of the standards; the second half is an extra treat I'm glad I stumbled across (I guess if you're some kind of weird collection-fetishist maybe it's even worth buying the book for).
I've used generics since the first beta release of Java 5 and had experience with parametric polymorphism in functional languages before that (in other words, I can tell my co- from my contra-variance). So I guess I'm heading towards the more expert end of the spectrum and I was worried I'd find the book boring. It wasn't. After claiming to be expert I don't want to spoil things with evidence that I'm actually stupid, but reading this book cleared up a few `misunderstandings' I'd had. I wish I had read it earlier.
If you're new to generics, and you don't mind thinking, I recommend this book. If you're a Java programmer who's a bit confused by <? super Foo> then this is the book for you.
The only people who shouldn't read this are people new to Java. You need to go elsewhere first. This is not a book for complete beginners. This is a great book in the classic — practical, concise and intelligent — O'Reilly mould.
You can purchase Java Generics and Collections from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Given the history of Generic Java, Naftalin and Wadler's Java Generics and Collections has a distinguished pedigree. In this review I'll argue that this is a new classic.
If you're a Java programmer you've probably heard of generics, an extension to the type system that was introduced in Java 5. They give you, as a programmer, a way to write code even when you don't know exactly what classes will be used.
The obvious example is collections — the author of a List class has no idea what type of objects will be stored when the code is used.
Before generics, if you wanted to write code that handled unknown classes you had to use make use of inheritance: write the code as if it would get Objects, and then let the caller cast the result as necessary. Since casts happen at runtime any mistakes may cause a runtime error (a ClassCastException).
Generics fix this. They let you write code in which the classes are named (parameters) and the compiler can then check that the use of these class parameters is consistent in your program. So if you have a List of Foo instances you write List<Foo> and the compiler knows that when you read that list you will receive a Foo, not an Object.
I'll get to the book in a moment, but first a little history. If you know any type theory — particularly as used in functional languages like ML and Haskell — then you'll recognize my quick description above as parametric polymorphism. You'll also know that it is incredibly useful, and wonder how Java programmers could ever have managed without it.
Which explains why Philip Wadler, one of the people responsible for Haskell, was part of a team that wrote GJ (Generic Java), one of the experimental Java mutations (others included PolyJ and Pizza) that, back in the day (late 90s) helped explore how parametric polymorphism could be added to Java, and which formed the basis for the generics introduced in Java 5.
So if you want to understand generics, Wadler is your man. Which, in turn, explains why I jumped at the chance to review O'Reilly's Java Generics and Collections, by Maurice Naftalin and Philip Wadler.
This is a moderately slim book (just under 300 pages). It looks like any other O'Reilly work — the animal is an Alligator this time. It's well organized, easy to read, and has a decent index.
There's an odd discrepancy, though: Wadler is the generics Guru; this is going to be `the generics reference'; generics are sexy (in relative terms — we're talking Java here) and collections are not; the title has "Java Generics" in great big letters with "and Collections" in little tiny ones down in a corner. Yet very nearly half this book is dedicated to collections.
Generics is a great, practical read. It starts simply, introducing a range of new features in Java 5, and then builds rapidly.
If you are completely new to generics, you'll want to read slowly. Everything is here, and it's very clear and friendly, but there are not the chapters of simple, repeated examples you might find in a fatter book. Within just 30 pages you meet pretty much all of generics, including wildcards and constraints.
If that makes your head spin, don't worry. Read on. The next hundred or so pages don't introduce any new syntax, but instead discuss a wide range of related issues. The chapters on Comparisons and Bounds and Declarations contain more examples that will help clarify what generics do. And the following chapters on Evolution, Reification, and Reflection will explain exactly why.
So the first seven chapters introduce generics and then justify the implementation — any programmer that takes the time to understand this will have a very solid base in generics.
There are even some interesting ideas on how Java could have evolved differently — section 6.9 Arrays as a Deprecated Type presents a strong case for removing arrays from the language. It's a tribute to the clarity and depth of this book that the reader is able to follow detailed arguments about language design. Fascinating stuff.
The next two chapters, however, were my favorites. Effective Generics and Design Patterns give sensible, practical advice on using generics in your work, including the best explanation of <X extends Foo<X>> I've seen yet (so if you don't know what I am talking about here, read the book).
(A practical word of advice — if at all possible, use Java 6 with generics. Java 5 has a sneaky bug).
The Collections part of the book was more along O'Reilly's `Nutshell' lines: the different chapters explore different collection types in detail. I must admit that at first I skipped this — it looked like API docs re-hashed to extend the size of the book.
Then I felt bad, because I was supposed to be reviewing this book (full disclosure: if you review a book for Slashdot you get to keep it). And you know what? It turned out to be pretty interesting. I've programmed in Java for (too many) years, and I guess I've not been quite as dedicated to tracking how the library has changed as I should have been — I learned a lot.
Again, a wide range of readers are welcome. This is more than a summary of the Javadocs, ranging from thumbnail sketches of trees and hashtables to a discussion of containers intended for multi-threaded programming.
The way I see it now, this part is a bonus: the first half, on generics, makes this book one of the standards; the second half is an extra treat I'm glad I stumbled across (I guess if you're some kind of weird collection-fetishist maybe it's even worth buying the book for).
I've used generics since the first beta release of Java 5 and had experience with parametric polymorphism in functional languages before that (in other words, I can tell my co- from my contra-variance). So I guess I'm heading towards the more expert end of the spectrum and I was worried I'd find the book boring. It wasn't. After claiming to be expert I don't want to spoil things with evidence that I'm actually stupid, but reading this book cleared up a few `misunderstandings' I'd had. I wish I had read it earlier.
If you're new to generics, and you don't mind thinking, I recommend this book. If you're a Java programmer who's a bit confused by <? super Foo> then this is the book for you.
The only people who shouldn't read this are people new to Java. You need to go elsewhere first. This is not a book for complete beginners. This is a great book in the classic — practical, concise and intelligent — O'Reilly mould.
You can purchase Java Generics and Collections from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I was really hoping they'd make another leap up to Java 60.
A big call out to the guys at Vagina Tech! Fo'Shizzle!
"Why did they cancel my favorite Sci-Fi show? I downloaded ALL the episodes!"
unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code.
Who ever saw a version of a Microsoft product that was compatible with the previous version?
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
One thing that I found in Java5 was that it lacked generics for several cases, e.g. Awt/Swing objects that were able to contain Object themselves. Not that it was a big problem, but it wouldn't have been bad to have that support there too...
Anyway - Generics is one of the best features of added to Java lately. It really helps. How I miss it when I'm programming for J2ME...
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
... was a quick and dirty intro to Java generics. I've had trouble finding that on Sun's site (especially ones with good code examples), but Google returns some good results. Given the availability of free tutorials, I probably wouldn't buy the book just for that.
That said, this sounds like a good resource on Java Collections in general (though Sun's javadocs are pretty nice themselves), as well as the other features introduced in Java 5. There also seems to be some discussion of more complex generic structures.
I'm still a bit lukewarm about buying it, but if I were getting back into a lot of Java stuff, I probably would.
(IANAL)
Java generics are not real generics, then you parametrize a generic class in Java you don't really create a new type. You just attach some information for Java compiler so it can perform automatic casting and save you some typing.
Java generics don't provide real type safety, for example, you can easily put Strings in List (that's why Collections.checkedCollection kludge was added).
In C# (or C++), on the other hand, parameterizing a generic type creates a _new_ _type_ which guarantees type safety and allows some quite interesting tricks. For example, in C# generics can be parametrized by primitive types and structs (which don't exist in Java, anyway) so you can have List without overhead of boxing. That's impossible in Java.
Whichever one of you resentful videogame addicted loners shot up the Virginia Tech campus a little while ago, that was a real dick move you guys. Just stop it.
Amongst those changes (enumerations, auto-boxing, foreach, varargs) generics was the most far-reaching, introducing generic programming in a simpler, safer way than C++ templates and, unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code.
Yeah, and by maintaining that backwards compatibility, they became totally worthless.
The only thing it offers is some compile-time sanity checking, but even that can be disabled through use of a new compiler pragma directive to suppress warnings. In fact, in several cases, you HAVE to disable warnings because certain operations (like creating an array of a generic type) are impossible without a warning.
Ever wondered why the collection classes require you to pass in an array to the toArray(T[]) method? Because Java generics throw away the class information after compile time (although there's no reason they need to do this, they could have kept it and maintained backwards compatibility), so you have to pass in an array to give the type information Java removed.
Java generics could have been useful, but since casting them into a non-generic type generates an ignorable warning, they become worthless. It's only a few lines of code to place a Double into an Integer collection, thereby removing then entire point completely.
To do flexible programming and to remove excessive code duplication you generally need some form of "meta programming" where programs can create, see into, or alter themselves to some extent. However, if you do this on a larger scale, you basically are creating a roll-your-own database. Thus, I think that one should perhaps look at better integration with and/or hooking a database to the app language. For example, storing function names in tables rather than using case statements or polymorphism. That way you don't need explicit in-app lists that have to mirror table rows. Java developers seem to be afraid of the database rather than embracing it. I think Java books overemphasize DB vender swappability. It is just not that important in most shops (yes, there are excpetions) and creates duplicate "mirror" structures that bloat up code and make busy work. I think relational databases are potentially better tools to manage and study complex collections/structures than in-app structures. (I say potentially because existing RDBMS are not fully designed for such a task.) In short, the real answer is to merge with and embrace DB technology, blurring the distinction between database and app. It may also make for more flexible code management than hierarchical file systems anyhow. Hierarchies have reached their limit in my opinion. We need queries and set theory to move to the next level in my opinion. Code is growing too unruly for hierarchies and static structures to handle.
Table-ized A.I.
Since he's dead, too.
I don't use any of the generic syntax at all in my code as I feel it makes it virtually unreadable to other developers. The syntax is just absolutely horrible, plus as most adept Java programmers know (been coding in Java myself since 1.0), the way generics is implemented in Java is broken (depending on your point of view on this matter).
.NET, but nevertheless the learning curve is still huge. With Java, the same thing is happening. What was once a simple, yet powerful programming language has evolved into a monster on par with the same kind of crap that comes out of Redmond that is overengineered and the last thing from elegant.
Then there is the Collections API itself which upon first glance seems like it was written by amateurs who have never had to write any performance critical code in their lives. For this reason as well, I generally try and avoid using anything in java.util as well.
And now they are talking about adding closures (more bloat) to Java which as I understand the proposal will be implemented under the hood in basically the same way as inner classes (another feature that is a maintenance nightmare that gets abused by novice developers ad infinitum).
Is Java not bloated enough? Do the guys at SUN have such feature envy of C# (the bastard child of Java), that they can't just say enough is enough?
I feel like this is all coming full circle with C++ in the sense that Java now has so many language features that it is becoming too complicated for entry-level developers to be truly productive with and now a new language is needed that has the best features of Java, minus all the bloat that totally overwhelms the initiates.
With more features, generally comes more power, but with more power there is more room for abuse for those who don't have the wisdom to use it (i.e. newbies). Everyone in programming starts off as a newbie and needs to get their feet wet, but once you make a programming language where everyone has a light saber, but does not have the Jedi training or wisdom to use it, well then you are going to have a lot of people causing a whole lot of trouble.
One of the main reasons why Windows software development has slowed to a crawl (besides of course the cannibalizing nature of MS on the Windows platform), is that it takes a good 4 years or more of full-time experience with the Windows API's just to become adept at programming on that platform, on top of being decent at C/C++ itself. I know Microsoft has tried to reduce that learning curve with C# and
I guess it is time for a new application programming language.
The original post is being just a little specious on generics -- the reason Java generics are backwards compatible is that they aren't generics, they're just automatic type conversions when accessing collections. Whee. C# generics may not be up to the level of true generic programming (e.g. C++) but they are at least 'templates' in the sense that ArrayList is a different type from ArrayList.
Java has come a long way but there's still a reason Java programmers cost about 60% of the cost of actual C++ programmers (curse them).
Whence? Hence. Whither? Thither.
There was a time when I actually was hoping to move from Java 1 to 1.1 and then later from 1.1 to 1.2 The move from 1.2 to 1.4 was still a good thing. However after trying Java 5 and 6 I refuse to move away from 1.4 I do not feel the need to move from something that works to something that pretends that it does more than it really does and introduced an entire set of problems on the way. As far as I am concerned the language is already bloated. I would love to see Java drop inheritance off entirely (and I have used it correctly too,) but there is no need for it really. Everything can be done with interfaces and libraries. From what I see the game is not really concerned with 'correct' implementations of pure coding paradigms, but it is rather concerned with good easily maintainable solutions where the mix of developers mostly consists of below average coders. Oh, and bringing varargs into a language? Talk about shooting yourself in the foot.
You can't handle the truth.
If you wish Xcode would reformat your code for consistency, GTFO.
If you're overwhelmed by IB's multi-paletted interface, GTFO.
If you've ever typed a backslash outside of ASCII art, GTFO.
If you can't intuit your way from HyperTalk to AppleScript, GTFO.
Bandwagon-jumpers are not welcome among real Mac geeks. Keep your filthy PC fingers to yourself.
Java generics are kept back-compatible with the old VM spec by way of type erasure: parametric information is "erased" from the type when it is compiled. So List and List and List all compile down to the same type: List.
Among other hiccups this makes it impossible to overload methods whose argument types differ only in the parametric information included with them.
By contrast, C++ templates and C# generics create a type disjoint from all other types in the same type class for each set of parameters in the type declaration.
Yet another sterling example of Java lossage.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Wouldn't someone have to be used to _only_ Java to not be familiar with at least some of these concepts?
Enumerations are available in Pascal and pretty much all of its descendants IIRC. It's also a type of field in an SQL database for much the same purpose as enumerations in programming languages.
The foreach loop has been in Perl since 2.0 in 1988. C# got foreach in 2000. It's in PHP. It comes from earlier FOR..IN loops from shells.
I'm sure there are examples of the other features which are similar to the Java version of them. The syntax may be different, and the exact details of darker semantic corners may be different. The concepts, however, are pretty easy to have run across unless someone has only used the one language.
The review seems to imply that bringing in what has been proven to work well in other languages is too confusing and should be done at a slower pace. The truth is, people program in a subset of any general-purpose language at first, and that subset grows over time. If someone works with code from other programmers, one picks up the parts of the language to which they are exposed as they are exposed to them. No one needs to cram all night to be up on all the new features of a language the day after the manual gets updated.
Sentence in the above post should have read as follows:
So List<String> and List<java.math.BigInteger> and List<javax.swing.JComponent> all compile down to the same type: List.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
*prepares to be modded troll*
People need to stop comparing Java/C# generics to C++ templates - they take similar syntax, but they aren't the same thing. I'm not sure how one can even be safer than the other.
And C# 2.0 maintained compatibility with existing C# 1.0 code (you still have access to the old containers) while actually giving significant performance benefits where Java is only syntax sugar that still produces the same old slow code.
That's clever, yes. I suppose there has to be one of these in every "discussion". Thanks for increasing the signal-to-noise ratio and all that.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Naftalin and Wadler are also holding a Java One session this year, it is on Wednesday, session id is TS-2890. If you have a Sun Developer Connection account (free) you can watch it online after the conference is over.
I agree with reviewer, the book is very good. It is true that Java generics is a compile time check, and that the generics information is removed (erasure). Nevertheless, that was a deliberate tradeoff for backwards compatibility, and it still makes coding complex Java a lot safer and easier. Look for instance at the 1.5 and 1.6 improvements to the concurrency libraries with Future, Callable and Executors.
Being bitter is drinking poison and hoping someone else will die
OK, this finally is a comment about the book itself, and not about its subject. In my practice, it is almost impossible to get people to understand that generics do not mean "a List of Objects now becomes a List of objects of certain type". Once a person latches onto this notion (that parameterization is simply a way of indicating something similar to a collection), he is almost impossible to shift from it - I've tried explaining the declaration of the base Enum (which is Enum<E extends Enum<E>> - to get the compareTo () to work in a type-safe manner) to seasoned Java developers, only to get (without exception, or even a Throwable): "Oh, I get it, that means that Enum contains other Enum-like things!". And yet the book dives right into this concept; the first glimpse of the actual meaning of parameterization does not appear until the section 2 of chapter 3, a good one third way through. If I were to do it the right way, I'd start with <T extends Comparable<T>>, explain it thoroughly, and only then allow Collection to enter the picture. So, I would disagree with the reviewer - if you want to understand ? super Foo, this is not the book, unless you are willing to skip the first 2 chapters.
I can assure you, the best way to get rid of dragons is to have one of your own.
While Java generics may be simpler and easier to use than C++ templates, they fall far short of the feature set of C++ templates. They do not really provide "generic programming" in the same sense that C++ templates do. There is much more to generic programming than being able to have a HashMap.
Which explains why Philip Wadler, one of the people responsible for Haskell, was part of a team that wrote GJ (Generic Java), one of the experimental Java mutations (others included PolyJ and Pizza) that, back in the day (late 90s) helped explore how parametric polymorphism could be added to Java, and which formed the basis for the generics introduced in Java 5.
So if you want to understand generics, Wadler is your man.
I think that this a very twisted and silly conclusion. Just because someone wrote or developed something doesn't automaticly imply that he or she is the best person when it comes to explaining everything about it. Quite frankly I think its much more of the opposite. Developers are by definition not the best people to turn to when you wish to really learn whatever they developed. While a developer would try to approach his ideas from a technical point of view most students would be more helped when you begin slow and abstract and eventually work your way up.
Naturally I'm a bit cynical here but heck. To me this has once again nothing to do with an intersting article but simply yet another post to try and push some "interesting" book forward thus hoping that someone is going to make more money out of it.
My opinion in all this is simple. If you're interested in Generics then the best place to start learning is the Sun Java tutorial. In this case the trail about Generics would sound like a good idea to start reading.
And you know whats so good about this tutorial? Its free, its from the company which developed Java (a company which doesn't only have very good developers when it comes to Java but also has people available who are quite skilled on documenting) and you can even download it so that you can read and study even if you don't have a permanent connection to the Internet.
Isn't all static type checking some kind of compile-time hack? I think you're completely misinformed about 'generics' in C++, as they are more like macros than anything else. C++ templates are nothing like a real type system which can be found in Haskell amongst others...
The interactive way to Go -- http://www.playgo.to/iwtg/en/
Sun did jump from 1.4 and 5.0 in the past. Java naming and versioning is a sad story.
The most far reaching changes to Java in Java 5 are the changes to improve support for concurrency. Generics are just syntactic sugar that improve compile time type checking. The concurrency support features offer fundamental improvements in the way you can structure your applications to take advantage of increasingly parallel hardware architectures.
This is a great construct, but I found that it can be quite inefficent because it creates an Iterator and uses that to traverse whatever is being passed. For some collections such as ArrayLists, I found using a good old loop and .get(index) performed much faster and avoided creation of Iterators and therefore needed less garbage collection. Foreach is very neat and great in lots of places, but it should come with a small health warning for the cases where performance is critical.
My application was very heavy on traversing ArrayLists though.
-- Mike
nuff said.
I'm less than two weeks away from taking the Java 5 certification exam, and Generics are definitely the most difficult new concept for me to get my head wrapped around. Granted I haven't studied it nearly enough yet and haven't done any large scale projects in 1.5 (we use 1.4.2 at work), so hopefully I'll be well prepared by the time next Friday rolls around. I use the Sierra, Bates SCJP book to study and it supposedly has everything I need to know about Generics for the exam, but is it everything I need to know for the "real world"? Maybe I'll check this book out, but after the exam. Don't want to get confused with real applications of generics. :)
Reviewing just the first hour of video games.
Java generics are mildly useful. To even mention them in the same breath as C++ templates, however, is extremely misleading. C++ templates go far beyond simply providing type-safe collections.
<soapbox>Of course, both mechanisms are work-arounds for the defects in the strongly-typed language paradigm. For the right way to handle types, look at python. Python uses untyped references to refer to typed objects, and written code is far simpler.</soapbox>
If you see the error at compile time, then it's not sneaky. Feel free to use generics with Java 5. Just be sure that your work compiles ...
Take it easy? I'll take it anyway I can get it . . .
I have not done any Java in years. I wonder how this compares to duck typing as in Ruby. Can anyone explain this in terms of Ruby's duck typing and collections?
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
a Duck Tape ribbon.
Any features included to the language, after the first release, would hardly be called as features. They just are fixes for incomplete first release. Either language designers were not aware of these already existing features (obviously, this can not be true), or, they chose not to include those features to the language.
unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code
As a consequence of Java's attempts to maintain backwards compatibility, Java generics are nearly useless. They fail to make your code statically type-safe, and they fail to make it run faster. Yet, despite failing to achieve the two primary purposes that generics have, they still make the language considerably more complex. In contrast, using generics in C# does give you extra type safety and extra performance compared to casting.
C# does not produce the generic versions of code until in the last moment...bytecode translation allows that. Assemblies contain the generic version of the code, so there is no bloat, and the code runs with maximum efficiency (in the context of C#) when translated to native code.
There is an old saying that says "a programming language is not mature unless it as reached operating system status". That's what has happened to Java, which is on par with C++ in complexity.
I do not fully agree though that powerful APIs need to be complex. There are two examples that contradict this: the Qt library (very simple, yet the most powerful C++ library) and the Be Toolkit, which was very powerful as well and completely written in C++.
There was a time where the IT industry kept buzzing about how wrong C/C++'s warnings are, and how they can introduce subtle bugs etc. Now that Java has warnings, are they good?
Interestingly laziness often makes Haskell code less efficent because of laziness. (TCO can end up forcing evaluation which isn't needed.)
In strict languages it's basically mandatory if you want to support functional programming styles (CSP, recursion instead of looping, etc.).
HAND.
HAND.
Please, name ONE other operating system out there that can claim to run decade-old binaries flawlessly in its most recent incarnation.
IBM's mainframe OS runs code from the '60's, methinks.
No really exciting differences, but the text without Slashdot's edits (which removed links, sub-headings and a paragraph that explained what I was doing) can be found here.
http://www.acooke.org