Scopes are one of the first things we learn as Java developers. Public, private and even protected scopes are easy enough to grok, but package-private scope alludes many Java newbies. I remember confusion when I first read about package-private scope; "Why would I ever need that?" I learn by understanding, not memorization. Missing the necessary context, my brain failed to retain package-private scope the first time through: in one ear, out the other.
Even when developers do have the background necessary to understand package-private scope, I think its inconsistency with the other scopes leads to further confusion. If you want a public method, prefix the method signature with public. For a private method, use the private keyword. Protected, protected. If you want a package-private method... omit the keyword altogether. For example, use String foo() instead of private String foo(). Adding fuel to the fire, Java documentation often interchanges the terms "package-private," "package," and "default." I'm embarrassed to admit I once tried to use package-private as a keyword.
Many programmers don't know (or think) they need package scoping. They try to work around its absence. Some messily expose implementation classes as part of their public API. This clutters the Javadocs and increases the library author's maintenance burden; whether the author likes it or not, they should support clients who depend on these implementation classes. Using package scope prevents clients from creating dependencies on internal implementation classes in the first place.
A few programmers like to put their public API in one package and their private implementation in another. They attempt to hide the "private" package from the client by not publishing its API. From a security viewpoint, exposing your private package to your public package inherently exposes it to everyone else (including the client). This may fly for application code, but you must hold reusable libraries to a higher standard. Java provides no way to say, "make foo public, but only for this one other package." In addition, splitting your public API and implementation into two different packages confines you to class granularity, whereas package scoping enables you to mix public and package-private members in the same class.
Others use protected scope when they should use package scope. My skin crawls when I see Javadocs dusted with protected members (Struts anyone?). This solution suffers the same fate as making your internal implementation classes public. Unlike package scoped members, protected members are still part of the public API; clients can access them, and the fields and methods show up in the Javadocs.
Package scoping particularly shines during unit testing. Some programmers argue that you should only test through the public API. Don't be silly. Limiting your tests to the public API contradicts the spirit of unit testing and subjects you to unnecessary dependency pain. I prefer to isolate and limit the amount of code I test at one time, and test as close to the code as possible.
To expose a class member to a test without impacting the public API, put the test class in the same package as the code it tests. Make the member you wish to expose to the test package-private instead of private (i.e. delete the private keyword from the declaration). I've actually grown accustomed to using package-private scope instead of private by default. Less typing, less clutter. To prevent clients from putting their classes in the same package as yours and accessing your package-private members, Java supports package sealing.
When I first heard rumors of a "headless iMac" a few weeks back, I got very excited. I already have a Mac hooked up to my home theater system, and I would prefer something more consistent with the other components. I doubt very seriously Apple would leave the monitor out just to save money. The thought of a beige 15" PC CRT hooked up to an Apple gives me the willies. Hooking an Apple to a TV is a completely different story. This will be the Mac for your living room. I like the idea of computing from the couch with my Bluetooth mouse and keyboard. This won't just steal away existing Windows users. This has the potential to compel non computer owners. Imagine your grandparents emailing pictures from their big screen TV.
Though the photos of the "iHome Media Centre" on Engadget sure look convincing (JPEG meta data and all), I doubt they're genuine. One, Apple hasn't sued them yet (though you could also interpret this as Apple not wanting to acknowledge the authenticity). Two, all of the ports are on the back. I would hope it would have USB and firewire ports on the front to hook up digital cameras, etc. Three, the spelling of "centre" is a little too cheeky, even for Apple.
I do not foresee this being a PVR. First, a PVR would require more hardware and horsepower for the video encoding whereas a low end G4 is more than enough for playing back video. Second, why would you need to record anything when you can download it all from Apple's new iTunes-like service for video? iClips anyone? As easy as Tivo is to use, browsing and downloading in iTunes is even easier. This setup would also make much better use of hard drive space than a PVR because it doesn't suffer the limitation of encoding video in real time. If Apple partners with TV networks like they have record labels, I'll be able to watch my shows at the same time as those watching them on conventional TV.
Cross your fingers.
Update: The keynote is over. Oh well. The Mac Mini would fit nicely into a home theater system. I'm surprised it doesn't have an s-video output. Steve did say this is the year for HD. I guess I'll be sticking to my PowerBook and bittorrent for the time being. Maybe next year.
Treat yourself this holiday season to a copy of Mike Clark's Pragmatic Project Automation. I love this book. Congratulations to the Pragmatic Programmers for this addition to the series and more importantly to the team. I'm already looking forward to future installments.
Foremost in my mind, the quality of the content to page ratio rocks. I'm tired of publishers stuffing 400 pages of bullshit down my throat. I don't have the time. Save your money. Save a tree. I want quality, not quantity. Mike writes as efficiently as he entertains. This book is airplane, stick it in your laptop bag and go, friendly. My shoulder thanks you, Mike.
Mike packed this book with awesome tips and tricks, some of which guest authors contributed. After reading it, you'll be making lava lamps turn on in response to build failures, your application will file bug reports automatically, and you'll have gained some insight into why Ant works the way that it does (as told by its creator). I personally learned how to create GUI installers automatically from my build file using free software. Cross platform wizard installer, $0. Happier end users, priceless.
I can't say enough good things about this book. Resolve to snuff out application down time this New Year. Put all of those little boxes called "computers" lying around your office to work. Spend more time on quality code (or with your family, whichever floats your boat). Buy a copy for your build guru. Buy one for your manager. I guarantee it will put you at the top of their gift giving lists next year.
I must run IntelliJ IDEA on Linux, but OS X is my OS of choice. After trying various setups involving X Windows, VNC, x2vnc, and Synergy, I've settled on running IDEA from my Linux box under X11 for OS X. In other words, IDEA runs on the Linux box but displays in OS X. For some reason, the Alt key did not work out of the box (which becomes an issue when I try to select a menu or hit "Alt+Enter" to import a class). I fixed the issue by creating .Xmodmap in my home directory on my Mac:
Russell Miles continues his introduction to AOP in Spring with a Cuckoo's Egg Design Pattern example. The CuckoosEgg interceptor routes method invocations to alternative implementations in his ReplacementFeature class. The example Spring AOP configuration takes nearly 60 lines of XML to say, "apply the CuckoosEgg interceptor to IBusinessLogic.foo() and IBusinessLogic2.bar()." Since Russell used the AOP Alliance API, we can reuse his same code with Dynaop and enjoy a considerably simpler BeanShell-based configuration:
I just accepted a job offer from Google. Thanks for the hook up, Cedric.
Many have tried, but Google is the first company to convince me to leave beautiful St. Louis, MO (Go Cards!). I've decided I want to live in San Francisco as opposed to the San Jose area. I have to move in a couple weeks, but I have no idea where I'm going to live. I like lofts. Any advice would be much appreciated.
This won't impact my blogging [in]frequency or work on Dynaop.
Dion is excited by the proliferation of AOP talks at the NFJS symposiums. Cedric remains skeptical about the adoption of AOP.
Many developers have an itch they aren't entirely aware of. Repeated boilerplate code causes it. AOP can scratch it. I survived without OOP for a long time, but now that I'm aware of it, and I understand it, I have no desire to go back. The same happened with AOP to a lesser degree. Whether others choose AOP or some other road, I'm confident the itch will get scratched. It's just a matter of time. Developers who understand AOP will open others' eyes to how they can improve their code, and they will in turn open even more developers' eyes. Pay it forward. I've witnessed this effect in my own company as interest in AOP slowly but surely snowballs.
In regard to alternate roads, annotations (assuming I understand them correctly) have the potential to partially supplant AOP, solving some problems in a less powerful but simpler manner. Take undo logic for example. I can use AOP to pick out undoable methods and apply undo logic to them completely independent of the target code. Or, I can just add @Undoable annotations in the source code of the undoable methods and inject the undo logic at compile time (generating undo command classes, etc.). The annotation-based approach isn't as concise as an AOP-based implementation, but some might argue that it's more maintainable.