Every now and then, it's really helpful to be able to generate a new Java class at runtime. Some problems just can't be solved any other way. It's one of those troublesome tasks: it's fairly tricky to do, and you only need to do it occasionally—but when you need it, you really need it (and usually you need it yesterday). So you have to start essentially from scratch, learning about how to do it on the fly, under pressure.

This talk is designed to help. You may not face this problem for a while, so there's no point focusing on the arcane details that you'll soon forget. Instead, I'll give you what you'll need to quickly come back up to speed when the time comes. You will see some real bytecode generation, but more importantly we'll discuss the types of problems where runtime code generation can save the day, the variety of tools and techniques that are available, and a step-by-step approach to getting the job done. Finally, for those who may be working with more dynamic languages, I'll show how powerful runtime code generation can be when it's easy. We'll start simply, but before we're done we'll be pretty deep into the bag of tricks. Come along, and be ready for the next time you need more than what's in your JAR file.

Most of the time, Java's automatic memory management works really well—it's one of the things that makes programming in Java a pleasant and productive experience, and it's nice that we don't have to worry about managing memory manually. However, although it's usually nice to ignore memory management, occasionally we have to pay close attention. Sometimes we need to take control of certain aspects of memory management. Sometimes Java programs do exhibit memory leaks, or unacceptably long garbage collection pauses, or very poor overall performance. But because Java's memory management is supposed to be "fully automatic," it can be difficult to find out what's really going on inside the VM.

Java memory management is just like most labor-saving simplifications: it works well most of the time, but for the weird edge cases when it doesn't work quite right, it can be a nightmare. This talk opens the hood, examining the inner workings of Java's memory system, including allocation and garbage collection. We'll look at how to control the memory system and interact with it, what's costly and what's not, how to tune the garbage collector and when to switch to a different GC algorithm, and other topics.

The Java Collections framework is a cornerstone of Java development. It's been a part of J2SE for six years now. Every Java developer knows it—how to create Lists, Maps, and Sets, how to put things into them and take things out, and how to iterate over the contents. But there's a lot more to the collections framework than that -- and very few programmers really know how to exploit the power that's just under the surface.

The basics of the collections classes are so simple that many developers haven't even thought to look for the additional power that's there. And it's not just built-in capabilities, either. The design of the collections framework makes possible several powerful techniques and patterns that can magnify your productivity, as well as helping you build systems that are efficient and scalable.

It may seem strange to give a talk on a framework that every Java programmer already knows. But in every project I've worked on for the past six years, I've seen a lot of code that uses the collections poorly. More often than not, that code was written by skilled programmers with significant Java experience. In this talk, you'll learn how to use the collections well, exploiting their full power—the little-known capabilities, the extensibility features, and powerful patterns such as wrappers, adapters, and decorators. We'll also cover some new features that slipped into Java 1.5, plus a few especially useful third-party collection implementations.