On Fri, 2006-08-04 at 13:17 +0900, fchoong@xxxxxxxxxxx wrote: > Hi Sven, > As you say, if we go after too many goals, we may end accomplishing none > of them, or worse complete them half way and leave users scratching their > heads as to what went wrong(this leaves a really bad impression). In general, definetly. > So it is better for us to say, "It maybe slow, but at least it is working and it is > an equivalent to JDK 1.4(or 1.5)". I think that after we achieve > compatibility with ONE version of Java API, we can go after the > optimizations. We can then say, "We have a solid equivalent of JDK 1.4". > This will be enough to gain many peoples attention. I agree. Compatibility goes first. But. There are cases where speed and furthering the implementation's compatibility aren't in conflict. In some cases, (AWT imaging is a good example), we have (or have had) implementations of things which were more or less fundamentally wrong. And where that fundamental problem had caused both issues with speed and with compatibility. The API is such that it's often difficult to do something fundamentally different from how Sun does it and still be fully compatible. And often, these ways of doing things are slower, too. (However, this isn't always the case) > I think we should reach a consensus of SPEC compatibility vs RI > compatibility, then we should write it down on the WIKI and stick to it > until it is complete. That way we can all stay focused. Actually, I'm a bit sceptical of having a policy on compatibility. I think it might be spending time on a non-existant problem. Spec-vs-JDK compatibility sounds like a big issue, and does turn up in cases now and then, but it's only is a big issue if you decide to turn all those cases into a general problem. If you do, you start looking for a big general solution and consensus on it. Which is hard to get for any general idea that's big enough. However, in my experience, when you do run into these issues (and it's actually fairly rare to do so), there usually is a quite broad consensus on what the right thing to do is in that particular case. And that's of course in rare event that someone actually consults the rest. In the vast majority of cases, the developer himself (who's presumably more in-touch with the particulars of the method involved than anyone else anyway) makes a judgement call. And unless it turns out this actually causes a real-world problem, you never hear from it again. I can't really imagine any consensus on the issue that wouldn't really just boil down to "Use common sense.". But if someone needs guidelines, here are at least the points I tend to evaluate myself if I run into something. * Re-read the spec. Are you sure there's no possible way the spec could be interpreted such that it supports this behaviour? (Happens quite a lot. Remember, in general, Sun's API docs tend to be written to fit their implementation and not vice-versa. ) * Does the actual behaviour "accidentally" seem to match the behaviour you'd get with simpler/less code than what the docs say? (Common, especially for Exceptions! A recent example I brought up is BigDecimal.setScale. Which delegates to BigDecimal.divide, (in our impl) and throws the exceptions that method throws. Which changed in 1.5, although Sun forgot to change the javadocs for the former method.) * Is this really a compatibility issue? Is it reasonable that any sanely-coded program could depend on this certain behaviour? (Most discrepancies would fall into this category) * Do other TCK-approved (IBM, Apple) VMs do it this way? (E.g. dependence on com.sun* classes.) * Check Sun's bug page, has someone reported this or something related which can provide additional insight into what the actual intended behaviour is here? (Remember, Sun has bugs, and people may create dependencies on them. If Sun acknowledges it's a bug, then it's not our problem.) * Do other Sun versions do it this way? (Sun has regressions, too.) /Sven
