I found the first edition of this book to be very helpful in becoming proficient in the Java language and standard libraries.
It covers all of the important concepts, really in as much detail as I believe one might want short of looking at the API documentation itself, including many particularities of each that aren't quite so intuitive: types, objects, classes, interfaces, io, threads, collections, reflection, beans, Swing, and more.
Looking at the O'Reilly website, I see that the second edition of the book also includes discussions of regular expressions and NIO, the new higher performance I/O system.
I won't be purchasing the second edition of the book, but if you are new to Java, I believe I can recommend it.
You get an overview of the entire language and the important standard libraries. It provides enough detail that it can often serve as a reference until you feel comfortable using the Java whitepapers and API specifications as your primary reference.
700 pages.
If you don't have a lot of experience with really taking advantage of object orientated concepts and design, and you find yourself using Java more than C/C++, I also recommend Oreilly's, "Java Design Patterns: A Tutorial". It puts much of the content of the original Design Patterns book into a Java context, and gives you numerous detailed and concrete examples of employing these patterns in Java and especially in standard Java scenarios. It provides suggestions for how to tell if you should use a particular pattern, as well as the advantages and disadvantages of each.
I'm certain that reading it will help you produce Java code that is more elegant and more maintainable. It will also help you be more conversant in object orientated design concepts.
And oh yes: avoid implementation inheritance unless you have a very good reason to use it; saving lines of code is not generally such a reason =)
Yes, but don't think for a minute that RIM is any less litigous or abusive of the patent and copyright systems than NTP; check out some of the links in the article.
However, I agree that this should not have been awarded a patent.
Given that we transmit data over wire, given that ability to transfer wirelessly what we previously transmitted over wire, given that email is data, and given that computer devices can be made small enough to fit in your hand, this is absolutely obvious.
Given all of these things, which NTP had nothing to do with the creation, development, or advanvement of, this extension is so blatantly obvious that it makes me sick.
Slashdot readers should understand that RIM is in no way less guilty of abusing the patent and copyright systems than is NTP. As seen in a link from the article, RIM has pursued similar measures against Good Technology, who, so far as I can tell, appear to be writing software for RIM's platforms which allows users to use the devices with Good Technology's competing services.
However, that doesn't mean that RIM, if they ultimately lose the appeal, will get what they deserve. Patenting a system of using wireless radio to transmit and receive email from a handheld device is a blatant abuse of the patent system.
Yes, perhaps 15-20 years ago it may not have been obvious.
However, given the introduction of small scale radio transmitters/receivers (er, which isn't exactly new), and powerful small scale electronics, it is absolutely obvious.
This is analogous to being awarded a patent for "a car which uses a 'gravity shield' to hover and propel itself along several feet above the surface", and then at some point in the future when a large scale and low power 'gravity shield' is invented (hah!), trying to enforce that patent.
A wireless network of handheld devices for email is an absolutely obvious application of existing technology. It was not even an "adaptation" of existing technology. It was just a matter of doing the obvious: 1) we transmit data which is email, 2) we wirelessly transmit data, 3) we have powerful electronic devices that can fit in the palm of one's hand, and it is obvious that 4) we can wirelessly transmit email to handheld devices.
5) be awarded patent on obvious combination of existing technology but fail to develop or implement it yourself 6) ??? 7) Profit!
While I don't want to take anything away from the Gentoo project, as it obviously satisfies a need or interest in the community, but I am sick and tired of the untrue stereotype being propogated that Debian is not recent.
If you bother to read the documentation, just barely, even the simplest overviews on the Debian website, you would know that you can also use Debian testing and unstable; you are not limited to stable.
(Yes, sometimes it is appropriate to limit yourself to stable, and when you do, what you get is a system that is very stable, and very closely scrutinized for bugs; look at Debian's own bug-tracking system even).
I am running: GNOME 2.2, Firebird 0.6 / Mozilla 1.4 / Epiphany 0.8, Nautilus 2.2.4, GIMP 1.3.17, OpenOffice.org 1.1, Abiword 1.99.2, Evolution 1.4.3, Gnumeric 1.1.19, XFree86 4.2.1, etc.
No this isn't "cutting edge" if you consider cutting edge to be following development branches and cvs snapshots. Of course not, but I don't want that.
Within reason, it is very recent, and it is stable; as stable as the upstream source, which is all that you can expect from any distribution.
My base system is almost entirely out of Debian stable. The rest of the system is out of testing/unstable only as required to satisfy the dependency versions for these applications.
I have never had the state of my installed packages corrupted by using testing/stable.
There is probably a better way, but this is enough for me (please post if you have an even easier way, as I'd love to know):
"apt-get update" to update the package information from the repositoriees.
"apt-get -u upgrade" "n" to see the packages available for upgrade from all repositories.
"apt-get -u install x" to upgrade package "x".
I could just answer yes to "apt-get -u upgrade", yes, and I recommend others to do this if they don't want to be bothered further, but I prefer to make the decision each time when I want to keep a package from stable instead of testing or unstable.
Look at the applications that are currently offically included in the GNOME desktop. Whether or not applications get included is specifically dependent upon whether or not they are compliant with the GNOME interface guidelines.
What we really need is for Nautilus to be more mature, and for there to be more GNOME 2 media applications which are compliant with the guidelines.
I know that many Slashdot readers scoff at what is being done in GNOME 2, but I am convinced that this is the path to a more usable UNIX desktop.
The simplicity is beautiful.
This is coming from someone who's primary use of X up until just a few months ago was 1) to have multiple xterms on the screen at once and at higher resolutions, and 2) to run Mozilla (Firebird).
The reason that I've switched to GNOME 2 on my laptop, is so that I can be a better prepared and better informed advocate for the UNIX desktop.
When people see what I am running, I do not want them to say, "Wow, that is incredibly esoteric, and looks totaly technical."
Instead, I want them to say, "That looks really great, it really looks like something I would enjoy using, and could pick up real quick."
To be clear, it does not follow from the observation, even if true, that we can not "measure" an object's exact position, that it has no well-defined position.
"An item is in motion if it is changing position -- but if you can measure it's exact position, then it isn't changing position."
The Arrow pardox suggests we conclude from the observation that at an instant of time an arrow "in motion" appears to be no different than a stationary arrow, that there is no difference between an arrow "in motion" and a stationary arrow.
This conclusion does not follow. The conclusion may be true, but it does not follow from this observation alone. Further, there seems to be no reason that at some instant, without context, we should expect there to appear to be a difference between an arrow in motion and a stationary arrow.
Select "Help:Help Contents". There are very helpful tutorials with lots of screen captures demonstrating its basic workings. Then you can move onto the "Tasks" section.
At least for Java development I found the online help to be quite sufficient.
You definitely want to go through the tutorials though instead of first trying to import a large existing project.
CVS support is great too.
Slashdot Mirror
I found the first edition of this book to be very helpful in becoming proficient in the Java language and standard libraries.
It covers all of the important concepts, really in as much detail as I believe one might want short of looking at the API documentation itself, including many particularities of each that aren't quite so intuitive: types, objects, classes, interfaces, io, threads, collections, reflection, beans, Swing, and more.
Looking at the O'Reilly website, I see that the second edition of the book also includes discussions of regular expressions and NIO, the new higher performance I/O system.
I won't be purchasing the second edition of the book, but if you are new to Java, I believe I can recommend it.
You get an overview of the entire language and the important standard libraries. It provides enough detail that it can often serve as a reference until you feel comfortable using the Java whitepapers and API specifications as your primary reference.
700 pages.
If you don't have a lot of experience with really taking advantage of object orientated concepts and design, and you find yourself using Java more than C/C++, I also recommend Oreilly's, "Java Design Patterns: A Tutorial". It puts much of the content of the original Design Patterns book into a Java context, and gives you numerous detailed and concrete examples of employing these patterns in Java and especially in standard Java scenarios. It provides suggestions for how to tell if you should use a particular pattern, as well as the advantages and disadvantages of each.
I'm certain that reading it will help you produce Java code that is more elegant and more maintainable. It will also help you be more conversant in object orientated design concepts.
And oh yes: avoid implementation inheritance unless you have a very good reason to use it; saving lines of code is not generally such a reason =)
Yes, but don't think for a minute that RIM is any less litigous or abusive of the patent and copyright systems than NTP; check out some of the links in the article.
However, I agree that this should not have been awarded a patent.
Given that we transmit data over wire, given that ability to transfer wirelessly what we previously transmitted over wire, given that email is data, and given that computer devices can be made small enough to fit in your hand, this is absolutely obvious.
Given all of these things, which NTP had nothing to do with the creation, development, or advanvement of, this extension is so blatantly obvious that it makes me sick.
Slashdot readers should understand that RIM is in no way less guilty of abusing the patent and copyright systems than is NTP. As seen in a link from the article, RIM has pursued similar measures against Good Technology, who, so far as I can tell, appear to be writing software for RIM's platforms which allows users to use the devices with Good Technology's competing services.
However, that doesn't mean that RIM, if they ultimately lose the appeal, will get what they deserve. Patenting a system of using wireless radio to transmit and receive email from a handheld device is a blatant abuse of the patent system.
Yes, perhaps 15-20 years ago it may not have been obvious.
However, given the introduction of small scale radio transmitters/receivers (er, which isn't exactly new), and powerful small scale electronics, it is absolutely obvious.
This is analogous to being awarded a patent for "a car which uses a 'gravity shield' to hover and propel itself along several feet above the surface", and then at some point in the future when a large scale and low power 'gravity shield' is invented (hah!), trying to enforce that patent.
A wireless network of handheld devices for email is an absolutely obvious application of existing technology. It was not even an "adaptation" of existing technology. It was just a matter of doing the obvious: 1) we transmit data which is email, 2) we wirelessly transmit data, 3) we have powerful electronic devices that can fit in the palm of one's hand, and it is obvious that 4) we can wirelessly transmit email to handheld devices.
5) be awarded patent on obvious combination of existing technology but fail to develop or implement it yourself
6) ???
7) Profit!
While I don't want to take anything away from the Gentoo project, as it obviously satisfies a need or interest in the community, but I am sick and tired of the untrue stereotype being propogated that Debian is not recent.
If you bother to read the documentation, just barely, even the simplest overviews on the Debian website, you would know that you can also use Debian testing and unstable; you are not limited to stable.
(Yes, sometimes it is appropriate to limit yourself to stable, and when you do, what you get is a system that is very stable, and very closely scrutinized for bugs; look at Debian's own bug-tracking system even).
I am running: GNOME 2.2, Firebird 0.6 / Mozilla 1.4 / Epiphany 0.8, Nautilus 2.2.4, GIMP 1.3.17, OpenOffice.org 1.1, Abiword 1.99.2, Evolution 1.4.3, Gnumeric 1.1.19, XFree86 4.2.1, etc.
No this isn't "cutting edge" if you consider cutting edge to be following development branches and cvs snapshots. Of course not, but I don't want that.
Within reason, it is very recent, and it is stable; as stable as the upstream source, which is all that you can expect from any distribution.
My base system is almost entirely out of Debian stable. The rest of the system is out of testing/unstable only as required to satisfy the dependency versions for these applications.
I have never had the state of my installed packages corrupted by using testing/stable.
There is probably a better way, but this is enough for me (please post if you have an even easier way, as I'd love to know):
"apt-get update" to update the package information from the repositoriees.
"apt-get -u upgrade"
"n" to see the packages available for upgrade from all repositories.
"apt-get -u install x" to upgrade package "x".
I could just answer yes to "apt-get -u upgrade", yes, and I recommend others to do this if they don't want to be bothered further, but I prefer to make the decision each time when I want to keep a package from stable instead of testing or unstable.
Look at the applications that are currently offically included in the GNOME desktop. Whether or not applications get included is specifically dependent upon whether or not they are compliant with the GNOME interface guidelines.
What we really need is for Nautilus to be more mature, and for there to be more GNOME 2 media applications which are compliant with the guidelines.
I know that many Slashdot readers scoff at what is being done in GNOME 2, but I am convinced that this is the path to a more usable UNIX desktop.
The simplicity is beautiful.
This is coming from someone who's primary use of X up until just a few months ago was 1) to have multiple xterms on the screen at once and at higher resolutions, and 2) to run Mozilla (Firebird).
The reason that I've switched to GNOME 2 on my laptop, is so that I can be a better prepared and better informed advocate for the UNIX desktop.
When people see what I am running, I do not want them to say, "Wow, that is incredibly esoteric, and looks totaly technical."
Instead, I want them to say, "That looks really great, it really looks like something I would enjoy using, and could pick up real quick."
Be an advocate.
To be clear, it does not follow from the observation, even if true, that we can not "measure" an object's exact position, that it has no well-defined position. "An item is in motion if it is changing position -- but if you can measure it's exact position, then it isn't changing position." The Arrow pardox suggests we conclude from the observation that at an instant of time an arrow "in motion" appears to be no different than a stationary arrow, that there is no difference between an arrow "in motion" and a stationary arrow. This conclusion does not follow. The conclusion may be true, but it does not follow from this observation alone. Further, there seems to be no reason that at some instant, without context, we should expect there to appear to be a difference between an arrow in motion and a stationary arrow.
Select "Help:Help Contents". There are very helpful tutorials with lots of screen captures demonstrating its basic workings. Then you can move onto the "Tasks" section. At least for Java development I found the online help to be quite sufficient. You definitely want to go through the tutorials though instead of first trying to import a large existing project. CVS support is great too.