The availability of components that do a myriad of tasks could lead programmer complacency
Look around. There are many software development components. Do you need to write a program that displays HTML? There is an HTML-displaying component. Do you need to write a program that plays a MIDI file? There is a MIDI-file-playing component. Do you need to write a program that uses a stack, queue or other classic data structure? There are data structure components. Indeed, many of the programming challenges that used to take hours, or days or weeks to write are now available as components.
It is certainly true that components have some very good properties. Software developers can save substantial amounts of time by using previously-written components. Also, as Joshua Bloch pointed out in "Effective Java," these components probably consist of high quality code written by professionals .
On the other hand, components might come with an undesireable side-effect. The availability of components that can do such a myriad of typical tasks could lead us programmers to a place of complacency where we do not know how the code in the components was written.
Perhaps the ability to rewrite component code from the ground up is not something that will be of much importance in day-to-day software engineering. Provided that someone, somewhere, will write components for whatever languages we will be using in the future, then we can continue to use the components. There is something to be said, though, for what programmers learn by way of writing such code for themselves.
In college, I sharpened my programming skills by, more than once, writing code for routine things such as linked lists. I was not doing any groundbreaking data structure research, and probably whatever linked list component came with our programming system would have worked just as well as, if not better than, what I wrote. But I still gained valuable knowledge and experience just by going through the motions of writing this code.
Imagine what we could learn, then, by writing our own HTML format and display code? Or our own MIDI file-playing code? Of course, not every programmer should necessarily attempt to implement every sort of existing component. But, from time to time, if a certain task seems interesting, it could be worth the effort just for the educational benefit. And, perhaps more importantly, by doing so we will not lose track of how all of the parts that we use were built.
If you're mainly interested in getting the job done fast and correctly, then by all means, reach for the components. That's what they are there for. If you have some spare time and want to spend it writing code, then you could consider rewriting a component. You may end up finding a better way of doing things than the writer of the component did. Or, if nothing else, you may simply gain algorithmic insight and become better equipped for future programming tasks. After all, it's good for us to know how we got here, and to be prepared to explore someplace new.
 Bloch, Josuha. Effective Java Programming Language Guide. Published by Addision-Wesley, 2001.