[Zel2008]

Hi everybody,

I just found out that the Sun JDK is now available for Mac (yay!), and it got me thinking, how should Java developers proceed with that knowledge?

Here's the quandry, it seems to me. Most Mac Java development in the last few years has probably been JDK 1.6 compliant, and using the Mac JDK. Since the Mac JDK functions somewhat differently from the Sun JDK, there almost always is some unique Java code specifically for Macs needed to make complicated things work cross-platform.

With the advent of Sun JDK 7 on Mac, all that extra jumping through hoops shouldn't be necessary, and it should be a no-brainer to update code to take advantage of the consistency and easier development ability.

But, here's the problem -- the Mac Sun JDK 7 (which is even available from the Java downloads page like the other normal ones) only works on OS Lion or better. There are still a decent number of Mac users who run Leopard or Snow Leopard, on which JDK 7 won't install. I've tried.

So, what do we do? Do we keep relying on a deprecated Mac JDK with security holes (Apple's own words -- you can Google it) for the sake of keeping more users, or do we update to a secure, consistent JDK and require users to update their OS's?

It's a thorny question, and I don't have a good answer. My instinct on this is to update the code and require OS Lion, but how much of a deadly sin is it to do that with existing software? For example, the software I maintain has been Mac Java 1.6, Mac JDK compliant for almost 4 years.

What other advantages, disadvantages, or arguments am I missing? Is there a clear-cut answer? I'm sure someone else must have run into this train of thought; what does everyone else here think?

Thanks,
Zel2008

This post has been edited by Zel2008: 25 July 2012 - 07:09 AM

[cfoley]

The answer to that isn't going to come from an analysis of the technical data alone. You need to look at it from a higher perspective and ask yourself why you are writing a piece of software and what principles you hold yourself to.

Are you coding for fun, to earn a wage, to sell a product? Is it more important to satisfy your need for the latest features available to you as a coder or is it more important to make a bottom line or maybe provide a service to others?

Which do you consider the worst crime: Excluding users from your product or releasing your product on an insecure platform?

How do you view yourself? Do you like to code on the bleeding edge of technology or are you happy to hold back and take the leap when the rest of the world is ready to come with you?

It may seem like I've simply thrown your questions back at you, and in a sense I have. But if you examine your and your company's values and get to the bottom of why a programming project exists at all, you will be able to make an easy decision on the technology to use for that project.

[Zel2008]

Hi cfoley,

You're absolutely right. My instinct, as almost the only developer (and probably soon the lead), is to make my life easier and upgrade, but I'm not sure the rest of my team would see it that way. And even if I become the lead developer, I won't have final say, either.

My philosophy has always been to simplify things from the developer standpoint, because it makes things easier to maintain. By extension, that makes things easier to add to, change, and upgrade. Other people on my team, though, prefer to make it easier for the user, at the expense of the developer, which gives me headaches.

Also, it drives me crazy having insecure code; warnings make me twitch. Once again, not everybody in my group has that ideology.

I was always taught that making things easy for developers isn't mutually exclusive from making things easy for users, but it seems to be hard to find others with that philosophy. That's the central issue here, I think.

This post has been edited by Zel2008: 25 July 2012 - 08:08 AM

[cfoley]

So it seems that your core values are not the same as all of your colleagues. That's a shame as it is always going to be a source of friction. Does your company have some core values to guide you?

The other side of the coin is the "why". Why are you making the software?

Money? Is your choice going to affect the bottom line?
Satisfaction? What does satisfaction mean to your team?

Why else are you making the software?