You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Doug Hall <do...@gmail.com> on 2005/05/11 18:26:35 UTC
Backward compatibility
Forgive a newbie, but if Harmony passes, would there be an effort to
write the deprecated code? Personally, I would hope not - at least not
initially. But wouldn't it need to include them to pass compatibility
tests (TCK), or do these tests only test the current API?
Doug
Re: Backward compatibility
Posted by Rodrigo Kumpera <ku...@gmail.com>.
If it´s not 100% API equivalent, then it cannot be called Java. The
announcement says that Harmony is about free java.
Rodrigo
On 5/11/05, Doug Hall <do...@gmail.com> wrote:
>
> On May 11, 2005, at 11:45 AM, Stefano Mazzocchi wrote:
>
> > Deprecated or non deprecated, we want Harmony to pass the TCK, so
> > whatever the TCK wants us to do, we'll do it.
>
> So what's the point? If all you're trying to do is duplicate J2SE 5,
> what advantage is there to making it an open source project? As soon as
> you "improve" something, aren't you're likely to break the API?
>
> Is this really an attempt to get Sun to open source Java?
>
> I'm not trying to be critical or anything. Just wondering what's the
> point?
>
> Doug
>
>
Re: Backward compatibility
Posted by kna KnA'hr <xu...@gmail.com>.
ok, im nobody ... bt please tell me:
is it just a plan off you to create this alternati ve thing or did someone
wlready start?
which peolpe are involved in the projekt any bigletter names on its title?
...how much of the code must be handwritte, in which language?
does the language you write a vm in make any sense, i mean, it it important
if you write it in c or java, plz make me wiser
thanks so far - xJnkNa
On 5/12/05, FaeLLe <mr...@gmail.com> wrote:
>
> 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 <ke...@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> <http://www.FaeLLe.com>
>
>
Re: Backward compatibility
Posted by FaeLLe <mr...@gmail.com>.
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 <ke...@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>
Re: Backward compatibility
Posted by Kev Jackson <ke...@it.fts-vn.com>.
>* 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
Re: Backward compatibility
Posted by FaeLLe <mr...@gmail.com>.
Sorry but you miss two major points. (Please do correct me this is my
understanding by observing content on Harmony)
* 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
* 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 ?
On 5/12/05, Kev Jackson <ke...@it.fts-vn.com> wrote:
>
>
> >
> >> Deprecated or non deprecated, we want Harmony to pass the TCK, so
> >> whatever the TCK wants us to do, we'll do it.
> >
> >
> I would have thought that it must pass the TCK to have any chance of
> wide acceptance, so presumably that means implementing depracted code
> [sigh].
>
> > So what's the point? If all you're trying to do is duplicate J2SE 5,
> > what advantage is there to making it an open source project? As soon
> > as you "improve" something, aren't you're likely to break the API?
>
> The point I'd make is that just because you have to implement deprecated
> code to make it pass teh TCK doesn't mean you have to do a particularly
> good job at it. For example to implement some deprecated code will take
> 2 days (bear with me figures pulled from /dev/null) if you actually care
> about the performance, or 5 minutes and another 5 for the unit test just
> to ensure that the code does what you think it does. Should we spend
> any time optimizing deprecated code so that deprecated apps run as fast
> on harmony as on Sun J2SE? I'd argue no, for the simple reason that
> most of the stuff that's deprecated has been for a *long* time, and if
> you haven't refactored by now, you need to rethink your job as a
> professional developer (granted some apps can't be refactored, but then
> will they be contenders to run on Harmony?)
>
> Kev
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Backward compatibility
Posted by Kev Jackson <ke...@it.fts-vn.com>.
>
>> Deprecated or non deprecated, we want Harmony to pass the TCK, so
>> whatever the TCK wants us to do, we'll do it.
>
>
I would have thought that it must pass the TCK to have any chance of
wide acceptance, so presumably that means implementing depracted code
[sigh].
> So what's the point? If all you're trying to do is duplicate J2SE 5,
> what advantage is there to making it an open source project? As soon
> as you "improve" something, aren't you're likely to break the API?
The point I'd make is that just because you have to implement deprecated
code to make it pass teh TCK doesn't mean you have to do a particularly
good job at it. For example to implement some deprecated code will take
2 days (bear with me figures pulled from /dev/null) if you actually care
about the performance, or 5 minutes and another 5 for the unit test just
to ensure that the code does what you think it does. Should we spend
any time optimizing deprecated code so that deprecated apps run as fast
on harmony as on Sun J2SE? I'd argue no, for the simple reason that
most of the stuff that's deprecated has been for a *long* time, and if
you haven't refactored by now, you need to rethink your job as a
professional developer (granted some apps can't be refactored, but then
will they be contenders to run on Harmony?)
Kev
Re: Backward compatibility
Posted by FaeLLe <mr...@gmail.com>.
Your going to make him lose his job by suggesting such a thing.
On 5/12/05, Karen Bennet <be...@yahoo.com> wrote:
>
>
> Gerry,
>
> Additional help in testing is always welcome. However,
>
> your posting makes me wonder why Sun wouldn't enable
> this project to leapfrog whose 4-5 years to a product
> like Tiger by donating the missing pieces. This
> would enable the community to work alongside Sun in
> the development of mustang and dolphin in an
> collaborative development model. I'm not sure if
> feasibility or not
> but you did say if there was anything that you could
> do to help ... maybe an internal Sun employee might
> have a better chance of convincing their employer that
> collaboration around this technology would benefit
> them and potentially get Java development accelerated
> with future ideas.
>
> P.S. I know there have been many before who have asked
> for this same request; but here's hoping that its
> reconsidered.
>
>
> --- Gerry Steele <gegerrytsteelemgmailom> wrote:
>
> > Hi
> >
> > I actually did seem a bit cynical there.
> >
> > I forgot to mention that if there is anything I can
> > do to help let me know
> > or perhaps I'll keep an eye on the lists. I've
> > experience with the JCJCK
> > other tests so I could be useful in the QA area
> > considering it's quite an
> > esoteric task. I do believe that variety and
> > competition is good in software
> > for everyone. Though I do feel a bit sorry for sun..
> > they put up the money
> > to develop and create the Java world we have now and
> > everyone seems to want
> > it for their own. And they don't exactly ask for a
> > lot from users..... just
> > remember that the nearest competitor costs a small
> > fortune.
> >
> > Another sisidenotes Project Peabody. All those bugs
> > in Mustang that have
> > been bothering you are now open to anyone to submit
> > fixes.
> >
> hthttp/jajavaun.com/developer/tetechnicalArticles2SE/pepeabody
> >
> > And you get a free t-shirt when you contribute!
> >
> > Gerry
> >
> > On 5/12/05, FaFaeLLemrmrbillcollectormgmailom>
> > wrote:
> > >
> > > Very inintrestingnd well noted writeup sir an
> > insight from a Sun employee
> > > is always a bonus.
> > >
> > > I will for sure followup comments on this article
> > and see what the
> > > community has to say on this post.
> > >
> > > On 5/11/05, Gerry Steele < gegerrytsteelemgmailom>
> > wrote:
> > > >
> > > > I'm a big fan of the Apache foundation but this
> > is one product I'm not
> > > > too
> > > > sure is such a good idea as of yet for reasons
> > several:
> > > >
> > > > >> Deprecated or non deprecated, we want Harmony
> > to pass the TCTCKso
> > > > > >> whatever the TCTCKants us to do, we'll do
> > it.
> > > >
> > > > I hope you understand what sticking to the
> TCTCK> entails. When it comes to
> > > >
> > > > implementing GUI stuff for instance, your
> > platform will have to fully
> > > > copy
> > > > the official JVJVM'swing/AWAWTidgets and all
> > other details in order for
> > > > the
> > > > automation and robot driven tests to pass. The
> > JCJCKetestbaseor tiger is
> > > >
> > > > immense. To get it setup and run is a skill on
> > its own. To get it to
> > > > pass
> > > > all tests takes a serious am mount of tweaking
> > and a nonoteablenowledge
> > > > of
> > > > the jajavatestarness. It will require
> > implementations on things as
> > > > extensive
> > > > as COCORBAnd RMRMIWe would need passive agents,
> > tntnameervers etc.
> > > >
> > > > Also, when running the TCTCKear in mind that
> > you'll have to run the
> > > > harness
> > > > with the Sun VMVM
> > > >
> > > > I'm not sure about the particular extent of the
> > tetestsuiterovided with
> > > > the
> > > > TCTCKou guys are talking about (if there is
> > interest can find out more),
> > > > but
> > > > the JCJCKwhich is basically a TCTCKor the entire
> > J2SE jrjrend jdjdkill
> > > > be
> > > > going on impossible to pass for an alternative
> > imimplmentations
> > > > everything
> > > > is written with the Sun JDJDKRJREn mind and test
> > cases are adapted in
> > > > ways
> > > > that will create an infinite unpredictable
> > series of problems when
> > > > trying to
> > > > adapt your code.
> > > >
> > > > Another reason is that I'm not quite sure I see
> > the point. It will take
> > > > 4-5
> > > > years or more to even come close to a product
> > like tiger. Sun are
> > > > already
> > > > working heavily on mustang and dolphin (to a
> > lesser degree on the
> > > > latter).
> > > > As well as this, sun research have many projects
> > looking at the future
> > > > of
> > > > the Java VMVMuch as the Barcelona project which
> > will drastically change
> > > > the
> > > > implementation of the JVJVMFor instance to make
> > it more network
> > > > orientated
> > > > or to improve resource sharing.
> > > >
> > > > The latter things (which are yet to see real sun
> > implementation) might
> > > > be
> > > > something you guys might then want to take
> > advantage of in order to
> > > > leverage
> > > > a selling point of Harmony. Without something
> > like that it's just
> > > > another
> > > > attempt at a VMVMhat will be playing catch-up
> > forever.
> > > >
> > > > Also, don't forget about quality. Sun put a
> > serious amount of money and
> > > > manpower into ensuring the quality and
> > compatibility of the JVJVMA lot
> > > > of
> > > > corporations depend on this. They have a regular
> > update release cycle.
> > > > For
> > > > instance we are currently working on 1.3.1_16,
> > 1.4.2_09, 5.0_04 & 5.0_05
> > > > .
> > > >
> > > > In a project of this size some of the the test
> > suites take several days
> > > > to
> > > > run. Some take many many hours of man power. For
> > excessive thoroughness
> > > > there also manual JCJCKnd regression test
> > suites. Which, trust me, will
> > > > not
> > > > be performed by someone who isn't being paid for
> > it. Things like this
> > > > don't
> > > > fit well with the community model.
> > > >
> > > > Another worry I have is that the effort here
> > might be better redirect to
> > > >
> > > > some other project. We already have Java. Even
> > if harmony does make it
> > > > to a
> > > > ususeableelease people will still prefer to use
> > the Sun VMVMIt will be
> > > > the
> > > > platform people build on and it will be the one
> > they trust.
> > > >
> > > > I'll be very interested in how this turns out.
> > > >
> > > > Regards,
> > > > Gerry
> > > >
> > > > 1) speed
> > > > >
> > > > > 2) portability (jajavas claimed to run
> > 'everywhere', but in fact, it
> > > > > runs only on a few operating systems, even
> > fewer for 1.5)
> > > > >
> > > > > 3) coconfigurabilityI might want to tune it
> > differently and, for
> > > > > example, choose different thread/GCGCodels)
> > > > >
> > > > > 4) implementation ststategyin mamacosxmultiple
> > JVJVMshare 80% of their
> > > >
> > > > > memory, and some of Swing is native, therefore
> > feels like the rest of
> > > > > the OS and it's hardware accelerated)
> > > > >
> > > > > 5) internal modularity (we want diversity of
> > implementation to drive
> > > > > innovation in the VMVMpace, both in and out
> > companies and
> >
> === message truncated ===
>
> Discover Yahoo!
> Stay in touch with email, IM, photo sharing and more. Check it out!
> http://discover.yahoo.com/stayintouch.html
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Backward compatibility
Posted by Stefano Mazzocchi <st...@apache.org>.
Gerry Steele wrote:
> Hi
>
> I actually did seem a bit cynical there.
>
> I forgot to mention that if there is anything I can do to help let me know
> or perhaps I'll keep an eye on the lists. I've experience with the JCK &
> other tests so I could be useful in the QA area considering it's quite an
> esoteric task. I do believe that variety and competition is good in software
> for everyone. Though I do feel a bit sorry for sun.. they put up the money
> to develop and create the Java world we have now and everyone seems to want
> it for their own.
ehm, before apache got interested in servlets, java was a technology to
implement applets in web pages. It was because of the Servlet API that
java started to be considered as a serious platform and Apache was
instrumental for that in releasing the state-of-the-art servlet engines
since 1997.
The java world is thankful to Sun and to Apache. Sun and Apache are
thankful to one another and respect each other deeply.
Sun is afraid of open source because they claim it will be easy for big
corporations to steer away from JVM compatibility. It's like parents
that are afraid of seeing their kids go out of the house: understandable
and irrational at the same time.
We want to show them there is no such a fear to have, just like having
Tomcat the biggest player in the servlet engine market *helped*
stabilizing the servlet technology, not the other way around.
So, they claimed that servlets were already a wasteland for strategy
reasons, so we created Geronimo.
And now that we are ready to show how open source support for J2EE makes
the compatibility promise stronger, not weaker, we felt ready to push to
the next and final level: the VM.
The message is clear: open source and free software are allies, not
enemies: they all drink at the same stream, polluting it with
incompatibilities would be suicidal for a community-driven development.
Apache gives the proper legal, economical and social contracts that are
needed for the java world to feel confident that evolution won't mean
fragmentation.
The *only* reason why Sun wants to keep spending all that money in
writing a JVM is because they are afraid that if they let go, others
will run the show.
We talked and talked and talked for *years* to try to convince Sun this
was not the case, we got even very close at one point, but then the
bubble exploded, people got burned and the deal went down the drain.
We are sick of talking.
It's time we do what we are best at: build communities that write
software that becomes the *de facto* standard in their space.
And look around: we have a pretty good history of doing that.
> And they don't exactly ask for a lot from users..... just
> remember that the nearest competitor costs a small fortune.
Oh, we know that. Look at gump: do you think we really want to rewrite
all those million lines of code?
> Another sidenote is Project Peabody. All those bugs in Mustang that have
> been bothering you are now open to anyone to submit fixes.
> http://java.sun.com/developer/technicalArticles/J2SE/peabody/
That is a step forward, very true, but that is not open source and not
an environment where the more I commit the more I can influence
architectural decisions. If just feels like I'm working for you for
free: you will get fixes, but no innovation.
> And you get a free t-shirt when you contribute!
Big deal, here you get enough visibility and respect to earn 20K$ more
at your next job. ;-)
--
Stefano.
Re: Backward compatibility
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 11, 2005, at 8:59 PM, Karen Bennet wrote:
>
> Gerry,
>
> Additional help in testing is always welcome. However,
>
> your posting makes me wonder why Sun wouldn't enable
> this project to leapfrog whose 4-5 years to a product
> like Tiger by donating the missing pieces. This
> would enable the community to work alongside Sun in
> the development of mustang and dolphin in an
> collaborative development model. I'm not sure if
> feasibility or not
> but you did say if there was anything that you could
> do to help ... maybe an internal Sun employee might
> have a better chance of convincing their employer that
> collaboration around this technology would benefit
> them and potentially get Java development accelerated
> with future ideas.
I've brought this us with Sun - how they can support us and support
compatibility with contributions. I don't want to push on this -
they know what we need (I mean, if anyone does, they do)...
I personally am not interested in this being a forcing function :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Backward compatibility
Posted by Karen Bennet <be...@yahoo.com>.
Gerry,
Additional help in testing is always welcome. However,
your posting makes me wonder why Sun wouldn't enable
this project to leapfrog whose 4-5 years to a product
like Tiger by donating the missing pieces. This
would enable the community to work alongside Sun in
the development of mustang and dolphin in an
collaborative development model. I'm not sure if
feasibility or not
but you did say if there was anything that you could
do to help ... maybe an internal Sun employee might
have a better chance of convincing their employer that
collaboration around this technology would benefit
them and potentially get Java development accelerated
with future ideas.
P.S. I know there have been many before who have asked
for this same request; but here's hoping that its
reconsidered.
--- Gerry Steele <gegerrytsteelemgmailom> wrote:
> Hi
>
> I actually did seem a bit cynical there.
>
> I forgot to mention that if there is anything I can
> do to help let me know
> or perhaps I'll keep an eye on the lists. I've
> experience with the JCJCK
> other tests so I could be useful in the QA area
> considering it's quite an
> esoteric task. I do believe that variety and
> competition is good in software
> for everyone. Though I do feel a bit sorry for sun..
> they put up the money
> to develop and create the Java world we have now and
> everyone seems to want
> it for their own. And they don't exactly ask for a
> lot from users..... just
> remember that the nearest competitor costs a small
> fortune.
>
> Another sisidenotes Project Peabody. All those bugs
> in Mustang that have
> been bothering you are now open to anyone to submit
> fixes.
>
hthttp/jajavaun.com/developer/tetechnicalArticles2SE/pepeabody
>
> And you get a free t-shirt when you contribute!
>
> Gerry
>
> On 5/12/05, FaFaeLLemrmrbillcollectormgmailom>
> wrote:
> >
> > Very inintrestingnd well noted writeup sir an
> insight from a Sun employee
> > is always a bonus.
> >
> > I will for sure followup comments on this article
> and see what the
> > community has to say on this post.
> >
> > On 5/11/05, Gerry Steele < gegerrytsteelemgmailom>
> wrote:
> > >
> > > I'm a big fan of the Apache foundation but this
> is one product I'm not
> > > too
> > > sure is such a good idea as of yet for reasons
> several:
> > >
> > > >> Deprecated or non deprecated, we want Harmony
> to pass the TCTCKso
> > > > >> whatever the TCTCKants us to do, we'll do
> it.
> > >
> > > I hope you understand what sticking to the
TCTCK> entails. When it comes to
> > >
> > > implementing GUI stuff for instance, your
> platform will have to fully
> > > copy
> > > the official JVJVM'swing/AWAWTidgets and all
> other details in order for
> > > the
> > > automation and robot driven tests to pass. The
> JCJCKetestbaseor tiger is
> > >
> > > immense. To get it setup and run is a skill on
> its own. To get it to
> > > pass
> > > all tests takes a serious am mount of tweaking
> and a nonoteablenowledge
> > > of
> > > the jajavatestarness. It will require
> implementations on things as
> > > extensive
> > > as COCORBAnd RMRMIWe would need passive agents,
> tntnameervers etc.
> > >
> > > Also, when running the TCTCKear in mind that
> you'll have to run the
> > > harness
> > > with the Sun VMVM
> > >
> > > I'm not sure about the particular extent of the
> tetestsuiterovided with
> > > the
> > > TCTCKou guys are talking about (if there is
> interest can find out more),
> > > but
> > > the JCJCKwhich is basically a TCTCKor the entire
> J2SE jrjrend jdjdkill
> > > be
> > > going on impossible to pass for an alternative
> imimplmentations
> > > everything
> > > is written with the Sun JDJDKRJREn mind and test
> cases are adapted in
> > > ways
> > > that will create an infinite unpredictable
> series of problems when
> > > trying to
> > > adapt your code.
> > >
> > > Another reason is that I'm not quite sure I see
> the point. It will take
> > > 4-5
> > > years or more to even come close to a product
> like tiger. Sun are
> > > already
> > > working heavily on mustang and dolphin (to a
> lesser degree on the
> > > latter).
> > > As well as this, sun research have many projects
> looking at the future
> > > of
> > > the Java VMVMuch as the Barcelona project which
> will drastically change
> > > the
> > > implementation of the JVJVMFor instance to make
> it more network
> > > orientated
> > > or to improve resource sharing.
> > >
> > > The latter things (which are yet to see real sun
> implementation) might
> > > be
> > > something you guys might then want to take
> advantage of in order to
> > > leverage
> > > a selling point of Harmony. Without something
> like that it's just
> > > another
> > > attempt at a VMVMhat will be playing catch-up
> forever.
> > >
> > > Also, don't forget about quality. Sun put a
> serious amount of money and
> > > manpower into ensuring the quality and
> compatibility of the JVJVMA lot
> > > of
> > > corporations depend on this. They have a regular
> update release cycle.
> > > For
> > > instance we are currently working on 1.3.1_16,
> 1.4.2_09, 5.0_04 & 5.0_05
> > > .
> > >
> > > In a project of this size some of the the test
> suites take several days
> > > to
> > > run. Some take many many hours of man power. For
> excessive thoroughness
> > > there also manual JCJCKnd regression test
> suites. Which, trust me, will
> > > not
> > > be performed by someone who isn't being paid for
> it. Things like this
> > > don't
> > > fit well with the community model.
> > >
> > > Another worry I have is that the effort here
> might be better redirect to
> > >
> > > some other project. We already have Java. Even
> if harmony does make it
> > > to a
> > > ususeableelease people will still prefer to use
> the Sun VMVMIt will be
> > > the
> > > platform people build on and it will be the one
> they trust.
> > >
> > > I'll be very interested in how this turns out.
> > >
> > > Regards,
> > > Gerry
> > >
> > > 1) speed
> > > >
> > > > 2) portability (jajavas claimed to run
> 'everywhere', but in fact, it
> > > > runs only on a few operating systems, even
> fewer for 1.5)
> > > >
> > > > 3) coconfigurabilityI might want to tune it
> differently and, for
> > > > example, choose different thread/GCGCodels)
> > > >
> > > > 4) implementation ststategyin mamacosxmultiple
> JVJVMshare 80% of their
> > >
> > > > memory, and some of Swing is native, therefore
> feels like the rest of
> > > > the OS and it's hardware accelerated)
> > > >
> > > > 5) internal modularity (we want diversity of
> implementation to drive
> > > > innovation in the VMVMpace, both in and out
> companies and
>
=== message truncated ===
Discover Yahoo!
Stay in touch with email, IM, photo sharing and more. Check it out!
http://discover.yahoo.com/stayintouch.html
Re: Backward compatibility
Posted by Gerry Steele <ge...@gmail.com>.
Hi
I actually did seem a bit cynical there.
I forgot to mention that if there is anything I can do to help let me know
or perhaps I'll keep an eye on the lists. I've experience with the JCK &
other tests so I could be useful in the QA area considering it's quite an
esoteric task. I do believe that variety and competition is good in software
for everyone. Though I do feel a bit sorry for sun.. they put up the money
to develop and create the Java world we have now and everyone seems to want
it for their own. And they don't exactly ask for a lot from users..... just
remember that the nearest competitor costs a small fortune.
Another sidenote is Project Peabody. All those bugs in Mustang that have
been bothering you are now open to anyone to submit fixes.
http://java.sun.com/developer/technicalArticles/J2SE/peabody/
And you get a free t-shirt when you contribute!
Gerry
On 5/12/05, FaeLLe <mr...@gmail.com> wrote:
>
> Very intresting and well noted writeup sir an insight from a Sun employee
> is always a bonus.
>
> I will for sure followup comments on this article and see what the
> community has to say on this post.
>
> On 5/11/05, Gerry Steele < gerry.steele@gmail.com> wrote:
> >
> > I'm a big fan of the Apache foundation but this is one product I'm not
> > too
> > sure is such a good idea as of yet for reasons several:
> >
> > >> Deprecated or non deprecated, we want Harmony to pass the TCK, so
> > > >> whatever the TCK wants us to do, we'll do it.
> >
> > I hope you understand what sticking to the TCK entails. When it comes to
> >
> > implementing GUI stuff for instance, your platform will have to fully
> > copy
> > the official JVM's Swing/AWT widgets and all other details in order for
> > the
> > automation and robot driven tests to pass. The JCK testbase for tiger is
> >
> > immense. To get it setup and run is a skill on its own. To get it to
> > pass
> > all tests takes a serious am mount of tweaking and a noteable knowledge
> > of
> > the javatest harness. It will require implementations on things as
> > extensive
> > as CORBA and RMI. We would need passive agents, tname servers etc.
> >
> > Also, when running the TCK bear in mind that you'll have to run the
> > harness
> > with the Sun VM.
> >
> > I'm not sure about the particular extent of the testsuite provided with
> > the
> > TCK you guys are talking about (if there is interest can find out more),
> > but
> > the JCK, which is basically a TCK for the entire J2SE jre and jdk will
> > be
> > going on impossible to pass for an alternative implmentation as
> > everything
> > is written with the Sun JDK/JRE in mind and test cases are adapted in
> > ways
> > that will create an infinite unpredictable series of problems when
> > trying to
> > adapt your code.
> >
> > Another reason is that I'm not quite sure I see the point. It will take
> > 4-5
> > years or more to even come close to a product like tiger. Sun are
> > already
> > working heavily on mustang and dolphin (to a lesser degree on the
> > latter).
> > As well as this, sun research have many projects looking at the future
> > of
> > the Java VM such as the Barcelona project which will drastically change
> > the
> > implementation of the JVM. For instance to make it more network
> > orientated
> > or to improve resource sharing.
> >
> > The latter things (which are yet to see real sun implementation) might
> > be
> > something you guys might then want to take advantage of in order to
> > leverage
> > a selling point of Harmony. Without something like that it's just
> > another
> > attempt at a VM that will be playing catch-up forever.
> >
> > Also, don't forget about quality. Sun put a serious amount of money and
> > manpower into ensuring the quality and compatibility of the JVM. A lot
> > of
> > corporations depend on this. They have a regular update release cycle.
> > For
> > instance we are currently working on 1.3.1_16, 1.4.2_09, 5.0_04 & 5.0_05
> > .
> >
> > In a project of this size some of the the test suites take several days
> > to
> > run. Some take many many hours of man power. For excessive thoroughness
> > there also manual JCK and regression test suites. Which, trust me, will
> > not
> > be performed by someone who isn't being paid for it. Things like this
> > don't
> > fit well with the community model.
> >
> > Another worry I have is that the effort here might be better redirect to
> >
> > some other project. We already have Java. Even if harmony does make it
> > to a
> > useable release people will still prefer to use the Sun VM. It will be
> > the
> > platform people build on and it will be the one they trust.
> >
> > I'll be very interested in how this turns out.
> >
> > Regards,
> > Gerry
> >
> > 1) speed
> > >
> > > 2) portability (java is claimed to run 'everywhere', but in fact, it
> > > runs only on a few operating systems, even fewer for 1.5)
> > >
> > > 3) configurability (I might want to tune it differently and, for
> > > example, choose different thread/GC models)
> > >
> > > 4) implementation stategy (in macosx, multiple JVMs share 80% of their
> >
> > > memory, and some of Swing is native, therefore feels like the rest of
> > > the OS and it's hardware accelerated)
> > >
> > > 5) internal modularity (we want diversity of implementation to drive
> > > innovation in the VM space, both in and out companies and
> > universities)
> > >
> > > And, last but not least, if Sun or other vendors that already have JVM
> > > want to stop paying for all that development on their and want to
> > start
> > > sharing the development costs with the java ecosystem in general and
> > > with a clear warranty that we will not try to pollute the stream we
> > all
> > > drink from, therefore want to contribute some of their code to
> > Harmony,
> > > we will welcome them with open arms.
> > >
> > > --
> > > Stefano.
> > >
> > >
> >
> > --
> > Gerry Steele
> >
> > x74521/+353-1-8199 521
> > http://blogs.sun.com/roller/page/gerrys
> > [ gerry.steele@sun.com OR gerry.steele@gmail.com]
> >
> >
>
>
> --
> www.FaeLLe.com <http://www.FaeLLe.com>
--
Gerry Steele
x74521/+353-1-8199 521
http://blogs.sun.com/roller/page/gerrys
[gerry.steele@sun.com OR gerry.steele@gmail.com]
Re: Backward compatibility
Posted by FaeLLe <mr...@gmail.com>.
Very intresting and well noted writeup sir an insight from a Sun employee is
always a bonus.
I will for sure followup comments on this article and see what the community
has to say on this post.
On 5/11/05, Gerry Steele <ge...@gmail.com> wrote:
>
> I'm a big fan of the Apache foundation but this is one product I'm not too
> sure is such a good idea as of yet for reasons several:
>
> >> Deprecated or non deprecated, we want Harmony to pass the TCK, so
> > >> whatever the TCK wants us to do, we'll do it.
>
> I hope you understand what sticking to the TCK entails. When it comes to
> implementing GUI stuff for instance, your platform will have to fully copy
> the official JVM's Swing/AWT widgets and all other details in order for
> the
> automation and robot driven tests to pass. The JCK testbase for tiger is
> immense. To get it setup and run is a skill on its own. To get it to pass
> all tests takes a serious am mount of tweaking and a noteable knowledge of
> the javatest harness. It will require implementations on things as
> extensive
> as CORBA and RMI. We would need passive agents, tname servers etc.
>
> Also, when running the TCK bear in mind that you'll have to run the
> harness
> with the Sun VM.
>
> I'm not sure about the particular extent of the testsuite provided with
> the
> TCK you guys are talking about (if there is interest can find out more),
> but
> the JCK, which is basically a TCK for the entire J2SE jre and jdk will be
> going on impossible to pass for an alternative implmentation as everything
> is written with the Sun JDK/JRE in mind and test cases are adapted in ways
> that will create an infinite unpredictable series of problems when trying
> to
> adapt your code.
>
> Another reason is that I'm not quite sure I see the point. It will take
> 4-5
> years or more to even come close to a product like tiger. Sun are already
> working heavily on mustang and dolphin (to a lesser degree on the latter).
> As well as this, sun research have many projects looking at the future of
> the Java VM such as the Barcelona project which will drastically change
> the
> implementation of the JVM. For instance to make it more network orientated
> or to improve resource sharing.
>
> The latter things (which are yet to see real sun implementation) might be
> something you guys might then want to take advantage of in order to
> leverage
> a selling point of Harmony. Without something like that it's just another
> attempt at a VM that will be playing catch-up forever.
>
> Also, don't forget about quality. Sun put a serious amount of money and
> manpower into ensuring the quality and compatibility of the JVM. A lot of
> corporations depend on this. They have a regular update release cycle. For
> instance we are currently working on 1.3.1_16, 1.4.2_09, 5.0_04 & 5.0_05.
>
> In a project of this size some of the the test suites take several days to
> run. Some take many many hours of man power. For excessive thoroughness
> there also manual JCK and regression test suites. Which, trust me, will
> not
> be performed by someone who isn't being paid for it. Things like this
> don't
> fit well with the community model.
>
> Another worry I have is that the effort here might be better redirect to
> some other project. We already have Java. Even if harmony does make it to
> a
> useable release people will still prefer to use the Sun VM. It will be the
> platform people build on and it will be the one they trust.
>
> I'll be very interested in how this turns out.
>
> Regards,
> Gerry
>
> 1) speed
> >
> > 2) portability (java is claimed to run 'everywhere', but in fact, it
> > runs only on a few operating systems, even fewer for 1.5)
> >
> > 3) configurability (I might want to tune it differently and, for
> > example, choose different thread/GC models)
> >
> > 4) implementation stategy (in macosx, multiple JVMs share 80% of their
> > memory, and some of Swing is native, therefore feels like the rest of
> > the OS and it's hardware accelerated)
> >
> > 5) internal modularity (we want diversity of implementation to drive
> > innovation in the VM space, both in and out companies and universities)
> >
> > And, last but not least, if Sun or other vendors that already have JVM
> > want to stop paying for all that development on their and want to start
> > sharing the development costs with the java ecosystem in general and
> > with a clear warranty that we will not try to pollute the stream we all
> > drink from, therefore want to contribute some of their code to Harmony,
> > we will welcome them with open arms.
> >
> > --
> > Stefano.
> >
> >
>
> --
> Gerry Steele
>
> x74521/+353-1-8199 521
> http://blogs.sun.com/roller/page/gerrys
> [gerry.steele@sun.com OR gerry.steele@gmail.com]
>
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Backward compatibility
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 12, 2005, at 8:29 PM, FaeLLe wrote:
> Everytime i read posts from you lot at Apache i feel more conviced
> this
> thing is going to be one huge success.
Thanks - we hope so. It's going to be a lot of work by a lot of
people...
>
> I cant imagine how convincing your salesmen must be !! (If you
> indeed did
> have salesment to market).
At Apache? :)
geir
>
> On 5/13/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>>
>> I didn't cc Gerry - I assume he's subscribed.
>>
>> On May 11, 2005, at 6:22 PM, Gerry Steele wrote:
>>
>>
>>> I'm a big fan of the Apache foundation but this is one product I'm
>>> not too
>>> sure is such a good idea as of yet for reasons several:
>>>
>>>
>>>
>>>>> Deprecated or non deprecated, we want Harmony to pass the TCK, so
>>>>>
>>>>>
>>>>>> whatever the TCK wants us to do, we'll do it.
>>>>>>
>>>>>>
>>>
>>>
>>> I hope you understand what sticking to the TCK entails. When it
>>> comes to
>>> implementing GUI stuff for instance, your platform will have to
>>> fully copy
>>> the official JVM's Swing/AWT widgets and all other details in order
>>> for the
>>> automation and robot driven tests to pass. The JCK testbase for
>>> tiger is
>>> immense. To get it setup and run is a skill on its own. To get it
>>> to pass
>>> all tests takes a serious am mount of tweaking and a noteable
>>> knowledge of
>>> the javatest harness. It will require implementations on things as
>>> extensive
>>> as CORBA and RMI. We would need passive agents, tname servers etc.
>>>
>>
>> Indeed. We face the same thing with the J2EE TCK. It's a lot of
>> work, but we've proven that it can be done in the Apache environment.
>>
>>
>>>
>>> Also, when running the TCK bear in mind that you'll have to run the
>>> harness
>>> with the Sun VM.
>>>
>>> I'm not sure about the particular extent of the testsuite provided
>>> with the
>>> TCK you guys are talking about (if there is interest can find out
>>> more), but
>>> the JCK, which is basically a TCK for the entire J2SE jre and jdk
>>> will be
>>> going on impossible to pass for an alternative implmentation as
>>> everything
>>> is written with the Sun JDK/JRE in mind and test cases are adapted
>>> in ways
>>> that will create an infinite unpredictable series of problems when
>>> trying to
>>> adapt your code.
>>>
>>
>> I believe that you may be mistaken, or it's just a problem of
>> phrasing :) I'm sure that any tests that are for specific extra-
>> specification Sun-specific behavior will be added to the exception
>> list and therefore not have to pass. We've run into a few things
>> like this w/ the TCK for J2EE. For me, they are just TCK
>> implementation mistakes, rather than any requirement to have Sun
>> implementations as part of the tested code.
>>
>>
>>>
>>> Another reason is that I'm not quite sure I see the point. It will
>>> take 4-5
>>> years or more to even come close to a product like tiger. Sun are
>>> already
>>> working heavily on mustang and dolphin (to a lesser degree on the
>>> latter).
>>> As well as this, sun research have many projects looking at the
>>> future of
>>> the Java VM such as the Barcelona project which will drastically
>>> change the
>>> implementation of the JVM. For instance to make it more network
>>> orientated
>>> or to improve resource sharing.
>>>
>>
>> It's clear that Sun does put a lot of effort into this. But don't
>> underestimate what an open source community can do.
>>
>>
>>>
>>> The latter things (which are yet to see real sun implementation)
>>> might be
>>> something you guys might then want to take advantage of in order to
>>> leverage
>>> a selling point of Harmony. Without something like that it's just
>>> another
>>> attempt at a VM that will be playing catch-up forever.
>>>
>>
>> We'll see :)
>>
>>
>>>
>>> Also, don't forget about quality. Sun put a serious amount of money
>>> and
>>> manpower into ensuring the quality and compatibility of the JVM. A
>>> lot of
>>> corporations depend on this. They have a regular update release
>>> cycle. For
>>> instance we are currently working on 1.3.1_16, 1.4.2_09, 5.0_04 &
>>> 5.0_05.
>>>
>>
>> Yes - quality is a major factor here. If we can't have the same
>> quality, people won't care, and the code won't be used. That's been
>> something we've been aware of since day 1.
>>
>>
>>>
>>> In a project of this size some of the the test suites take several
>>> days to
>>> run. Some take many many hours of man power. For excessive
>>> thoroughness
>>> there also manual JCK and regression test suites. Which, trust me,
>>> will not
>>> be performed by someone who isn't being paid for it. Things like
>>> this don't
>>> fit well with the community model.
>>>
>>
>> I'm not so sure. I can easily see that we can find people that would
>> want to be paid to do it, and people that might pay them to do it.
>> There's nothing wrong with commercial involvement in projects at
>> apache, as long as it's a standard Apache-style, transparent
>> meritocracy. Throughout the ASF, you'll find individuals
>> participating in projects that are paid by someone to do so.
>>
>>
>>>
>>> Another worry I have is that the effort here might be better
>>> redirect to
>>> some other project. We already have Java. Even if harmony does make
>>> it to a
>>> useable release people will still prefer to use the Sun VM. It will
>>> be the
>>> platform people build on and it will be the one they trust.
>>>
>>> I'll be very interested in how this turns out.
>>>
>>
>> As will we all. Please consider helping us out :)
>>
>> geir
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>
>
> --
> www.FaeLLe.com <http://www.FaeLLe.com>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Backward compatibility
Posted by FaeLLe <mr...@gmail.com>.
Everytime i read posts from you lot at Apache i feel more conviced this
thing is going to be one huge success.
I cant imagine how convincing your salesmen must be !! (If you indeed did
have salesment to market).
On 5/13/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
> I didn't cc Gerry - I assume he's subscribed.
>
> On May 11, 2005, at 6:22 PM, Gerry Steele wrote:
>
> > I'm a big fan of the Apache foundation but this is one product I'm
> > not too
> > sure is such a good idea as of yet for reasons several:
> >
> >
> >>> Deprecated or non deprecated, we want Harmony to pass the TCK, so
> >>>
> >>>> whatever the TCK wants us to do, we'll do it.
> >>>>
> >
> >
> > I hope you understand what sticking to the TCK entails. When it
> > comes to
> > implementing GUI stuff for instance, your platform will have to
> > fully copy
> > the official JVM's Swing/AWT widgets and all other details in order
> > for the
> > automation and robot driven tests to pass. The JCK testbase for
> > tiger is
> > immense. To get it setup and run is a skill on its own. To get it
> > to pass
> > all tests takes a serious am mount of tweaking and a noteable
> > knowledge of
> > the javatest harness. It will require implementations on things as
> > extensive
> > as CORBA and RMI. We would need passive agents, tname servers etc.
>
> Indeed. We face the same thing with the J2EE TCK. It's a lot of
> work, but we've proven that it can be done in the Apache environment.
>
> >
> > Also, when running the TCK bear in mind that you'll have to run the
> > harness
> > with the Sun VM.
> >
> > I'm not sure about the particular extent of the testsuite provided
> > with the
> > TCK you guys are talking about (if there is interest can find out
> > more), but
> > the JCK, which is basically a TCK for the entire J2SE jre and jdk
> > will be
> > going on impossible to pass for an alternative implmentation as
> > everything
> > is written with the Sun JDK/JRE in mind and test cases are adapted
> > in ways
> > that will create an infinite unpredictable series of problems when
> > trying to
> > adapt your code.
>
> I believe that you may be mistaken, or it's just a problem of
> phrasing :) I'm sure that any tests that are for specific extra-
> specification Sun-specific behavior will be added to the exception
> list and therefore not have to pass. We've run into a few things
> like this w/ the TCK for J2EE. For me, they are just TCK
> implementation mistakes, rather than any requirement to have Sun
> implementations as part of the tested code.
>
> >
> > Another reason is that I'm not quite sure I see the point. It will
> > take 4-5
> > years or more to even come close to a product like tiger. Sun are
> > already
> > working heavily on mustang and dolphin (to a lesser degree on the
> > latter).
> > As well as this, sun research have many projects looking at the
> > future of
> > the Java VM such as the Barcelona project which will drastically
> > change the
> > implementation of the JVM. For instance to make it more network
> > orientated
> > or to improve resource sharing.
>
> It's clear that Sun does put a lot of effort into this. But don't
> underestimate what an open source community can do.
>
> >
> > The latter things (which are yet to see real sun implementation)
> > might be
> > something you guys might then want to take advantage of in order to
> > leverage
> > a selling point of Harmony. Without something like that it's just
> > another
> > attempt at a VM that will be playing catch-up forever.
>
> We'll see :)
>
> >
> > Also, don't forget about quality. Sun put a serious amount of money
> > and
> > manpower into ensuring the quality and compatibility of the JVM. A
> > lot of
> > corporations depend on this. They have a regular update release
> > cycle. For
> > instance we are currently working on 1.3.1_16, 1.4.2_09, 5.0_04 &
> > 5.0_05.
>
> Yes - quality is a major factor here. If we can't have the same
> quality, people won't care, and the code won't be used. That's been
> something we've been aware of since day 1.
>
> >
> > In a project of this size some of the the test suites take several
> > days to
> > run. Some take many many hours of man power. For excessive
> > thoroughness
> > there also manual JCK and regression test suites. Which, trust me,
> > will not
> > be performed by someone who isn't being paid for it. Things like
> > this don't
> > fit well with the community model.
>
> I'm not so sure. I can easily see that we can find people that would
> want to be paid to do it, and people that might pay them to do it.
> There's nothing wrong with commercial involvement in projects at
> apache, as long as it's a standard Apache-style, transparent
> meritocracy. Throughout the ASF, you'll find individuals
> participating in projects that are paid by someone to do so.
>
> >
> > Another worry I have is that the effort here might be better
> > redirect to
> > some other project. We already have Java. Even if harmony does make
> > it to a
> > useable release people will still prefer to use the Sun VM. It will
> > be the
> > platform people build on and it will be the one they trust.
> >
> > I'll be very interested in how this turns out.
>
> As will we all. Please consider helping us out :)
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Backward compatibility
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
I didn't cc Gerry - I assume he's subscribed.
On May 11, 2005, at 6:22 PM, Gerry Steele wrote:
> I'm a big fan of the Apache foundation but this is one product I'm
> not too
> sure is such a good idea as of yet for reasons several:
>
>
>>> Deprecated or non deprecated, we want Harmony to pass the TCK, so
>>>
>>>> whatever the TCK wants us to do, we'll do it.
>>>>
>
>
> I hope you understand what sticking to the TCK entails. When it
> comes to
> implementing GUI stuff for instance, your platform will have to
> fully copy
> the official JVM's Swing/AWT widgets and all other details in order
> for the
> automation and robot driven tests to pass. The JCK testbase for
> tiger is
> immense. To get it setup and run is a skill on its own. To get it
> to pass
> all tests takes a serious am mount of tweaking and a noteable
> knowledge of
> the javatest harness. It will require implementations on things as
> extensive
> as CORBA and RMI. We would need passive agents, tname servers etc.
Indeed. We face the same thing with the J2EE TCK. It's a lot of
work, but we've proven that it can be done in the Apache environment.
>
> Also, when running the TCK bear in mind that you'll have to run the
> harness
> with the Sun VM.
>
> I'm not sure about the particular extent of the testsuite provided
> with the
> TCK you guys are talking about (if there is interest can find out
> more), but
> the JCK, which is basically a TCK for the entire J2SE jre and jdk
> will be
> going on impossible to pass for an alternative implmentation as
> everything
> is written with the Sun JDK/JRE in mind and test cases are adapted
> in ways
> that will create an infinite unpredictable series of problems when
> trying to
> adapt your code.
I believe that you may be mistaken, or it's just a problem of
phrasing :) I'm sure that any tests that are for specific extra-
specification Sun-specific behavior will be added to the exception
list and therefore not have to pass. We've run into a few things
like this w/ the TCK for J2EE. For me, they are just TCK
implementation mistakes, rather than any requirement to have Sun
implementations as part of the tested code.
>
> Another reason is that I'm not quite sure I see the point. It will
> take 4-5
> years or more to even come close to a product like tiger. Sun are
> already
> working heavily on mustang and dolphin (to a lesser degree on the
> latter).
> As well as this, sun research have many projects looking at the
> future of
> the Java VM such as the Barcelona project which will drastically
> change the
> implementation of the JVM. For instance to make it more network
> orientated
> or to improve resource sharing.
It's clear that Sun does put a lot of effort into this. But don't
underestimate what an open source community can do.
>
> The latter things (which are yet to see real sun implementation)
> might be
> something you guys might then want to take advantage of in order to
> leverage
> a selling point of Harmony. Without something like that it's just
> another
> attempt at a VM that will be playing catch-up forever.
We'll see :)
>
> Also, don't forget about quality. Sun put a serious amount of money
> and
> manpower into ensuring the quality and compatibility of the JVM. A
> lot of
> corporations depend on this. They have a regular update release
> cycle. For
> instance we are currently working on 1.3.1_16, 1.4.2_09, 5.0_04 &
> 5.0_05.
Yes - quality is a major factor here. If we can't have the same
quality, people won't care, and the code won't be used. That's been
something we've been aware of since day 1.
>
> In a project of this size some of the the test suites take several
> days to
> run. Some take many many hours of man power. For excessive
> thoroughness
> there also manual JCK and regression test suites. Which, trust me,
> will not
> be performed by someone who isn't being paid for it. Things like
> this don't
> fit well with the community model.
I'm not so sure. I can easily see that we can find people that would
want to be paid to do it, and people that might pay them to do it.
There's nothing wrong with commercial involvement in projects at
apache, as long as it's a standard Apache-style, transparent
meritocracy. Throughout the ASF, you'll find individuals
participating in projects that are paid by someone to do so.
>
> Another worry I have is that the effort here might be better
> redirect to
> some other project. We already have Java. Even if harmony does make
> it to a
> useable release people will still prefer to use the Sun VM. It will
> be the
> platform people build on and it will be the one they trust.
>
> I'll be very interested in how this turns out.
As will we all. Please consider helping us out :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Backward compatibility
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 11, 2005, at 8:03 PM, Stefano Mazzocchi wrote:
>
> if Harmony fails to write even a single line of code, but helps
> building better social bridges and making a 'free and open
> certified JVM' a reality, I won't consider it a failure.
Indeed.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Backward compatibility
Posted by Stefano Mazzocchi <st...@apache.org>.
Gerry Steele wrote:
> I'll be very interested in how this turns out.
Gerry,
if Harmony fails to write even a single line of code, but helps building
better social bridges and making a 'free and open certified JVM' a
reality, I won't consider it a failure.
Helping out doesn't mean rewriting in the sake of "my license is holier
than yours", both camps are rather pragmatic at licensing issues...
unfortunatley we have to deal with other people that are not so
pragmatic, or with scenarios/egos so big that can hardly be moved or
even routed around.
So, don't tell us in how many ways we can fail, we know all those
already (and more ;-)
Let's do one step at a time and don't look at how many steps there are
to make: the worst way to fail is not to try at all :-)
--
Stefano.
Re: Backward compatibility
Posted by Stefano Mazzocchi <st...@apache.org>.
Robert Schuster wrote:
> I want to jump at the chance to send my kindest regards to my fellow
> hackers from the Apache community: Thanks for getting together - this
> cooperation will rock!
<bowing and taking my hat-with-the-feather (pun intended) off/>
It is my (and others') deep pleasure!
Together, we are stronger and we will have more fun :-)
The differences between us are a lot smaller than the similarities. It's
time to build on that.
--
Stefano.
Re: Backward compatibility
Posted by Robert Schuster <th...@gmx.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
> I hope you understand what sticking to the TCK entails. When it comes to
> implementing GUI stuff for instance, your platform will have to fully copy
> the official JVM's Swing/AWT widgets and all other details in order for the
> automation and robot driven tests to pass. The JCK testbase for tiger is
> immense. To get it setup and run is a skill on its own. To get it to pass
> all tests takes a serious am mount of tweaking and a noteable knowledge of
> the javatest harness. It will require implementations on things as extensive
> as CORBA and RMI. We would need passive agents, tname servers etc.
Ok. We also have an evergrowing test suite called mauve[0].
>
> Also, when running the TCK bear in mind that you'll have to run the harness
> with the Sun VM.
>
> I'm not sure about the particular extent of the testsuite provided with the
> TCK you guys are talking about (if there is interest can find out more), but
> the JCK, which is basically a TCK for the entire J2SE jre and jdk will be
> going on impossible to pass for an alternative implmentation as everything
> is written with the Sun JDK/JRE in mind and test cases are adapted in ways
> that will create an infinite unpredictable series of problems when trying to
> adapt your code.
I am not sure whether this speaks in favor of the TCK. A testsuite
should IMHO be implementation independent ...
> Also, don't forget about quality. Sun put a serious amount of money and
> manpower into ensuring the quality and compatibility of the JVM. A lot of
> corporations depend on this. They have a regular update release cycle. For
> instance we are currently working on 1.3.1_16, 1.4.2_09, 5.0_04 & 5.0_05.
Sorry for poking on this but I want to shatter your believe in "serious
amount of money and manpower" a bit:
http://java.sun.com/j2se/1.5.0/docs/api/java/awt/BasicStroke.html#feedConsumer(sun.dc.path.PathConsumer,%20java.awt.geom.PathIterator)
Beware: We have more of these bloopers ;)
> Another worry I have is that the effort here might be better redirect to
> some other project.
This is an often heard suggestion but IMHO it simply does not work this
way: People here have not gathered because they have too much time or
find no place to put their work resources to. The fine people from
Apache met to implement J2SE5 and nothing else.
> We already have Java.
People have various reasons for their commitment. Since I am a GNU
Classpath developer with a strong stance for software freedom you can
guess mine. ;)
> Even if harmony does make it to a
> useable release people will still prefer to use the Sun VM. It will be the
> platform people build on and it will be the one they trust.
I for myself have no problem with Sun's VM being used by the majority.
Again I think people here will do this project for the fun/joy/... of it
not neccessarily because they dream of world domination. (= intrinsic
motivation) :)
I want to jump at the chance to send my kindest regards to my fellow
hackers from the Apache community: Thanks for getting together - this
cooperation will rock!
cu
Robert
[0] - http://sources.redhat.com/mauve/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCgqPjG9cfwmwwEtoRAo9kAJ9Y4F3a8EVo950ejekwMZiQccVM2wCfbftR
xvE8VWzDfBuCuEWLrm7sINo=
=PEZj
-----END PGP SIGNATURE-----
Re: Backward compatibility
Posted by Dmitry Serebrennikov <dm...@earthlink.net>.
I thinking you worry too much :) Maybe Sun is just making it all too
complicated ;)
If nothing else, perhaps with some competition Sun will finally start
fixing all those bugs in the bugparade that have been there for years
and years (like flaky filesystem operations, weird out of memory errors,
and the like). Just take a look how Microsoft has gotten off their ass
once Linux has really became popular. VM can't be that much more
complicated than an operating system, can it?
-dmitry
Gerry Steele wrote:
>I'm a big fan of the Apache foundation but this is one product I'm not too
>sure is such a good idea as of yet for reasons several:
>
>
>
>>>Deprecated or non deprecated, we want Harmony to pass the TCK, so
>>>
>>>
>>>>whatever the TCK wants us to do, we'll do it.
>>>>
>>>>
>
>
>I hope you understand what sticking to the TCK entails. When it comes to
>implementing GUI stuff for instance, your platform will have to fully copy
>the official JVM's Swing/AWT widgets and all other details in order for the
>automation and robot driven tests to pass. The JCK testbase for tiger is
>immense. To get it setup and run is a skill on its own. To get it to pass
>all tests takes a serious am mount of tweaking and a noteable knowledge of
>the javatest harness. It will require implementations on things as extensive
>as CORBA and RMI. We would need passive agents, tname servers etc.
>
>Also, when running the TCK bear in mind that you'll have to run the harness
>with the Sun VM.
>
>I'm not sure about the particular extent of the testsuite provided with the
>TCK you guys are talking about (if there is interest can find out more), but
>the JCK, which is basically a TCK for the entire J2SE jre and jdk will be
>going on impossible to pass for an alternative implmentation as everything
>is written with the Sun JDK/JRE in mind and test cases are adapted in ways
>that will create an infinite unpredictable series of problems when trying to
>adapt your code.
>
>Another reason is that I'm not quite sure I see the point. It will take 4-5
>years or more to even come close to a product like tiger. Sun are already
>working heavily on mustang and dolphin (to a lesser degree on the latter).
>As well as this, sun research have many projects looking at the future of
>the Java VM such as the Barcelona project which will drastically change the
>implementation of the JVM. For instance to make it more network orientated
>or to improve resource sharing.
>
>The latter things (which are yet to see real sun implementation) might be
>something you guys might then want to take advantage of in order to leverage
>a selling point of Harmony. Without something like that it's just another
>attempt at a VM that will be playing catch-up forever.
>
>Also, don't forget about quality. Sun put a serious amount of money and
>manpower into ensuring the quality and compatibility of the JVM. A lot of
>corporations depend on this. They have a regular update release cycle. For
>instance we are currently working on 1.3.1_16, 1.4.2_09, 5.0_04 & 5.0_05.
>
>In a project of this size some of the the test suites take several days to
>run. Some take many many hours of man power. For excessive thoroughness
>there also manual JCK and regression test suites. Which, trust me, will not
>be performed by someone who isn't being paid for it. Things like this don't
>fit well with the community model.
>
>Another worry I have is that the effort here might be better redirect to
>some other project. We already have Java. Even if harmony does make it to a
>useable release people will still prefer to use the Sun VM. It will be the
>platform people build on and it will be the one they trust.
>
>I'll be very interested in how this turns out.
>
>Regards,
>Gerry
>
>1) speed
>
>
>>2) portability (java is claimed to run 'everywhere', but in fact, it
>>runs only on a few operating systems, even fewer for 1.5)
>>
>>3) configurability (I might want to tune it differently and, for
>>example, choose different thread/GC models)
>>
>>4) implementation stategy (in macosx, multiple JVMs share 80% of their
>>memory, and some of Swing is native, therefore feels like the rest of
>>the OS and it's hardware accelerated)
>>
>>5) internal modularity (we want diversity of implementation to drive
>>innovation in the VM space, both in and out companies and universities)
>>
>>And, last but not least, if Sun or other vendors that already have JVM
>>want to stop paying for all that development on their and want to start
>>sharing the development costs with the java ecosystem in general and
>>with a clear warranty that we will not try to pollute the stream we all
>>drink from, therefore want to contribute some of their code to Harmony,
>>we will welcome them with open arms.
>>
>>--
>>Stefano.
>>
>>
>>
>>
>
>
>
>
Re: Backward compatibility
Posted by Gerry Steele <ge...@gmail.com>.
I'm a big fan of the Apache foundation but this is one product I'm not too
sure is such a good idea as of yet for reasons several:
>> Deprecated or non deprecated, we want Harmony to pass the TCK, so
> >> whatever the TCK wants us to do, we'll do it.
I hope you understand what sticking to the TCK entails. When it comes to
implementing GUI stuff for instance, your platform will have to fully copy
the official JVM's Swing/AWT widgets and all other details in order for the
automation and robot driven tests to pass. The JCK testbase for tiger is
immense. To get it setup and run is a skill on its own. To get it to pass
all tests takes a serious am mount of tweaking and a noteable knowledge of
the javatest harness. It will require implementations on things as extensive
as CORBA and RMI. We would need passive agents, tname servers etc.
Also, when running the TCK bear in mind that you'll have to run the harness
with the Sun VM.
I'm not sure about the particular extent of the testsuite provided with the
TCK you guys are talking about (if there is interest can find out more), but
the JCK, which is basically a TCK for the entire J2SE jre and jdk will be
going on impossible to pass for an alternative implmentation as everything
is written with the Sun JDK/JRE in mind and test cases are adapted in ways
that will create an infinite unpredictable series of problems when trying to
adapt your code.
Another reason is that I'm not quite sure I see the point. It will take 4-5
years or more to even come close to a product like tiger. Sun are already
working heavily on mustang and dolphin (to a lesser degree on the latter).
As well as this, sun research have many projects looking at the future of
the Java VM such as the Barcelona project which will drastically change the
implementation of the JVM. For instance to make it more network orientated
or to improve resource sharing.
The latter things (which are yet to see real sun implementation) might be
something you guys might then want to take advantage of in order to leverage
a selling point of Harmony. Without something like that it's just another
attempt at a VM that will be playing catch-up forever.
Also, don't forget about quality. Sun put a serious amount of money and
manpower into ensuring the quality and compatibility of the JVM. A lot of
corporations depend on this. They have a regular update release cycle. For
instance we are currently working on 1.3.1_16, 1.4.2_09, 5.0_04 & 5.0_05.
In a project of this size some of the the test suites take several days to
run. Some take many many hours of man power. For excessive thoroughness
there also manual JCK and regression test suites. Which, trust me, will not
be performed by someone who isn't being paid for it. Things like this don't
fit well with the community model.
Another worry I have is that the effort here might be better redirect to
some other project. We already have Java. Even if harmony does make it to a
useable release people will still prefer to use the Sun VM. It will be the
platform people build on and it will be the one they trust.
I'll be very interested in how this turns out.
Regards,
Gerry
1) speed
>
> 2) portability (java is claimed to run 'everywhere', but in fact, it
> runs only on a few operating systems, even fewer for 1.5)
>
> 3) configurability (I might want to tune it differently and, for
> example, choose different thread/GC models)
>
> 4) implementation stategy (in macosx, multiple JVMs share 80% of their
> memory, and some of Swing is native, therefore feels like the rest of
> the OS and it's hardware accelerated)
>
> 5) internal modularity (we want diversity of implementation to drive
> innovation in the VM space, both in and out companies and universities)
>
> And, last but not least, if Sun or other vendors that already have JVM
> want to stop paying for all that development on their and want to start
> sharing the development costs with the java ecosystem in general and
> with a clear warranty that we will not try to pollute the stream we all
> drink from, therefore want to contribute some of their code to Harmony,
> we will welcome them with open arms.
>
> --
> Stefano.
>
>
--
Gerry Steele
x74521/+353-1-8199 521
http://blogs.sun.com/roller/page/gerrys
[gerry.steele@sun.com OR gerry.steele@gmail.com]
Re: Backward compatibility
Posted by Stefano Mazzocchi <st...@apache.org>.
Doug Hall wrote:
>
> On May 11, 2005, at 11:45 AM, Stefano Mazzocchi wrote:
>
>> Deprecated or non deprecated, we want Harmony to pass the TCK, so
>> whatever the TCK wants us to do, we'll do it.
>
>
> So what's the point? If all you're trying to do is duplicate J2SE 5,
> what advantage is there to making it an open source project? As soon as
> you "improve" something, aren't you're likely to break the API?
>
> Is this really an attempt to get Sun to open source Java?
>
> I'm not trying to be critical or anything. Just wondering what's the point?
The TCK tests the 'functionality' of the underlying JVM, not things like:
1) speed
2) portability (java is claimed to run 'everywhere', but in fact, it
runs only on a few operating systems, even fewer for 1.5)
3) configurability (I might want to tune it differently and, for
example, choose different thread/GC models)
4) implementation stategy (in macosx, multiple JVMs share 80% of their
memory, and some of Swing is native, therefore feels like the rest of
the OS and it's hardware accelerated)
5) internal modularity (we want diversity of implementation to drive
innovation in the VM space, both in and out companies and universities)
And, last but not least, if Sun or other vendors that already have JVM
want to stop paying for all that development on their and want to start
sharing the development costs with the java ecosystem in general and
with a clear warranty that we will not try to pollute the stream we all
drink from, therefore want to contribute some of their code to Harmony,
we will welcome them with open arms.
--
Stefano.
Re: Backward compatibility
Posted by Doug Hall <do...@gmail.com>.
On May 11, 2005, at 11:45 AM, Stefano Mazzocchi wrote:
> Deprecated or non deprecated, we want Harmony to pass the TCK, so
> whatever the TCK wants us to do, we'll do it.
So what's the point? If all you're trying to do is duplicate J2SE 5,
what advantage is there to making it an open source project? As soon as
you "improve" something, aren't you're likely to break the API?
Is this really an attempt to get Sun to open source Java?
I'm not trying to be critical or anything. Just wondering what's the
point?
Doug
Re: Backward compatibility
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 11, 2005, at 12:45 PM, Stefano Mazzocchi wrote:
> Doug Hall wrote:
>
>> Forgive a newbie, but if Harmony passes, would there be an effort
>> to write the deprecated code? Personally, I would hope not - at
>> least not initially. But wouldn't it need to include them to pass
>> compatibility tests (TCK), or do these tests only test the current
>> API?
>>
>
> Deprecated or non deprecated, we want Harmony to pass the TCK, so
> whatever the TCK wants us to do, we'll do it.
Yes - to chime in here, we don't just want to squeak by. We want to
be just as good as anything else. We may optimize the deprecated
APIs later, but we won't avoid doing them - J2SE users expect to have
those APIs in an implementation that calls itself Java, and so we
shall :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Backward compatibility
Posted by Stefano Mazzocchi <st...@apache.org>.
Doug Hall wrote:
> Forgive a newbie, but if Harmony passes, would there be an effort to
> write the deprecated code? Personally, I would hope not - at least not
> initially. But wouldn't it need to include them to pass compatibility
> tests (TCK), or do these tests only test the current API?
Deprecated or non deprecated, we want Harmony to pass the TCK, so
whatever the TCK wants us to do, we'll do it.
--
Stefano.