I am going to teach a course in object-oriented programming in Java, and am looking for materials - textbooks and slides. It is a course for 2nd-year undergrads. In the 1st year, they already learned an introduction to programming course, also with Java. So, books that just teach Java will not be good textbooks. What are good textbooks for such a course? Additionally, are there existing courses where I can get slides and other course materials, so that I do not have to prepare everything from scratch?
I'm going to jump the gun a bit here and make a suggestion with less than complete information. Assuming that the students have seen a fair amount of Java and its libraries and also assuming that the book they used isn't terrible on OO concepts then I'd suggest that you run a project course. There are a fair number of possibilities for projects
One is to use your own doctoral research interest as stated in your profile and have students build a software system to solve fair cutting problems.
Another possibility is to use an old APCS Case study that was quite well developed and used for a few years in the APCS course in the US: Grid World. The study comes with a starting code base and a student manual.
You might also join the Greenroom and look at the various projects available there. It is also a community of educators who might be able to offer assistance. The Greenroom resources use the greenfoot IDE which is simple but complete, but the advantage in your situation is the various projects that you might be able to develop into a course.
The BlueJ IDE is a bit more sophisticated and the community there also publishes a number of projects via the Blueroom. Many of them might be considered as the basis of a project course.
Of course, another consideration is how well you know Object-Oriented programming yourself, as you don't say. If you are less than an expert, you might consider for yourself to look at something like Polymorphism: As It Is Played by Joseph Bergin. I don't think it would be suitable for a course text, but it might give you some background in OO thinking if you haven't already acquired it.
I also note that in a project course you have the opportunity to introduce students to some of the additional personal practices they will need as they advance, such as teamwork and, perhaps, pair programming and test first development. Moreover, to ease your own workload, a project course could be very flexible, with students starting work on early requirements while you develop later ones. I'm thinking of something like an agile methodology here, of course, with yourself as the students' "customer".
Of course, if you want them to learn OO style and not just build code, then you need to watch over them. There are a few ways you can do this. I'm assuming that your class is reasonably sized (say 20 or less). I'm not sure how to make it work for 80. You can use the class time as design sessions for coding. You can have students work in groups for a while and show you what they come up with. Initially you can suggest designs for sections of the project. The idea is to "nudge" teams in the desired direction, rather than to lecture on the ideal.
I used to teach the Compiler Course in which a goal was also to improve OO thinking. I would review the student's code every two weeks. Student pairs (or teams) would submit printouts in a folder every two weeks. They needed to use a highlight marker to mark the changes from the previous report. It is relatively quick to go through 10 or so folders if marked up. You don't need to note every detail in these, nor do you need to grade them, but just give any needed feedback. For many groups as check mark is enough. But for some, you know you need to provide more guidance.
If teams are larger (say around 5-6) I would do two things. One is that I'd appoint a "captain" who was responsible for keeping me informed (not for team management). I could discuss the periodic report with him/her. Depending on the number of students, you could have a weekly "captain's meeting" as part of class or office hours, perhaps. I also named teams with names they though clever to give them a sense of belonging. "Lions" and "Tigers" might work, or "Earth" and "Sky". I made up the names to avoid possible improper "creativity."