Skip to main content

What Is Hip?

Posted by editor on August 24, 2006 at 6:53 AM PDT

Iterating over successful habits

So how will you have your self-help: seven habits or six pillars? Finding the common traits of success is a popular pursuit -- it's what patterns are all about after all.

In some ways this line of thinking is as old as philosophy itself: what do you believe, and how should you act in accordance with that? If you believe that software should be robust, stable, predictable, easy to understand, and easy to maintain, then you'll soon ask yourself, "OK, how exactly do I do that?" It's not enough to just want to write good software; you have to have a self-awareness of what practices do and don't result in good code.

Robert J. Miller has an answer in today's Feature Article. In fact, he has five answers, which he calls Five Habits of Highly Profitable Software Developers:

Following these five habits will help development teams create software that everyone on the team can read, understand, and modify. When software development teams create new value too quickly and without consideration for the future, they tend to create software with increasingly high implementation costs. Inevitably, bad practices will catch up to these teams when they have to revisit the software for future comprehension and modification. Adding new value to existing software can be very expensive if the software is difficult to comprehend. However, when development teams apply these best practices, they will provide new value at the lowest possible cost to their business team.

One thing you might notice about his list is that rather than being high-level meta-processes, his habits are specific strategies for the use of methods and constructors. That may be why the title doesn't claim that these are the five habits... perhaps there are others. Take a look at Robert's list and see if you agree and if you have some other ideas about strategies for creating consistent, maintainable code.

Topping off the Java Today section, we look a few weeks ahead to the annual Jini gathering.
With the recent wiki-fication of the site, information for the 10th Jini Community Meeting is now collected as a wiki page. Those attending the Sept. 13-14 event in Brussels can use the page to learn more about the event, make plans, view schedules and session descriptions, and add themselves to the list of participants.

Will Java SE 7.0 have closures? In his blog entry Full Disclosure, Peter Ahé writes: " Some clever guys have written up a proposal on closures [PDF, 104KB] and been kind enough to put my name on it. I was just sitting in the room trying my best not to look too stupid." In a follow-up, Non-local return and lexical scope, he notes "i haven't seen any comments from people that understand closures saying they don't like them. So this makes you think if closures is just a matter of understanding them or not." ONJava blogger Dejan Bosanac also considers the proposal in Will we have closures in Java 1.7?

Shai's weblog is picking up links and commentary from around the Javasphere for arguing that Java 5 Language changes were a bad idea. "Don't get me wrong, I use Java 5 -- it is a great platform, but the language changes are a failure according to the criteria I care about and I think you should care about it too. Lets look at the features brought on by Java 5, with the exception of annotations none of them made Java any better and in fact made it more confusing with multiple syntaxes to accomplish the same thing"

Cay Horstmann relates an aggravating experience with NetBeans in today's Weblogs. In
How Not to Report an Internal Error, he writes:
"NetBeans pops up a dialog with an exception message when it finds an internal error. And again. And again. And again. And again. This blog reviews just how user-hostile this behavior is, and suggests alternatives."

Alexander Potochkin has had a remarkable challeng resolving a Swing bug, which he relates in
The ButtonGroup of my dreams:
"I have fixed quite a lot of bugs and RFE's in Swing for Java 1.6 and don't really remember all of them, but I do remember one remarkable bug because it took me unusually long time to find a good solution and after I had fixed it I had to fix several regressions and finally I completely rolled the fix back"

Text Normalization...what's that? As John O'Conner explains,
"Java SE 6 makes the Normalizer API public...but how's it going to help you?"

In today's Forums,
gkulewski isn't as concerned with forking open-source Java as he is with the practice of bundling a specific JRE with end-user apps. The message
Re: Private JREs argues:
"But I really believe Sun and others should do everything to stop people making private JREs. _Not_ in legal ways, but in technical ways. Private JREs cause more problems (increased download size, many different dll problems, stopping portability, silently decreasing security, causing obscurity, ...) that they solve (knowing what JVM will be used - but not exactly what OS and other components). Making one, compatible, autoupgradable, easy to find and install (possibly bundled by default in OS) equiped with good tools (like JWS should be or better) JRE will hopefully make private JREs mania decrease..."

The hot-button issue in the thread
Re: JavaBean API ready for external review is whether beans should implement some specific interface. zixle
"To sum it up, I don't see the point of an interface here. The value of AbstractBean (yes, I'm stuck on that name) is to make it easier to create an Object that provides support for PropertyChangeListeners. The beans spec says reflection is to be used to located the add/remove methods, hence why bother with an interface for the four or so variants... Consumers of AbstractBean that care about PropertyChangeListeners will use reflection and will not know to look for a certain interface. If you want to generate a proxy for your concrete subclasses AbstractBean, you can define an interface with the methods you care about."

In today's
News Headlines

Registered users can submit news items for the href=""> News Page using our
news submission
. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the href=""> News RSS

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

Iterating over successful habits