What's the meaning of “the Sun defect” and how does it differ from the more generic “NIH syndrome”?

Question

I hear people talking about the "Sun defect", often giving the whole mess around logging as an example.

How is it different from the not-invented-here syndrome, which means uselessly duplicating existing work?

Answer 1

I couldn't find what you mean by the term in google.

There is still plenty of code in the JDK which which has not been maintained to best practice. However the major of what you would use will do what you need and there is no good reason to redevelop it.

I have written a number of low level frameworks which do the same thing as what is available in the JDK but a different way to solve a specific problem but I would say they have limited application.

Many developers are motivated money and they tend to find existing solutions to get a job done, but many are strongly motivated by the technical challenge. Sometimes this desire for a technical challenge results in a re-inventing of the wheel. There are companies which develop new and better wheels, but most re-invented solutions is no better in the long run. (true of many products IMHO)

You want to have a balance between re-use and a willingness to produce tactical solutions, as a well a balance been making money and finding a challenge. ;)

Answer 2

The "logging mess" in Java most likely refers to that JDK 1.4 introduced a logging framework that was inspired by the then de-facto logging framework log4j, but not compatible.

There was loud voices that they should just have adopted log4j - which seen in hindsight would have saved a lot of trouble - but JDK 1.4 logging can do things that log4j couldn't at that time. All in all this has resulted in numerous logging frameworks trying to deal with this duality and dealing with the new API's trying to fix the duality. These days the best bet is to write new code against the SLF4J API and then let the deployment people figure out which backend to use.

I do not know why Sun did not pick up log4j, but a qualified guess would be that JDK 1.4 logging is a formalization of an existing logging framework inside Sun, probably coming from their C world. In my personal opinion the JDK 1.4 logging framework was not done by an experienced Java person or some decisions would have been done otherwise. It could also be that log4j was not under a usable license (as other C libraries are being used elsewhere).

Licenses are probably the largest cause of redoing the works of others, simply because their code cannot be used as the licenses are incompatible. If you doubt this, consider asking your boss to use a GPL library in your main product and see what the lawyers say.

Answer 3

Can you please cite a reference to some discussion where "the Sun defect" is used in the way that you are asking about.

I did a Google search and there are remarkably few hits for the phrase "the sun defect", and the only vaguely relevant examples I could see were in relation to some specific Sun Bug Database entry.

---

Afaik it is more about Sun not reusing third-party code for political/internal reasons and writing their own version instead, but introducing some defect the original version didn't have.

Can you please cite some discussion to support this. I've never heard of it, and as others have confirmed, it doesn't show up in Google searches. (Well actually it does now ... but that hardly count!)

If this is all that "the Sun defect" is supposed to mean, then you've already answered your own question.

Note: I'm not saying that it doesn't occur. However it is easy to point the finger and say "NIH syndrome" when the true cause of a misfeature is not actually known or even knowable. And it is easy to pick/ holes in some design in retrospect.

One thing that a lot of people fail to realize is that design mistakes in Java are really hard to fix without damaging what makes Java so attractive to business; i.e. the platform's stability & backwards compatibility. So, when mistakes are made (and they are ... because engineers are only human) they tend to stand out like a sore thumb.