harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From FaeLLe <mrbillcollec...@gmail.com>
Subject Re: Backward compatibility
Date Thu, 12 May 2005 03:11:36 GMT
Compromises will be done that is for sure and yes you do seem to correct 
this will probably be done on those deprecated methods out there and it 
would be a good idea too to circumvent the usage of them while still 
adhering to the requirements.

On 5/12/05, Kev Jackson <kevin.jackson@it.fts-vn.com> wrote:
> >* The complete agreement and compatiblity of the rules set down by TCK 
> was
> >one of the major factors that ensured that we would be 100% Java as it is 
> by
> >Sun
> >
> >
> >
> Yep agreed, if we were going to create a 90% but not deprecated code, we
> couldn't say that it was Java, and what would be the point of that?
> >* As a very learned person who clearly was authority on the subject 
> aldready
> >pointed out some Sun methods do indeed invoke these deprecated methods 
> and
> >when they are deprecated and when not does indeed fluctuate. And if we 
> are
> >making something should we *compromise* on quality of anything that we
> >produce ?
> >
> >
> Yes getting stuff released is a matter of compromise. If you ask Sun
> engineers do they believe that everything in Java5 is perfect? Nope,
> but they released it anyway. Open source is in the fantastic position
> of being able to refactor infinitely and to be able to constantly
> improve code - something commercial software usually doesn't have time
> to do.
> Being pragmatic allows you to get a working version released, being
> idealistic "everything must be designed perfectly before we start
> writing code" only works in Utopia, ie nowhere. I firmly believe that
> the scale of this project will initially require some sort of
> compromises to be made, so long as these are not fundamentally limiting
> (and is an unoptimized implementation of deprecated code limiting?),
> then they can be changed later when there are free developers with time
> on their hands. Also ask yourself as a developer, do you want to spend
> your time working on the boring deprecated parts of the code? It's a
> burden someone will have to do to get the TCK to pass, but I doubt there
> will be many volunteers to code these bits - and the ones who do
> volunteer will be respected for the odiousness of teh task that they
> have volunteered for.
> This isn't to refute your point that we should make a sub-standard
> product, just that parts of the product are more important (deliver more
> business value to customer) and should be concentrated on first. As a
> n00b on this list, I'm aware that most of what I'm writing could be
> regurgitating previously discussed stuff, and I'm also not claiming to
> be a VM engineer or someone with prior GC/JIT development experience,
> just as someone who's seen the "design first"/idealistic model crash and
> burn on too many occasions.
> Kev

www.FaeLLe.com <http://www.FaeLLe.com>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message