You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/02/02 15:36:48 UTC
[vote] Acceptance of HARMONY-39 : Contribution of beans, regex and
math class library code
I have received the ACQs and the BCC for Harmony-39, so I can assert
that the critical provenance paperwork is in order (although not in SVN
yet).
Please vote to accept or reject this codebase into the Apache Harmony
class library :
[ ] + 1 Accept
[ ] -1 Reject (provide reason below
Lets let this run 3 days unless a) someone states they need more time or
b) we get all committer votes before then.
Go...
geir
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Dalibor Topic wrote:
> On Tue, Mar 21, 2006 at 02:48:25PM -0300, Fernando Cassia wrote:
>> On 3/21/06, Dalibor Topic <ro...@kaffe.org> wrote:
>>>
>>>
>>> Java is so depressingly backwards. We're solving problems over and
>>> over again that would not be problems in the first place if Java was
>>> managed competently, by people who have a clue about involving
>>> communities, and placed the platform before their business interests.
>>>
>>> cheers,
>>> dalibor topic
>>
>> Can you please stop with the Sun bashing?. Sun has specifically allowed you
>> among others to create a cleanroom implementation of their JVM. In fact they
>> did change the legalese allowing that to happen.
>
> That's a slightly uninformed assertion.
>
> Sun changed their legalese to make it possible to certify
> a cleanroom implementation of J2SE as compatible, a little while ago.
Well, because Apache primarily (and others) pushed to have the JCP changed.
>
> Implementing the specs by writing open source VMs has been done since
> 1996, and needed no specific blessing.
That's debatable. Of course, Sun had some strange, untested-in-court
ideas about how to protect the specs, but still - there's room for
debate here.
>
> Certification of compatibility is not the same thing as the right to
> implement. The former is something Sun can grant, the latter is not for Sun
> to decide.
Again, room for debate...
>
>> If you dislike Java so much, you're free to go to the Mono camp and start
>> chasing the MSFT train....
>>
>
> No, I like Java, so I won't be switching camps. It is possible
> to be disappointed with Sun's management of the platform without disliking the
> language. I dare say that there would be no business interest for
> companies to get involed with projects like this one if everything was
> peachy, and if Java wouldn't dearly need better leadership.
>
>> Thanks to the Sun "business interests", Microsoft wasn't succesfull in
>> "derailing" java and polluting it with Win32 api calls and all that crap,
>> like they originally intended to do with J++....
>
> I'm not sure if you are aware of it, but J# (what J++ is called now),
> still exists. With Sun's blessing, since the Microsoft settlement. It
> also includes all that Win32 specific mess. You can download your 'free'
> copy of Visual Studio Express 2005 for J# from Microsoft.
>
> cheers,
> dalibor topic
>
>> FC
>
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Dalibor Topic <ro...@kaffe.org>.
On Tue, Mar 21, 2006 at 02:48:25PM -0300, Fernando Cassia wrote:
> On 3/21/06, Dalibor Topic <ro...@kaffe.org> wrote:
> >
> >
> >
> > Java is so depressingly backwards. We're solving problems over and
> > over again that would not be problems in the first place if Java was
> > managed competently, by people who have a clue about involving
> > communities, and placed the platform before their business interests.
> >
> > cheers,
> > dalibor topic
>
>
> Can you please stop with the Sun bashing?. Sun has specifically allowed you
> among others to create a cleanroom implementation of their JVM. In fact they
> did change the legalese allowing that to happen.
That's a slightly uninformed assertion.
Sun changed their legalese to make it possible to certify
a cleanroom implementation of J2SE as compatible, a little while ago.
Implementing the specs by writing open source VMs has been done since
1996, and needed no specific blessing.
Certification of compatibility is not the same thing as the right to
implement. The former is something Sun can grant, the latter is not for Sun
to decide.
>
> If you dislike Java so much, you're free to go to the Mono camp and start
> chasing the MSFT train....
>
No, I like Java, so I won't be switching camps. It is possible
to be disappointed with Sun's management of the platform without disliking the
language. I dare say that there would be no business interest for
companies to get involed with projects like this one if everything was
peachy, and if Java wouldn't dearly need better leadership.
> Thanks to the Sun "business interests", Microsoft wasn't succesfull in
> "derailing" java and polluting it with Win32 api calls and all that crap,
> like they originally intended to do with J++....
I'm not sure if you are aware of it, but J# (what J++ is called now),
still exists. With Sun's blessing, since the Microsoft settlement. It
also includes all that Win32 specific mess. You can download your 'free'
copy of Visual Studio Express 2005 for J# from Microsoft.
cheers,
dalibor topic
> FC
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Fernando Cassia <fe...@gmail.com>.
On 3/21/06, Dalibor Topic <ro...@kaffe.org> wrote:
>
>
>
> Java is so depressingly backwards. We're solving problems over and
> over again that would not be problems in the first place if Java was
> managed competently, by people who have a clue about involving
> communities, and placed the platform before their business interests.
>
> cheers,
> dalibor topic
Can you please stop with the Sun bashing?. Sun has specifically allowed you
among others to create a cleanroom implementation of their JVM. In fact they
did change the legalese allowing that to happen.
If you dislike Java so much, you're free to go to the Mono camp and start
chasing the MSFT train....
Thanks to the Sun "business interests", Microsoft wasn't succesfull in
"derailing" java and polluting it with Win32 api calls and all that crap,
like they originally intended to do with J++....
FC
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Dalibor Topic <ro...@kaffe.org>.
On Tue, Mar 21, 2006 at 04:17:26PM +0100, Chris Gray wrote:
> On Tuesday 21 March 2006 15:53, Dalibor Topic wrote:
>
> > But alas, Sun currently sees other implementations as a threat to its
> > business model as a proprietary Java vendor, so one has to deal with
> > such things until they stop having a business interest in being a
> > proprietary Java vendor (yeah, right), or go bust (yeah, right), or
> > actually makes true on the 'participation age' and 'JDK community' talk
> > (yeah, right).
>
> Yeah, right +1 :-0
>
> There are quite a few people within Sun who think that what we (Harmony,
> Kaffe, SableVM, Wonka, ...) are doing is cool - well, I've met a couple
> anyway. But once things start to get "official", you're talking to another
> brick in the wall ...
Unfortunately, the bright engineering people at Sun aren't the ones that
run the Java show.
Java is so depressingly backwards. We're solving problems over and
over again that would not be problems in the first place if Java was
managed competently, by people who have a clue about involving
communities, and placed the platform before their business interests.
cheers,
dalibor topic
>
> (mother did it need to be so high?)
>
> --
> Chris Gray /k/ Embedded Java Solutions BE0503765045
> Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
> chris.gray@kiffer.be +32 3 216 0369
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Chris Gray <ch...@kiffer.be>.
On Tuesday 21 March 2006 15:53, Dalibor Topic wrote:
> But alas, Sun currently sees other implementations as a threat to its
> business model as a proprietary Java vendor, so one has to deal with
> such things until they stop having a business interest in being a
> proprietary Java vendor (yeah, right), or go bust (yeah, right), or
> actually makes true on the 'participation age' and 'JDK community' talk
> (yeah, right).
Yeah, right +1 :-0
There are quite a few people within Sun who think that what we (Harmony,
Kaffe, SableVM, Wonka, ...) are doing is cool - well, I've met a couple
anyway. But once things start to get "official", you're talking to another
brick in the wall ...
(mother did it need to be so high?)
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Anton Avtamonov <an...@gmail.com>.
On 3/22/06, Mikhail Loenko <ml...@gmail.com> wrote:
> As I understood the main Tim's concern with running tests in bootclasspath is
> that real apps wont run that way.
>
> If we test in special VM mode then we go far away from how real apps
> are running.
Agree.
Besides, VM will have to be even more complicated and (most likely) a
bit slowly.
--
Anton Avtamonov,
Intel Middleware Products Division
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Mikhail Loenko <ml...@gmail.com>.
As I understood the main Tim's concern with running tests in bootclasspath is
that real apps wont run that way.
If we test in special VM mode then we go far away from how real apps
are running.
$0.02
Thanks,
Mikhail
2006/3/22, Etienne Gagnon <eg...@sablevm.org>:
> Just a random idea... Why not have a special "testing" mode in the VM
> that would trigger special permissions to code in ".test" packages?
>
> Actually, this mechanism could act differently: simply consider
> some.package and some.package.test as being the *same* package (so,
> erase, at loading time, the .test package suffix from loaded classes.
> It could also "combine" the fields & methods of package.Foo with
> package.test.Foo if classes with identical names exist in both packages,
> so that private methods could be tested.
>
> Additionally, the testing mode could allow for loading java.lang.*
> classes in user class loaders.
>
> Of course, this would be a non-standard option, like -Xtestpermissions .
> And, this way, all the test code could reside in files and directories
> that would be separate from the real code.
>
> Yep, a random idea. ;-)
>
> Etienne
>
> Geir Magnusson Jr wrote:
> > testing a.b.c.Foo and you have to do it from a.b.c.test.FooTest, how can
> > you ever do implementation testing of Foo? It's not an unreasonable
> >...
>
> --
> Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
> SableVM: http://www.sablevm.org/
> SableCC: http://www.sablecc.org/
>
>
>
Re: [OT] Re: Unit testing revisited
Posted by Stepan Mishura <st...@gmail.com>.
On 3/22/06, Geir Magnusson Jr wrote:
>
>
>
> Leo Simons wrote:
> > On Wed, Mar 22, 2006 at 07:34:16AM -0500, Geir Magnusson Jr wrote:
> >>> LEO :
> >>> I'll point out that every time you restrict to an ordered sequence of
> >>> taking care of things in an open souce community you do slow them down
> just
> >>> a little (hey, that's an interesting assertion. Hmm. Should write a
> book
> >>> about it I guess) so make sure its what you want :-).
> >> Huh?
> >
> > You didn't say "let us test the code in isolation [using a smart
> framework]",
> > you said "let us test the code in isolation *first* [using a smart
> > framework]". I need to write a book about why I think the difference
> > matters, and it needs to be a book because I'll need many many words...
>
> Oh - no, I didn't mean that. Sorry. All three are independent. You can
> do them in parallel. We can build our mechanism to do the
> implementation tests correctly while we continue to do everything else.
>
> I just wanted to see if I could get through the fog and be clear what
> the issues are and stop confusing #1 and #2, both of which are important.
>
> To test java.util.Foo, I believe it's important to have BOTH
>
> java.util.FooTest
>
> AND
>
> org.apache.harmony.test.java.util.FooTest
>
> as they are intended to test different things (the first as a
> 'un-integrated' implementation test and the second as an 'in-situ'
> API/spec test).
Yes, indeed. We should admit that we need both tests rather then arguing
which test is the right.
Thanks,
Stepan.
If we agree on that and recognize that, I suspect the test debates will
> come to rapid closure, and we'll have a mini-roadmap of what we want to
> do in the testing area that is parallelizable and doesn't hold anyone up.
>
> geir
>
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: [OT] Re: Unit testing revisited
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Leo Simons wrote:
> On Wed, Mar 22, 2006 at 07:34:16AM -0500, Geir Magnusson Jr wrote:
>>> LEO :
>>> I'll point out that every time you restrict to an ordered sequence of
>>> taking care of things in an open souce community you do slow them down just
>>> a little (hey, that's an interesting assertion. Hmm. Should write a book
>>> about it I guess) so make sure its what you want :-).
>> Huh?
>
> You didn't say "let us test the code in isolation [using a smart framework]",
> you said "let us test the code in isolation *first* [using a smart
> framework]". I need to write a book about why I think the difference
> matters, and it needs to be a book because I'll need many many words...
Oh - no, I didn't mean that. Sorry. All three are independent. You can
do them in parallel. We can build our mechanism to do the
implementation tests correctly while we continue to do everything else.
I just wanted to see if I could get through the fog and be clear what
the issues are and stop confusing #1 and #2, both of which are important.
To test java.util.Foo, I believe it's important to have BOTH
java.util.FooTest
AND
org.apache.harmony.test.java.util.FooTest
as they are intended to test different things (the first as a
'un-integrated' implementation test and the second as an 'in-situ'
API/spec test).
If we agree on that and recognize that, I suspect the test debates will
come to rapid closure, and we'll have a mini-roadmap of what we want to
do in the testing area that is parallelizable and doesn't hold anyone up.
geir
[OT] Re: Unit testing revisited
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Mar 22, 2006 at 07:34:16AM -0500, Geir Magnusson Jr wrote:
> >Heh. You find *those* by running the app server tests :-). I suspect that
> >running the J2EE TCK against geronimo running on harmony and comparing it
> >with running the J2EE TCK against geronimo running on the sun jdk is
> >going to be pretty insightful...
>
> Like a mortar attack is insightful. :)
LOL. There might be a building or two left standing, and we can give the
people that built those a standing ovation :-)
> It will be an interesting test of "The Algebra of TCK-ness"
>
> If A = Sun JDK passes Java SE TCK
> If B(A) = Geronimo passes Java EE TCK on compliant Sun JDK
> If C = Harmony JDK passes on Java SE TCK
>
> then it should be true that B(C). No need to test!
>
> :)
LOL. I think you've just proved the whole discussion is fruitless.
> >>Please point me to it! I always want to see new ways of doing this.
> >>Challenge away!
> >
> >Okay :-), top-of-head,
> >
> >http://svn.apache.org/repos/asf/excalibur/trunk/framework/impl/src/test/org/apache/avalon/framework/context/test/ContextTestCase.java
> >
> >(one of the last remaining bits of code that can be traced back to apache
> >jserv which was tested using testlet which was around before JUnit). In
> >general, the parts of jakarta and what grew out of it that are derivants of
> >the JServ branch of working (including avalon, now excalibur, cocoon) often
> >do thingsl ike this.
> >
> >The fact I typed that URL from memory and was right is kinda scary, isn't
> >it? I've not worked on that code for *years* and its moved a few dozen
> >times...
>
> That is scary. It's also scary that you proposed Avalon as an example :)
LOL. That project has some of the best frigging brilliant ideas in its
codebase, some of which most of the java world *still* hasn't figured out.
Ever heard of classloader hell? We /solved/ that, in 1999, before the J2EE
world knew it would become a problem (all the people at JBoss still haven't
figured it out and I hear Geronimo is having trouble too). I still view OSGi
as a broken committee-designed version of half of avalon. The core of the
code that makes apache cocoon go as fast as it goes lived in avalon and now
lives in excalibur. No-one hardly touches it but no-one needs to because its
as rock solid as, well, the JDK :-)
Quality of the code was never a problem with avalon. Another one of my
assertions is that as code quality approaches infinity the number of
people that can work on it together approaches 0. Lisp hackers don't even
try (you might spot a rephrased version of the "all code continuously evolves
to become like a broken version of Common Lisp", above), in avalon, we did...
...doesn't mean reading the code is a bad idea. Go read :-)
> >>So the problem boils down to the fact that we are implicitly doing
> >>integration testing. That's why I've been suggesting the framework -
> >>let us test the code in isolation first, using "implementation tests".
> >>Then, if our isolation framework is sexy enough, lets try to reproduce
> >>the same classloader/security model we would experience in a VM, and do
> >>spec/API testing. *Then* we can do integration testing by running the
> >>code in the VM ("in situ") and do the proper (aka (*.test.*) )
> >>spec/API/tck testing.
> >>
> >>I'll post this as a separate message because this one is way too woolly
> >>at this point.
> >
> >Okay, this does sound like "the core" of the matter. There you go.
> >
> >I'll point out that every time you restrict to an ordered sequence of
> >taking care of things in an open souce community you do slow them down just
> >a little (hey, that's an interesting assertion. Hmm. Should write a book
> >about it I guess) so make sure its what you want :-).
>
> Huh?
You didn't say "let us test the code in isolation [using a smart framework]",
you said "let us test the code in isolation *first* [using a smart
framework]". I need to write a book about why I think the difference
matters, and it needs to be a book because I'll need many many words...
LSD
Re: Unit testing revisited
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Leo Simons wrote:
> On Wed, Mar 22, 2006 at 06:41:56AM -0500, Geir Magnusson Jr wrote:
>>
[SNIP]
>> You forgot one - "integration test", which is a unit test that's been
>> around long enough to shave. :) (It's actually not a unit test...)
>
> "integration test" --> any test that is not an implementation test or
> specification test. Typically these test the interactions between
> multiple pieces rather than the correct behaviour of a single
> piece.
>
> I forgot another one:
>
> "gump run using harmony" --> the biggest frigging integration test you
> can think of. Tests the interaction between harmony and millions
> of lines of userland code.
"frigging integration test" --> A kind of integration test that
uses a "frig", or "functional rig". See
http://gump.apache.org/
:)
>
>>>>> We already see lots of errors caused by
>>>>> oversight of the classloader differences.
>>>> Right. And I think the solution is to think about this in some other
>>>> way than just running things in a VM, like a test harness that does the
>>>> right thing in terms of the classes being tested (what would be in the
>>>> boot classloader) and the classes doing the testing.
>>> I don't know about that. I'm sure that if the problem is well-defined
>>> enough solutions will become apparent, and I still don't quite get why it
>>> is the subject of continuous debate (eg can't someone just go out and try
>>> and do what you propose and show it works?).
>> The problem is 'completeness' because we have multiple problems to
>> solve.
>
> Uh-oh. Completeness is a scary word. I didn't see that coming.
>
> <snip a couple of hackiness details />
>> I think that both of these solutions are
>>
>> a) messy - since only XP psycho's really *enjoy* creating unit tests, we
>> want to make it as painless as possible as to not disincentivize
>> developers. Look at what we have so far. IBM had to go off to the Unit
>> Test Mines they run in a Secret Undisclosed Location in the Principality
>> of BigBlueLand to provide unit tests for stuff they had already donated!
>> :) [Thanks, btw]
>
> The class library design is messy. Testing it will, one way or another, be
> a messy subject.
>
>> b) subject to "mechanical failure" - we're doing all sorts of unnatural
>> acts on code that is usually the "rock solid" basis for doing these
>> unnatural things to other code (like in app servers), and I worry that
>> such complexity will lead to very hard or impossible to find failures or
>> bugs
>
> Heh. You find *those* by running the app server tests :-). I suspect that
> running the J2EE TCK against geronimo running on harmony and comparing it
> with running the J2EE TCK against geronimo running on the sun jdk is
> going to be pretty insightful...
Like a mortar attack is insightful. :)
It will be an interesting test of "The Algebra of TCK-ness"
If A = Sun JDK passes Java SE TCK
If B(A) = Geronimo passes Java EE TCK on compliant Sun JDK
If C = Harmony JDK passes on Java SE TCK
then it should be true that B(C). No need to test!
:)
>
>>> There is also the possibility that all the package-private materials in
>>> reality are fully exercised if you test the public parts of the package
>>> thoroughly enough. A coverage utility like clover can show that. XP
>>> (extreme programming) purists (like me) might argue that if you have
>>> package-private stuff that is not exerciseable through the public API
>>> that the package-private stuff needs to be factored out. But lets try not
>>> to argue too much :-)
>> I agree with the latter part. What I worry about though is that despite
>> the best of intentions, unit testing tends not to ever be complete and
>> thorough. I don't know if things like clover indicate the quality of
>> the coverage - but simply having coverage just isn't enough, IMO, as you
>> may not exercise completely enough so that all internal functionality is
>> directly exercised. Dunno.
>
> You've never had the pleasure of being part of a project that was fully
> XP-run from the start, have you? Its not a pipe dream but its also not
> likely to be attainable for harmony (if we want to get anything running
> before 2020).
No, I haven't. I don't think you could do Jave SE as XP because design
and planning is needed :)
>
>>>>>> I
>>>>>> couldn't imagine that the Eclipse tests don't test package protected
>>>>>> things.
>>>>> The only thing shared with Eclipse-land here is the *.tests.* package
>>>>> name element, hardly significant or unique I expect.
>>>> Well, it is around here. While I haven't done a survey, I'm used to
>>>> projects keeping things in parallel trees to make it easy to test.
>>> If with "here" you mean "the ASF" I'm happy to challenge the assertion :-)
>> Please point me to it! I always want to see new ways of doing this.
>> Challenge away!
>
> Okay :-), top-of-head,
>
> http://svn.apache.org/repos/asf/excalibur/trunk/framework/impl/src/test/org/apache/avalon/framework/context/test/ContextTestCase.java
>
> (one of the last remaining bits of code that can be traced back to apache
> jserv which was tested using testlet which was around before JUnit). In
> general, the parts of jakarta and what grew out of it that are derivants of
> the JServ branch of working (including avalon, now excalibur, cocoon) often
> do thingsl ike this.
>
> The fact I typed that URL from memory and was right is kinda scary, isn't
> it? I've not worked on that code for *years* and its moved a few dozen
> times...
That is scary. It's also scary that you proposed Avalon as an example :)
>
>> So the problem boils down to the fact that we are implicitly doing
>> integration testing. That's why I've been suggesting the framework -
>> let us test the code in isolation first, using "implementation tests".
>> Then, if our isolation framework is sexy enough, lets try to reproduce
>> the same classloader/security model we would experience in a VM, and do
>> spec/API testing. *Then* we can do integration testing by running the
>> code in the VM ("in situ") and do the proper (aka (*.test.*) )
>> spec/API/tck testing.
>>
>> I'll post this as a separate message because this one is way too woolly
>> at this point.
>
> Okay, this does sound like "the core" of the matter. There you go.
>
> I'll point out that every time you restrict to an ordered sequence of
> taking care of things in an open souce community you do slow them down just
> a little (hey, that's an interesting assertion. Hmm. Should write a book
> about it I guess) so make sure its what you want :-).
Huh?
geir
Re: Unit testing revisited
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Mar 22, 2006 at 06:41:56AM -0500, Geir Magnusson Jr wrote:
> >Eg I would suggest that we bite the bullet and go something like this:
> >
> > "unit test" --> any test runnable by a "unit testing framework" such as
> > JUnit or Cactus.
> >
> > "implementation test" --> a test run to verify that a specific piece
> > of code, preferably as small a piece as is seperately
> > testable, behaves as expected.
> >
> > "specification test" --> a test run to verify that an implementation is
> > conformant with some specification, prefereably as small a piece
> > of the specification for which a test can be defined.
> >
> > "API test" --> a specification test where the specification takes the
> > form of an API definition (perhaps a java interface with
> > supporting javadocs, perhaps just javadocs, perhaps IDL...)
> >
> > "tck test" --> any test defined as part of something that is called a
> > "TCK" or technology compatibility kit. TCK tests are
> > supposed to be specification tests.
>
> You forgot one - "integration test", which is a unit test that's been
> around long enough to shave. :) (It's actually not a unit test...)
"integration test" --> any test that is not an implementation test or
specification test. Typically these test the interactions between
multiple pieces rather than the correct behaviour of a single
piece.
I forgot another one:
"gump run using harmony" --> the biggest frigging integration test you
can think of. Tests the interaction between harmony and millions
of lines of userland code.
> >>>We already see lots of errors caused by
> >>>oversight of the classloader differences.
> >>Right. And I think the solution is to think about this in some other
> >>way than just running things in a VM, like a test harness that does the
> >>right thing in terms of the classes being tested (what would be in the
> >>boot classloader) and the classes doing the testing.
> >
> >I don't know about that. I'm sure that if the problem is well-defined
> >enough solutions will become apparent, and I still don't quite get why it
> >is the subject of continuous debate (eg can't someone just go out and try
> >and do what you propose and show it works?).
>
> The problem is 'completeness' because we have multiple problems to
> solve.
Uh-oh. Completeness is a scary word. I didn't see that coming.
<snip a couple of hackiness details />
> I think that both of these solutions are
>
> a) messy - since only XP psycho's really *enjoy* creating unit tests, we
> want to make it as painless as possible as to not disincentivize
> developers. Look at what we have so far. IBM had to go off to the Unit
> Test Mines they run in a Secret Undisclosed Location in the Principality
> of BigBlueLand to provide unit tests for stuff they had already donated!
> :) [Thanks, btw]
The class library design is messy. Testing it will, one way or another, be
a messy subject.
> b) subject to "mechanical failure" - we're doing all sorts of unnatural
> acts on code that is usually the "rock solid" basis for doing these
> unnatural things to other code (like in app servers), and I worry that
> such complexity will lead to very hard or impossible to find failures or
> bugs
Heh. You find *those* by running the app server tests :-). I suspect that
running the J2EE TCK against geronimo running on harmony and comparing it
with running the J2EE TCK against geronimo running on the sun jdk is
going to be pretty insightful...
> >There is also the possibility that all the package-private materials in
> >reality are fully exercised if you test the public parts of the package
> >thoroughly enough. A coverage utility like clover can show that. XP
> >(extreme programming) purists (like me) might argue that if you have
> >package-private stuff that is not exerciseable through the public API
> >that the package-private stuff needs to be factored out. But lets try not
> >to argue too much :-)
>
> I agree with the latter part. What I worry about though is that despite
> the best of intentions, unit testing tends not to ever be complete and
> thorough. I don't know if things like clover indicate the quality of
> the coverage - but simply having coverage just isn't enough, IMO, as you
> may not exercise completely enough so that all internal functionality is
> directly exercised. Dunno.
You've never had the pleasure of being part of a project that was fully
XP-run from the start, have you? Its not a pipe dream but its also not
likely to be attainable for harmony (if we want to get anything running
before 2020).
> >>>>I
> >>>>couldn't imagine that the Eclipse tests don't test package protected
> >>>>things.
> >>>The only thing shared with Eclipse-land here is the *.tests.* package
> >>>name element, hardly significant or unique I expect.
> >>Well, it is around here. While I haven't done a survey, I'm used to
> >>projects keeping things in parallel trees to make it easy to test.
> >
> >If with "here" you mean "the ASF" I'm happy to challenge the assertion :-)
>
> Please point me to it! I always want to see new ways of doing this.
> Challenge away!
Okay :-), top-of-head,
http://svn.apache.org/repos/asf/excalibur/trunk/framework/impl/src/test/org/apache/avalon/framework/context/test/ContextTestCase.java
(one of the last remaining bits of code that can be traced back to apache
jserv which was tested using testlet which was around before JUnit). In
general, the parts of jakarta and what grew out of it that are derivants of
the JServ branch of working (including avalon, now excalibur, cocoon) often
do thingsl ike this.
The fact I typed that URL from memory and was right is kinda scary, isn't
it? I've not worked on that code for *years* and its moved a few dozen
times...
> So the problem boils down to the fact that we are implicitly doing
> integration testing. That's why I've been suggesting the framework -
> let us test the code in isolation first, using "implementation tests".
> Then, if our isolation framework is sexy enough, lets try to reproduce
> the same classloader/security model we would experience in a VM, and do
> spec/API testing. *Then* we can do integration testing by running the
> code in the VM ("in situ") and do the proper (aka (*.test.*) )
> spec/API/tck testing.
>
> I'll post this as a separate message because this one is way too woolly
> at this point.
Okay, this does sound like "the core" of the matter. There you go.
I'll point out that every time you restrict to an ordered sequence of
taking care of things in an open souce community you do slow them down just
a little (hey, that's an interesting assertion. Hmm. Should write a book
about it I guess) so make sure its what you want :-).
LSD
Re: Unit testing revisited
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Leo Simons wrote:
> Just two cents (or a little more) from the peanut gallery...
>
> On Tue, Mar 21, 2006 at 10:45:42PM -0500, Geir Magnusson Jr wrote:
>> Tim Ellison wrote:
>>> Just to clarify terminology -- unit tests are a 'style' of test that
>>> focus on particular units of functionality. Unit tests can be both
>>> implementation tests and API tests. Implementation tests are specific
>>> to our implementation (the mechanism, hidden to the end user, by which
>>> we chose to implement the APIs); and API tests are common to all
>>> conformant implementations (they test the APIs used by the end user).
>> So can we refer to "implementation tests" as "unit tests", because I
>> would bet that's a well-understood useage, and refer to things that are
>> strictly testing the API as "API tests".
>
> Thinking more about all this verbiage, and looking at a bunch of "unit
> tests" in many apache packages, I think the definitions are inherently
> too vague to get consensus on. It comes down to "what is a unit", and
> this is an age-old discussion (see: metric system vs inches) we should
> not try and have.
>
> It gets us into arguments like "that is not a proper unit test". 'Why
> not?' "The unit is too big." 'Well, our units are just bigger than yours,
> you silly Brits!' "Why you little...!"
>
> So I will suggest we don't go and try to define "unit test" and stop using
> the phrase when we want to make distinctions between stuff.
>
> Eg I would suggest that we bite the bullet and go something like this:
>
> "unit test" --> any test runnable by a "unit testing framework" such as
> JUnit or Cactus.
>
> "implementation test" --> a test run to verify that a specific piece
> of code, preferably as small a piece as is seperately
> testable, behaves as expected.
>
> "specification test" --> a test run to verify that an implementation is
> conformant with some specification, prefereably as small a piece
> of the specification for which a test can be defined.
>
> "API test" --> a specification test where the specification takes the
> form of an API definition (perhaps a java interface with
> supporting javadocs, perhaps just javadocs, perhaps IDL...)
>
> "tck test" --> any test defined as part of something that is called a
> "TCK" or technology compatibility kit. TCK tests are
> supposed to be specification tests.
>
You forgot one - "integration test", which is a unit test that's been
around long enough to shave. :) (It's actually not a unit test...)
These definitions are fine. The key is to separate out "implementation"
from spec/API, IMO.
>>> Geir Magnusson Jr wrote:
>>>> Good unit tests are going to be testing things that are package
>>>> protected. You can't do that if you aren't in the same package
>>>> (obviously).
>>> We have implementation tests that require package private, and maybe
>>> even private access to our implementation classes both in the java.* and
>>> o.a.h.* packages.
>
> This seems correct.
>
>>> The 'problem' is that we cannot define classes in java.* packages that
>>> are loaded by the application classloader. That is counter to
>>> specification and prohibited by the VM.
>>>
>>> We also have API tests that should not have access to package private
>>> and even private types in the implementation.
>
> This seems correct too.
>
>>> The 'problem' is that running API tests in java.* packages does provide
>>> such access, and worse runs those tests on the bootclassloader which
>>> gives them special security access not afforded to our users.
>
> This makes sense.
>
>>> I've said this lots of times before.
>
> Usually that means one is not coming across well, not that people aren't
> trying to listen or anything like that :-)
>
>>> We already see lots of errors caused by
>>> oversight of the classloader differences.
>> Right. And I think the solution is to think about this in some other
>> way than just running things in a VM, like a test harness that does the
>> right thing in terms of the classes being tested (what would be in the
>> boot classloader) and the classes doing the testing.
>
> I don't know about that. I'm sure that if the problem is well-defined
> enough solutions will become apparent, and I still don't quite get why it
> is the subject of continuous debate (eg can't someone just go out and try
> and do what you propose and show it works?).
The problem is 'completeness' because we have multiple problems to
solve. The .test.* solution works - it gets the test off the boot
classpath (and associated namespaces) so the API tests can function
properly - in the right security context, namely the same as user code.
>
>>>> With the "custom" of putting in things in o.a.h.t are we
>>>> implicitly discouraging good testing practice?
>>> This is laughable.
>> You are going to have to explain why it's "laughable". If you are
>> testing a.b.c.Foo and you have to do it from a.b.c.test.FooTest, how can
>> you ever do implementation testing of Foo? It's not an unreasonable
>> question. Certainly not "laughable".
>
> In general casting something someone else thinks as laughable is not very
> conductive to working together. I thought the question was phrased in a
> very thought-provoking manner :-).
>
> In any case, the obvious answer to the question is that you can do it by
> writing your implementation so that it is implementation testable in that
> manner. This means not (or allmost not) using package-private access
> definitions anywhere. If "protected" can make sense, you get to do things
> such as
>
> public class MyTestCase extends TestCase
> {
> public static class MyExtended extends My
> {
> public My m;
>
> public MyExtended( My m )
> {
> this.m = m;
> }
>
> public Object exposedFoo()
> {
> return m.foo();
> }
> }
> }
>
> If "protected" does not make sense, you can put the "real" implementation
> in some other package, and then the package-private stuff is nothing more
> than a facade for that real implementation (you still can't
> implementation-test the facade. What you can do is to use code generation
> to create the facade, and then implementation test the code generation.
> Or just not bother). Eg
>
> --
> package java.foo;
>
> import o.a.h.j.foo.FooImpl;
>
> class Foo { /* package private */
> private final FooImpl f = new FooImpl();
>
> void foo()
> {
> f.foo();
> }
> }
> --
> package o.a.h.j.foo;
>
> public class FooImpl
> {
> public void foo() // readily testable, cuz public
> {
> /* ... */
> }
> }
> --
>
> The last option I'm aware of is to resort to using reflection,
> since the runtime type system can bypass any and all access restrictions
> if you have the appropriate security manager, but that leads to rather
> painful test coding and makes the test coding error prone.
I think that both of these solutions are
a) messy - since only XP psycho's really *enjoy* creating unit tests, we
want to make it as painless as possible as to not disincentivize
developers. Look at what we have so far. IBM had to go off to the Unit
Test Mines they run in a Secret Undisclosed Location in the Principality
of BigBlueLand to provide unit tests for stuff they had already donated!
:) [Thanks, btw]
b) subject to "mechanical failure" - we're doing all sorts of unnatural
acts on code that is usually the "rock solid" basis for doing these
unnatural things to other code (like in app servers), and I worry that
such complexity will lead to very hard or impossible to find failures or
bugs
>
> There is also the possibility that all the package-private materials in
> reality are fully exercised if you test the public parts of the package
> thoroughly enough. A coverage utility like clover can show that. XP
> (extreme programming) purists (like me) might argue that if you have
> package-private stuff that is not exerciseable through the public API
> that the package-private stuff needs to be factored out. But lets try not
> to argue too much :-)
I agree with the latter part. What I worry about though is that despite
the best of intentions, unit testing tends not to ever be complete and
thorough. I don't know if things like clover indicate the quality of
the coverage - but simply having coverage just isn't enough, IMO, as you
may not exercise completely enough so that all internal functionality is
directly exercised. Dunno.
>
>>>> Given that this
>>>> o.a.h.t.* pattern comes from Eclipse-land, how do they do it?
>
> I doubt it comes from Eclipse-land. If ViewCVS wasn't locked for CVS
> I could probably find you code from 1997 at the ASF that has a .test.
> package in the middle.
Tim referenced Eclipse as the source of the practice. That's why I was
asking for how they solved the problem of implementation testing.
>
>>>> I
>>>> couldn't imagine that the Eclipse tests don't test package protected
>>>> things.
>>> The only thing shared with Eclipse-land here is the *.tests.* package
>>> name element, hardly significant or unique I expect.
>> Well, it is around here. While I haven't done a survey, I'm used to
>> projects keeping things in parallel trees to make it easy to test.
>
> If with "here" you mean "the ASF" I'm happy to challenge the assertion :-)
Please point me to it! I always want to see new ways of doing this.
Challenge away!
>
>> Granted, projects don't have the problem we have.
>>
>> The thing I'm asking for is this - how in Eclipse-land do they test
>> package protected stuff? How do they do implementation tests?
>
> I suspects its one or more of the above. For my own code, I tend to
> design it so that implementation tests are not neccessary - eg I build
> a large amount of specification tests (API tests) and verify that the
> code coverage from running the API tests is 100%. Of course we don't
> have that luxury (the API is already defined, and most of it probably
> wasn't designed with this whole "purist" testing thing in mind).
>
>>> Eclipse testing does not have the java.* namespace issues with
>>> classloaders that we have got.
>> Right, but that's a classloader and security manager issue for the
>> testing framework, isn't it?
>>
>> Hypothetically....suppose we decided (for whatever reason) that we
>> weren't going to test in situ to get better control of the environment.
>> What would you do?
>
> What does "in situ" mean?
"in the original place". IOW, we test this code not in isolation, like
in a testing framework, but in the VM itself, which IMO is the problem.
It's the problem because (as Tim rightly points out) any in-package unit
tests are running "incorrectly" - they are not running as user code that
uses the target classes would be running.
So the problem boils down to the fact that we are implicitly doing
integration testing. That's why I've been suggesting the framework -
let us test the code in isolation first, using "implementation tests".
Then, if our isolation framework is sexy enough, lets try to reproduce
the same classloader/security model we would experience in a VM, and do
spec/API testing. *Then* we can do integration testing by running the
code in the VM ("in situ") and do the proper (aka (*.test.*) )
spec/API/tck testing.
I'll post this as a separate message because this one is way too woolly
at this point.
>
>>>> I've been short of Round Tuits lately, but I still would like to
>>>> investigate a test harness that helps us by mitigating the security
>>>> issues...
>>> Today we run all our tests in one suite on the classpath. They are API
>>> tests.
>> I hope they are more than API tests.
>
> See above for why one could hope they don't need to more than API tests (I
> doubt it, but in terms of what would be *nice*...)
>
>>> I expect that we will at least have another test suite of implementation
>>> tests.
>>>
>>> However, over the last few weeks we have been discussing the other
>>> 'dimensions' of testing that we want to embody, and we haven't settled
>>> on a suitable way of representing those different dimensions. Filenames
>>> for testcases may do it if we can squeeze in enough information into a
>>> filename (I don't like that approach, BTW)
>> I don't either.
>>
>> , or explicitly defining
>>> different suites of tests.
>> Which makes sense.
>
> Yup. It could even make sense to build some rather large extensions to JUnit
> to make all this stuff more manageable (eg we *can* do stuff like
>
> MyApiTest extends AbstractHarmonyTestCase
> {
> static { markTestStyle(API); }
>
> /* ... */
> }
>
> MyApiTest extends AbstractHarmonyTestCase
> {
> static { markTestStyle(IMPL); }
>
> /* ... */
> }
>
> , or similar things using 1.5 annotations).
>
>
> cheers!
>
>
> Leo
>
>
Unit testing revisited (was: ...Acceptance of HARMONY-39...)
Posted by Leo Simons <ma...@leosimons.com>.
Just two cents (or a little more) from the peanut gallery...
On Tue, Mar 21, 2006 at 10:45:42PM -0500, Geir Magnusson Jr wrote:
> Tim Ellison wrote:
> >Just to clarify terminology -- unit tests are a 'style' of test that
> >focus on particular units of functionality. Unit tests can be both
> >implementation tests and API tests. Implementation tests are specific
> >to our implementation (the mechanism, hidden to the end user, by which
> >we chose to implement the APIs); and API tests are common to all
> >conformant implementations (they test the APIs used by the end user).
>
> So can we refer to "implementation tests" as "unit tests", because I
> would bet that's a well-understood useage, and refer to things that are
> strictly testing the API as "API tests".
Thinking more about all this verbiage, and looking at a bunch of "unit
tests" in many apache packages, I think the definitions are inherently
too vague to get consensus on. It comes down to "what is a unit", and
this is an age-old discussion (see: metric system vs inches) we should
not try and have.
It gets us into arguments like "that is not a proper unit test". 'Why
not?' "The unit is too big." 'Well, our units are just bigger than yours,
you silly Brits!' "Why you little...!"
So I will suggest we don't go and try to define "unit test" and stop using
the phrase when we want to make distinctions between stuff.
Eg I would suggest that we bite the bullet and go something like this:
"unit test" --> any test runnable by a "unit testing framework" such as
JUnit or Cactus.
"implementation test" --> a test run to verify that a specific piece
of code, preferably as small a piece as is seperately
testable, behaves as expected.
"specification test" --> a test run to verify that an implementation is
conformant with some specification, prefereably as small a piece
of the specification for which a test can be defined.
"API test" --> a specification test where the specification takes the
form of an API definition (perhaps a java interface with
supporting javadocs, perhaps just javadocs, perhaps IDL...)
"tck test" --> any test defined as part of something that is called a
"TCK" or technology compatibility kit. TCK tests are
supposed to be specification tests.
> >Geir Magnusson Jr wrote:
> >>Good unit tests are going to be testing things that are package
> >>protected. You can't do that if you aren't in the same package
> >>(obviously).
> >
> >We have implementation tests that require package private, and maybe
> >even private access to our implementation classes both in the java.* and
> >o.a.h.* packages.
This seems correct.
> >The 'problem' is that we cannot define classes in java.* packages that
> >are loaded by the application classloader. That is counter to
> >specification and prohibited by the VM.
> >
> >We also have API tests that should not have access to package private
> >and even private types in the implementation.
This seems correct too.
> >The 'problem' is that running API tests in java.* packages does provide
> >such access, and worse runs those tests on the bootclassloader which
> >gives them special security access not afforded to our users.
This makes sense.
> > I've said this lots of times before.
Usually that means one is not coming across well, not that people aren't
trying to listen or anything like that :-)
> > We already see lots of errors caused by
> >oversight of the classloader differences.
>
> Right. And I think the solution is to think about this in some other
> way than just running things in a VM, like a test harness that does the
> right thing in terms of the classes being tested (what would be in the
> boot classloader) and the classes doing the testing.
I don't know about that. I'm sure that if the problem is well-defined
enough solutions will become apparent, and I still don't quite get why it
is the subject of continuous debate (eg can't someone just go out and try
and do what you propose and show it works?).
> >>With the "custom" of putting in things in o.a.h.t are we
> >>implicitly discouraging good testing practice?
> >
> >This is laughable.
>
> You are going to have to explain why it's "laughable". If you are
> testing a.b.c.Foo and you have to do it from a.b.c.test.FooTest, how can
> you ever do implementation testing of Foo? It's not an unreasonable
> question. Certainly not "laughable".
In general casting something someone else thinks as laughable is not very
conductive to working together. I thought the question was phrased in a
very thought-provoking manner :-).
In any case, the obvious answer to the question is that you can do it by
writing your implementation so that it is implementation testable in that
manner. This means not (or allmost not) using package-private access
definitions anywhere. If "protected" can make sense, you get to do things
such as
public class MyTestCase extends TestCase
{
public static class MyExtended extends My
{
public My m;
public MyExtended( My m )
{
this.m = m;
}
public Object exposedFoo()
{
return m.foo();
}
}
}
If "protected" does not make sense, you can put the "real" implementation
in some other package, and then the package-private stuff is nothing more
than a facade for that real implementation (you still can't
implementation-test the facade. What you can do is to use code generation
to create the facade, and then implementation test the code generation.
Or just not bother). Eg
--
package java.foo;
import o.a.h.j.foo.FooImpl;
class Foo { /* package private */
private final FooImpl f = new FooImpl();
void foo()
{
f.foo();
}
}
--
package o.a.h.j.foo;
public class FooImpl
{
public void foo() // readily testable, cuz public
{
/* ... */
}
}
--
The last option I'm aware of is to resort to using reflection,
since the runtime type system can bypass any and all access restrictions
if you have the appropriate security manager, but that leads to rather
painful test coding and makes the test coding error prone.
There is also the possibility that all the package-private materials in
reality are fully exercised if you test the public parts of the package
thoroughly enough. A coverage utility like clover can show that. XP
(extreme programming) purists (like me) might argue that if you have
package-private stuff that is not exerciseable through the public API
that the package-private stuff needs to be factored out. But lets try not
to argue too much :-)
> >>Given that this
> >>o.a.h.t.* pattern comes from Eclipse-land, how do they do it?
I doubt it comes from Eclipse-land. If ViewCVS wasn't locked for CVS
I could probably find you code from 1997 at the ASF that has a .test.
package in the middle.
> >> I
> >>couldn't imagine that the Eclipse tests don't test package protected
> >>things.
> >
> >The only thing shared with Eclipse-land here is the *.tests.* package
> >name element, hardly significant or unique I expect.
>
> Well, it is around here. While I haven't done a survey, I'm used to
> projects keeping things in parallel trees to make it easy to test.
If with "here" you mean "the ASF" I'm happy to challenge the assertion :-)
> Granted, projects don't have the problem we have.
>
> The thing I'm asking for is this - how in Eclipse-land do they test
> package protected stuff? How do they do implementation tests?
I suspects its one or more of the above. For my own code, I tend to
design it so that implementation tests are not neccessary - eg I build
a large amount of specification tests (API tests) and verify that the
code coverage from running the API tests is 100%. Of course we don't
have that luxury (the API is already defined, and most of it probably
wasn't designed with this whole "purist" testing thing in mind).
> >Eclipse testing does not have the java.* namespace issues with
> >classloaders that we have got.
>
> Right, but that's a classloader and security manager issue for the
> testing framework, isn't it?
>
> Hypothetically....suppose we decided (for whatever reason) that we
> weren't going to test in situ to get better control of the environment.
> What would you do?
What does "in situ" mean?
> >>I've been short of Round Tuits lately, but I still would like to
> >>investigate a test harness that helps us by mitigating the security
> >>issues...
> >
> >Today we run all our tests in one suite on the classpath. They are API
> >tests.
>
> I hope they are more than API tests.
See above for why one could hope they don't need to more than API tests (I
doubt it, but in terms of what would be *nice*...)
> >I expect that we will at least have another test suite of implementation
> >tests.
> >
> >However, over the last few weeks we have been discussing the other
> >'dimensions' of testing that we want to embody, and we haven't settled
> >on a suitable way of representing those different dimensions. Filenames
> >for testcases may do it if we can squeeze in enough information into a
> >filename (I don't like that approach, BTW)
>
> I don't either.
>
> , or explicitly defining
> >different suites of tests.
>
> Which makes sense.
Yup. It could even make sense to build some rather large extensions to JUnit
to make all this stuff more manageable (eg we *can* do stuff like
MyApiTest extends AbstractHarmonyTestCase
{
static { markTestStyle(API); }
/* ... */
}
MyApiTest extends AbstractHarmonyTestCase
{
static { markTestStyle(IMPL); }
/* ... */
}
, or similar things using 1.5 annotations).
cheers!
Leo
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Etienne Gagnon wrote:
> Just a random idea... Why not have a special "testing" mode in the VM
> that would trigger special permissions to code in ".test" packages?
You wouldn't need that when testing in the VM. :)
That's why Tim suggested o.a.h.test.xxxx so then you stay out of package
namespace that "belongs" to the boot classpath.
>
> Actually, this mechanism could act differently: simply consider
> some.package and some.package.test as being the *same* package (so,
> erase, at loading time, the .test package suffix from loaded classes.
> It could also "combine" the fields & methods of package.Foo with
> package.test.Foo if classes with identical names exist in both packages,
> so that private methods could be tested.
To me the problem then is that our VM becomes a testing framework - why
not just have a testing framework?
>
> Additionally, the testing mode could allow for loading java.lang.*
> classes in user class loaders.
>
> Of course, this would be a non-standard option, like -Xtestpermissions .
> And, this way, all the test code could reside in files and directories
> that would be separate from the real code.
>
> Yep, a random idea. ;-)
>
Not a bad one, but it seems like a special "testing framework" with just
another name :)
geir
> Etienne
>
> Geir Magnusson Jr wrote:
>> testing a.b.c.Foo and you have to do it from a.b.c.test.FooTest, how can
>> you ever do implementation testing of Foo? It's not an unreasonable
>> ...
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Etienne Gagnon <eg...@sablevm.org>.
Just a random idea... Why not have a special "testing" mode in the VM
that would trigger special permissions to code in ".test" packages?
Actually, this mechanism could act differently: simply consider
some.package and some.package.test as being the *same* package (so,
erase, at loading time, the .test package suffix from loaded classes.
It could also "combine" the fields & methods of package.Foo with
package.test.Foo if classes with identical names exist in both packages,
so that private methods could be tested.
Additionally, the testing mode could allow for loading java.lang.*
classes in user class loaders.
Of course, this would be a non-standard option, like -Xtestpermissions .
And, this way, all the test code could reside in files and directories
that would be separate from the real code.
Yep, a random idea. ;-)
Etienne
Geir Magnusson Jr wrote:
> testing a.b.c.Foo and you have to do it from a.b.c.test.FooTest, how can
> you ever do implementation testing of Foo? It's not an unreasonable
>...
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
sorry (was: Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution
of beans, regex and math class library code)
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
<snip>
>> Geir Magnusson Jr wrote:
<snip>
>>> With the "custom" of putting in things in o.a.h.t are we
>>> implicitly discouraging good testing practice?
>>
>> This is laughable.
>
> You are going to have to explain why it's "laughable". If you are
> testing a.b.c.Foo and you have to do it from a.b.c.test.FooTest, how can
> you ever do implementation testing of Foo? It's not an unreasonable
> question. Certainly not "laughable".
I'm behind on my mail at the moment as I prepare for the Harmony talk at
eclipsecon -- so I'll give you a proper answer later, but I wanted to
apologize straight away if my flippant response caused offense. I hope
you know I don't mean it personally. I'm passionate about the
*technology* ! and it kinda spilled over ;-) I'll behave better...
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Just to clarify terminology -- unit tests are a 'style' of test that
> focus on particular units of functionality. Unit tests can be both
> implementation tests and API tests. Implementation tests are specific
> to our implementation (the mechanism, hidden to the end user, by which
> we chose to implement the APIs); and API tests are common to all
> conformant implementations (they test the APIs used by the end user).
So can we refer to "implementation tests" as "unit tests", because I
would bet that's a well-understood useage, and refer to things that are
strictly testing the API as "API tests".
>
> Geir Magnusson Jr wrote:
>> Good unit tests are going to be testing things that are package
>> protected. You can't do that if you aren't in the same package
>> (obviously).
>
> We have implementation tests that require package private, and maybe
> even private access to our implementation classes both in the java.* and
> o.a.h.* packages.
>
> The 'problem' is that we cannot define classes in java.* packages that
> are loaded by the application classloader. That is counter to
> specification and prohibited by the VM.
>
> We also have API tests that should not have access to package private
> and even private types in the implementation.
>
> The 'problem' is that running API tests in java.* packages does provide
> such access, and worse runs those tests on the bootclassloader which
> gives them special security access not afforded to our users. I've said
> this lots of times before. We already see lots of errors caused by
> oversight of the classloader differences.
Right. And I think the solution is to think about this in some other
way than just running things in a VM, like a test harness that does the
right thing in terms of the classes being tested (what would be in the
boot classloader) and the classes doing the testing.
>
>> With the "custom" of putting in things in o.a.h.t are we
>> implicitly discouraging good testing practice?
>
> This is laughable.
You are going to have to explain why it's "laughable". If you are
testing a.b.c.Foo and you have to do it from a.b.c.test.FooTest, how can
you ever do implementation testing of Foo? It's not an unreasonable
question. Certainly not "laughable".
>
>> Given that this
>> o.a.h.t.* pattern comes from Eclipse-land, how do they do it? I
>> couldn't imagine that the Eclipse tests don't test package protected
>> things.
>
> The only thing shared with Eclipse-land here is the *.tests.* package
> name element, hardly significant or unique I expect.
Well, it is around here. While I haven't done a survey, I'm used to
projects keeping things in parallel trees to make it easy to test.
Granted, projects don't have the problem we have.
The thing I'm asking for is this - how in Eclipse-land do they test
package protected stuff? How do they do implementation tests?
>
> Eclipse testing does not have the java.* namespace issues with
> classloaders that we have got.
Right, but that's a classloader and security manager issue for the
testing framework, isn't it?
Hypothetically....suppose we decided (for whatever reason) that we
weren't going to test in situ to get better control of the environment.
What would you do?
>
>> I've been short of Round Tuits lately, but I still would like to
>> investigate a test harness that helps us by mitigating the security
>> issues...
>
> Today we run all our tests in one suite on the classpath. They are API
> tests.
I hope they are more than API tests.
>
> I expect that we will at least have another test suite of implementation
> tests.
>
> However, over the last few weeks we have been discussing the other
> 'dimensions' of testing that we want to embody, and we haven't settled
> on a suitable way of representing those different dimensions. Filenames
> for testcases may do it if we can squeeze in enough information into a
> filename (I don't like that approach, BTW)
I don't either.
, or explicitly defining
> different suites of tests.
Which makes sense.
>
> Regards,
> Tim
>
>> geir
>>
>> Mark Hindess wrote:
>>> I thought the crucial thing was that tests should be in a separate
>>> namespace not in the namespace of the package they are testing (at
>>> least not unless it was absolutely necessary).
>>> -Mark.
>>>
>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>> I'm doing it now.
>>>>
>>>> I need to go back and stare at our discussion on test setup, because I'm
>>>> still not a raving fan of o.a.h.test....
>>>>
>>>> geir
>>>>
>>>> Mark Hindess wrote:
>>>>> Don't worry, you'd have to be less subtle for me to take something
>>>>> as criticism.
>>>>>
>>>>> I've had an attempt at moving beans out - HARMONY-218. If that gets
>>>>> committed I'll do the other too.
>>>>>
>>>>> -Mark.
>>>>>
>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>> That wasn't a criticism, btw. It seemed like a natural thing to do
>>>>>> when
>>>>>> I first saw it, but when I was actually dealing w/ it, my opinion
>>>>>> changed.
>>>>>>
>>>>>> Yah, split away! That was going to be my next question, how to
>>>>>> split..
>>>>>>
>>>>>> geir
>>>>>>
>>>>>> Mark Hindess wrote:
>>>>>>> Fair enough.
>>>>>>>
>>>>>>> Mind if I redo the script/patch to split the three modules to match
>>>>>>> the structure of the others? That is, into separate modules/math,
>>>>>>> modules/beans, modules/regex directories?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mark.
>>>>>>>
>>>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>>>> I just committed. There was some delay because of a missing
>>>>>>>> CCLA. Sorry.
>>>>>>>>
>>>>>>>> I've committed the code as is from the JIRA. I'm going to do
>>>>>>>> some basic
>>>>>>>> cleanup and then look at hte patches to integrate.
>>>>>>>>
>>>>>>>> Looking at this (and 88?) I think that this "add patches"
>>>>>>>> approach is a
>>>>>>>> bad one, because it complicates what this JIRA is now.
>>>>>>>>
>>>>>>>> In the future, I think we should just create new JIRA's for
>>>>>>>> add-ons (if
>>>>>>>> the add-on contributor isn't the contributor of the original
>>>>>>>> JIRA) and
>>>>>>>> just link them so they are easy to keep track of...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Richard Liang wrote:
>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>> Despite a touch of trouble with the packaging of the
>>>>>>>>>> contribution, it
>>>>>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
>>>>>>>>>>
>>>>>>>>>> +1 from :
>>>>>>>>>>
>>>>>>>>>> Geir
>>>>>>>>>> Stefano
>>>>>>>>>> Dims
>>>>>>>>>> Tim
>>>>>>>>>> Leo
>>>>>>>>>>
>>>>>>>>>> In it comes....
>>>>>>>>>>
>>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can
>>>>>>>>>>> assert
>>>>>>>>>>> that the critical provenance paperwork is in order (although
>>>>>>>>>>> not in
>>>>>>>>>>> SVN yet).
>>>>>>>>>>>
>>>>>>>>>>> Please vote to accept or reject this codebase into the Apache
>>>>>>>>>>> Harmony
>>>>>>>>>>> class library :
>>>>>>>>>>>
>>>>>>>>>>> [ ] + 1 Accept
>>>>>>>>>>> [ ] -1 Reject (provide reason below
>>>>>>>>>>>
>>>>>>>>>>> Lets let this run 3 days unless a) someone states they need
>>>>>>>>>>> more time
>>>>>>>>>>> or b) we get all committer votes before then.
>>>>>>>>>>>
>>>>>>>>>>> Go...
>>>>>>>>>>>
>>>>>>>>>>> geir
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> Hello Geir,
>>>>>>>>>
>>>>>>>>> As this contribution has been accepted for a long time, I'm
>>>>>>>>> wondering
>>>>>>>>> when the source code could be put into Harmony SVN.
>>>>>>>>>
>>>>>>>>> I'm working on the implementation of java.text.DecimalFormat
>>>>>>>>> which has
>>>>>>>>> enhancements on BigDecimal and BigInteger support. Now I just
>>>>>>>>> use this
>>>>>>>>> contribution as external jars in Eclipse.
>>>>>>>>>
>>>>>>> --
>>>>>>> Mark Hindess <ma...@googlemail.com>
>>>>>>> IBM Java Technology Centre, UK.
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Mark Hindess <ma...@googlemail.com>
>>>>> IBM Java Technology Centre, UK.
>>>>>
>>>>>
>>>
>>> --
>>> Mark Hindess <ma...@googlemail.com>
>>> IBM Java Technology Centre, UK.
>>>
>>>
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Tim Ellison <t....@gmail.com>.
Just to clarify terminology -- unit tests are a 'style' of test that
focus on particular units of functionality. Unit tests can be both
implementation tests and API tests. Implementation tests are specific
to our implementation (the mechanism, hidden to the end user, by which
we chose to implement the APIs); and API tests are common to all
conformant implementations (they test the APIs used by the end user).
Geir Magnusson Jr wrote:
> Good unit tests are going to be testing things that are package
> protected. You can't do that if you aren't in the same package
> (obviously).
We have implementation tests that require package private, and maybe
even private access to our implementation classes both in the java.* and
o.a.h.* packages.
The 'problem' is that we cannot define classes in java.* packages that
are loaded by the application classloader. That is counter to
specification and prohibited by the VM.
We also have API tests that should not have access to package private
and even private types in the implementation.
The 'problem' is that running API tests in java.* packages does provide
such access, and worse runs those tests on the bootclassloader which
gives them special security access not afforded to our users. I've said
this lots of times before. We already see lots of errors caused by
oversight of the classloader differences.
> With the "custom" of putting in things in o.a.h.t are we
> implicitly discouraging good testing practice?
This is laughable.
> Given that this
> o.a.h.t.* pattern comes from Eclipse-land, how do they do it? I
> couldn't imagine that the Eclipse tests don't test package protected
> things.
The only thing shared with Eclipse-land here is the *.tests.* package
name element, hardly significant or unique I expect.
Eclipse testing does not have the java.* namespace issues with
classloaders that we have got.
> I've been short of Round Tuits lately, but I still would like to
> investigate a test harness that helps us by mitigating the security
> issues...
Today we run all our tests in one suite on the classpath. They are API
tests.
I expect that we will at least have another test suite of implementation
tests.
However, over the last few weeks we have been discussing the other
'dimensions' of testing that we want to embody, and we haven't settled
on a suitable way of representing those different dimensions. Filenames
for testcases may do it if we can squeeze in enough information into a
filename (I don't like that approach, BTW), or explicitly defining
different suites of tests.
Regards,
Tim
> geir
>
> Mark Hindess wrote:
>> I thought the crucial thing was that tests should be in a separate
>> namespace not in the namespace of the package they are testing (at
>> least not unless it was absolutely necessary).
>> -Mark.
>>
>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>> I'm doing it now.
>>>
>>> I need to go back and stare at our discussion on test setup, because I'm
>>> still not a raving fan of o.a.h.test....
>>>
>>> geir
>>>
>>> Mark Hindess wrote:
>>>> Don't worry, you'd have to be less subtle for me to take something
>>>> as criticism.
>>>>
>>>> I've had an attempt at moving beans out - HARMONY-218. If that gets
>>>> committed I'll do the other too.
>>>>
>>>> -Mark.
>>>>
>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>> That wasn't a criticism, btw. It seemed like a natural thing to do
>>>>> when
>>>>> I first saw it, but when I was actually dealing w/ it, my opinion
>>>>> changed.
>>>>>
>>>>> Yah, split away! That was going to be my next question, how to
>>>>> split..
>>>>>
>>>>> geir
>>>>>
>>>>> Mark Hindess wrote:
>>>>>> Fair enough.
>>>>>>
>>>>>> Mind if I redo the script/patch to split the three modules to match
>>>>>> the structure of the others? That is, into separate modules/math,
>>>>>> modules/beans, modules/regex directories?
>>>>>>
>>>>>> Regards,
>>>>>> Mark.
>>>>>>
>>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>>> I just committed. There was some delay because of a missing
>>>>>>> CCLA. Sorry.
>>>>>>>
>>>>>>> I've committed the code as is from the JIRA. I'm going to do
>>>>>>> some basic
>>>>>>> cleanup and then look at hte patches to integrate.
>>>>>>>
>>>>>>> Looking at this (and 88?) I think that this "add patches"
>>>>>>> approach is a
>>>>>>> bad one, because it complicates what this JIRA is now.
>>>>>>>
>>>>>>> In the future, I think we should just create new JIRA's for
>>>>>>> add-ons (if
>>>>>>> the add-on contributor isn't the contributor of the original
>>>>>>> JIRA) and
>>>>>>> just link them so they are easy to keep track of...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Richard Liang wrote:
>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>> Despite a touch of trouble with the packaging of the
>>>>>>>>> contribution, it
>>>>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
>>>>>>>>>
>>>>>>>>> +1 from :
>>>>>>>>>
>>>>>>>>> Geir
>>>>>>>>> Stefano
>>>>>>>>> Dims
>>>>>>>>> Tim
>>>>>>>>> Leo
>>>>>>>>>
>>>>>>>>> In it comes....
>>>>>>>>>
>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can
>>>>>>>>>> assert
>>>>>>>>>> that the critical provenance paperwork is in order (although
>>>>>>>>>> not in
>>>>>>>>>> SVN yet).
>>>>>>>>>>
>>>>>>>>>> Please vote to accept or reject this codebase into the Apache
>>>>>>>>>> Harmony
>>>>>>>>>> class library :
>>>>>>>>>>
>>>>>>>>>> [ ] + 1 Accept
>>>>>>>>>> [ ] -1 Reject (provide reason below
>>>>>>>>>>
>>>>>>>>>> Lets let this run 3 days unless a) someone states they need
>>>>>>>>>> more time
>>>>>>>>>> or b) we get all committer votes before then.
>>>>>>>>>>
>>>>>>>>>> Go...
>>>>>>>>>>
>>>>>>>>>> geir
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> Hello Geir,
>>>>>>>>
>>>>>>>> As this contribution has been accepted for a long time, I'm
>>>>>>>> wondering
>>>>>>>> when the source code could be put into Harmony SVN.
>>>>>>>>
>>>>>>>> I'm working on the implementation of java.text.DecimalFormat
>>>>>>>> which has
>>>>>>>> enhancements on BigDecimal and BigInteger support. Now I just
>>>>>>>> use this
>>>>>>>> contribution as external jars in Eclipse.
>>>>>>>>
>>>>>> --
>>>>>> Mark Hindess <ma...@googlemail.com>
>>>>>> IBM Java Technology Centre, UK.
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Mark Hindess <ma...@googlemail.com>
>>>> IBM Java Technology Centre, UK.
>>>>
>>>>
>>
>>
>> --
>> Mark Hindess <ma...@googlemail.com>
>> IBM Java Technology Centre, UK.
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Richard Liang wrote:
> Geir Magnusson Jr wrote:
>> Good unit tests are going to be testing things that are package
>> protected. You can't do that if you aren't in the same package
>> (obviously). With the "custom" of putting in things in o.a.h.t are we
>> implicitly discouraging good testing practice? Given that this
>> o.a.h.t.* pattern comes from Eclipse-land, how do they do it? I
>> couldn't imagine that the Eclipse tests don't test package protected
>> things.
>>
> Hello Geir,
>
> Maybe we should have two types of test suites:
> 1. Test for APIs including public and protected methods which could be
> run against different Java SE implementations.
Yep
> ==>> If we want to test a protected method of a class, we could mock a
> subclass of this class. And write test case against the subclass.
> (Protected methods are accessible to subclass)
That's actually different but interesting.
>
> 2. Test for internal implementation which may include tests for package
> private methods and tests for other internal-used classes.
> ==>>We must put the tests into the same package if we want to test
> package private methods of a class.
Yes
>
> These are just some rough thinking ;-) Any comments? Thanks a lot.
I wonder if we're unique in this situation. We may be, given we need to
test the things that 99.9999% of the world depends on having right and
working.
We also have the problem that testing w/in a VM makes assumptions about
the VM correctness, which we can't tell right now :)
geir
>> I've been short of Round Tuits lately, but I still would like to
>> investigate a test harness that helps us by mitigating the security
>> issues...
>>
>> geir
>>
>> Mark Hindess wrote:
>>> I thought the crucial thing was that tests should be in a separate
>>> namespace not in the namespace of the package they are testing (at
>>> least not unless it was absolutely necessary).
>>> -Mark.
>>>
>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>> I'm doing it now.
>>>>
>>>> I need to go back and stare at our discussion on test setup, because
>>>> I'm
>>>> still not a raving fan of o.a.h.test....
>>>>
>>>> geir
>>>>
>>>> Mark Hindess wrote:
>>>>> Don't worry, you'd have to be less subtle for me to take something
>>>>> as criticism.
>>>>>
>>>>> I've had an attempt at moving beans out - HARMONY-218. If that gets
>>>>> committed I'll do the other too.
>>>>>
>>>>> -Mark.
>>>>>
>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>> That wasn't a criticism, btw. It seemed like a natural thing to
>>>>>> do when
>>>>>> I first saw it, but when I was actually dealing w/ it, my opinion
>>>>>> changed.
>>>>>>
>>>>>> Yah, split away! That was going to be my next question, how to
>>>>>> split..
>>>>>>
>>>>>> geir
>>>>>>
>>>>>> Mark Hindess wrote:
>>>>>>> Fair enough.
>>>>>>>
>>>>>>> Mind if I redo the script/patch to split the three modules to match
>>>>>>> the structure of the others? That is, into separate modules/math,
>>>>>>> modules/beans, modules/regex directories?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mark.
>>>>>>>
>>>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>>>> I just committed. There was some delay because of a missing
>>>>>>>> CCLA. Sorry.
>>>>>>>>
>>>>>>>> I've committed the code as is from the JIRA. I'm going to do
>>>>>>>> some basic
>>>>>>>> cleanup and then look at hte patches to integrate.
>>>>>>>>
>>>>>>>> Looking at this (and 88?) I think that this "add patches"
>>>>>>>> approach is a
>>>>>>>> bad one, because it complicates what this JIRA is now.
>>>>>>>>
>>>>>>>> In the future, I think we should just create new JIRA's for
>>>>>>>> add-ons (if
>>>>>>>> the add-on contributor isn't the contributor of the original
>>>>>>>> JIRA) and
>>>>>>>> just link them so they are easy to keep track of...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Richard Liang wrote:
>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>> Despite a touch of trouble with the packaging of the
>>>>>>>>>> contribution, it
>>>>>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
>>>>>>>>>>
>>>>>>>>>> +1 from :
>>>>>>>>>>
>>>>>>>>>> Geir
>>>>>>>>>> Stefano
>>>>>>>>>> Dims
>>>>>>>>>> Tim
>>>>>>>>>> Leo
>>>>>>>>>>
>>>>>>>>>> In it comes....
>>>>>>>>>>
>>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can
>>>>>>>>>>> assert
>>>>>>>>>>> that the critical provenance paperwork is in order (although
>>>>>>>>>>> not in
>>>>>>>>>>> SVN yet).
>>>>>>>>>>>
>>>>>>>>>>> Please vote to accept or reject this codebase into the Apache
>>>>>>>>>>> Harmony
>>>>>>>>>>> class library :
>>>>>>>>>>>
>>>>>>>>>>> [ ] + 1 Accept
>>>>>>>>>>> [ ] -1 Reject (provide reason below
>>>>>>>>>>>
>>>>>>>>>>> Lets let this run 3 days unless a) someone states they need
>>>>>>>>>>> more time
>>>>>>>>>>> or b) we get all committer votes before then.
>>>>>>>>>>>
>>>>>>>>>>> Go...
>>>>>>>>>>>
>>>>>>>>>>> geir
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> Hello Geir,
>>>>>>>>>
>>>>>>>>> As this contribution has been accepted for a long time, I'm
>>>>>>>>> wondering
>>>>>>>>> when the source code could be put into Harmony SVN.
>>>>>>>>>
>>>>>>>>> I'm working on the implementation of java.text.DecimalFormat
>>>>>>>>> which has
>>>>>>>>> enhancements on BigDecimal and BigInteger support. Now I just
>>>>>>>>> use this
>>>>>>>>> contribution as external jars in Eclipse.
>>>>>>>>>
>>>>>>> --
>>>>>>> Mark Hindess <ma...@googlemail.com>
>>>>>>> IBM Java Technology Centre, UK.
>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> Mark Hindess <ma...@googlemail.com>
>>>>> IBM Java Technology Centre, UK.
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Mark Hindess <ma...@googlemail.com>
>>> IBM Java Technology Centre, UK.
>>>
>>>
>>
>
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Stepan Mishura <st...@gmail.com>.
Hi Richard,
On 3/21/06, Richard Liang wrote:
> Geir Magnusson Jr wrote:
> > Good unit tests are going to be testing things that are package
> > protected. You can't do that if you aren't in the same package
> > (obviously). With the "custom" of putting in things in o.a.h.t are we
> > implicitly discouraging good testing practice? Given that this
> > o.a.h.t.* pattern comes from Eclipse-land, how do they do it? I
> > couldn't imagine that the Eclipse tests don't test package protected
> > things.
> >
> Hello Geir,
>
> Maybe we should have two types of test suites:
> 1. Test for APIs including public and protected methods which could be
> run against different Java SE implementations.
> ==>> If we want to test a protected method of a class, we could mock a
> subclass of this class. And write test case against the subclass.
> (Protected methods are accessible to subclass)
>
> 2. Test for internal implementation which may include tests for package
> private methods and tests for other internal-used classes.
> ==>>We must put the tests into the same package if we want to test
> package private methods of a class.
I agree with you that we should put tests in separate suites. I did the
similar suggestion[1] a while ago.
Thanks,
Stepan.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/%3c6e47b64f0603150129mddcae2at4229b4be5b9e71a7@mail.gmail.com%3e
> These are just some rough thinking ;-) Any comments? Thanks a lot.
> > I've been short of Round Tuits lately, but I still would like to
> > investigate a test harness that helps us by mitigating the security
> > issues...
> >
> > geir
> >
> > Mark Hindess wrote:
> >> I thought the crucial thing was that tests should be in a separate
> >> namespace not in the namespace of the package they are testing (at
> >> least not unless it was absolutely necessary).
> >> -Mark.
> >>
> >> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>> I'm doing it now.
> >>>
> >>> I need to go back and stare at our discussion on test setup, because
> >>> I'm
> >>> still not a raving fan of o.a.h.test....
> >>>
> >>> geir
> >>>
> >>> Mark Hindess wrote:
> >>>> Don't worry, you'd have to be less subtle for me to take something
> >>>> as criticism.
> >>>>
> >>>> I've had an attempt at moving beans out - HARMONY-218. If that gets
> >>>> committed I'll do the other too.
> >>>>
> >>>> -Mark.
> >>>>
> >>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>>> That wasn't a criticism, btw. It seemed like a natural thing to
> >>>>> do when
> >>>>> I first saw it, but when I was actually dealing w/ it, my opinion
> >>>>> changed.
> >>>>>
> >>>>> Yah, split away! That was going to be my next question, how to
> >>>>> split..
> >>>>>
> >>>>> geir
> >>>>>
> >>>>> Mark Hindess wrote:
> >>>>>> Fair enough.
> >>>>>>
> >>>>>> Mind if I redo the script/patch to split the three modules to match
> >>>>>> the structure of the others? That is, into separate modules/math,
> >>>>>> modules/beans, modules/regex directories?
> >>>>>>
> >>>>>> Regards,
> >>>>>> Mark.
> >>>>>>
> >>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>>>>> I just committed. There was some delay because of a missing
> >>>>>>> CCLA. Sorry.
> >>>>>>>
> >>>>>>> I've committed the code as is from the JIRA. I'm going to do
> >>>>>>> some basic
> >>>>>>> cleanup and then look at hte patches to integrate.
> >>>>>>>
> >>>>>>> Looking at this (and 88?) I think that this "add patches"
> >>>>>>> approach is a
> >>>>>>> bad one, because it complicates what this JIRA is now.
> >>>>>>>
> >>>>>>> In the future, I think we should just create new JIRA's for
> >>>>>>> add-ons (if
> >>>>>>> the add-on contributor isn't the contributor of the original
> >>>>>>> JIRA) and
> >>>>>>> just link them so they are easy to keep track of...
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Richard Liang wrote:
> >>>>>>>> Geir Magnusson Jr wrote:
> >>>>>>>>> Despite a touch of trouble with the packaging of the
> >>>>>>>>> contribution, it
> >>>>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
> >>>>>>>>>
> >>>>>>>>> +1 from :
> >>>>>>>>>
> >>>>>>>>> Geir
> >>>>>>>>> Stefano
> >>>>>>>>> Dims
> >>>>>>>>> Tim
> >>>>>>>>> Leo
> >>>>>>>>>
> >>>>>>>>> In it comes....
> >>>>>>>>>
> >>>>>>>>> Geir Magnusson Jr wrote:
> >>>>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can
> >>>>>>>>>> assert
> >>>>>>>>>> that the critical provenance paperwork is in order (although
> >>>>>>>>>> not in
> >>>>>>>>>> SVN yet).
> >>>>>>>>>>
> >>>>>>>>>> Please vote to accept or reject this codebase into the Apache
> >>>>>>>>>> Harmony
> >>>>>>>>>> class library :
> >>>>>>>>>>
> >>>>>>>>>> [ ] + 1 Accept
> >>>>>>>>>> [ ] -1 Reject (provide reason below
> >>>>>>>>>>
> >>>>>>>>>> Lets let this run 3 days unless a) someone states they need
> >>>>>>>>>> more time
> >>>>>>>>>> or b) we get all committer votes before then.
> >>>>>>>>>>
> >>>>>>>>>> Go...
> >>>>>>>>>>
> >>>>>>>>>> geir
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> Hello Geir,
> >>>>>>>>
> >>>>>>>> As this contribution has been accepted for a long time, I'm
> >>>>>>>> wondering
> >>>>>>>> when the source code could be put into Harmony SVN.
> >>>>>>>>
> >>>>>>>> I'm working on the implementation of java.text.DecimalFormat
> >>>>>>>> which has
> >>>>>>>> enhancements on BigDecimal and BigInteger support. Now I just
> >>>>>>>> use this
> >>>>>>>> contribution as external jars in Eclipse.
> >>>>>>>>
> >>>>>> --
> >>>>>> Mark Hindess <ma...@googlemail.com>
> >>>>>> IBM Java Technology Centre, UK.
> >>>>>>
> >>>>>>
> >>>>
> >>>> --
> >>>> Mark Hindess <ma...@googlemail.com>
> >>>> IBM Java Technology Centre, UK.
> >>>>
> >>>>
> >>
> >>
> >> --
> >> Mark Hindess <ma...@googlemail.com>
> >> IBM Java Technology Centre, UK.
> >>
> >>
> >
>
>
> --
> Richard Liang
> China Software Development Lab, IBM
>
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> Hi Richard
>
> Did I understand your "1." correctly that this suite (Test for APIs) would be
> something competing with Sun's TCK?
Not sure how you got there from Richard's comments. As others have said
"no", we need API tests to test our code is working as we intended.
When it comes to getting certification we will use Sun's JCK (the only
way of getting certification). We should be reasonably confident of
achieving compliance before running the JCK (i.e. we code to the spec
not to the JCK).
Regards,
Tim
> Thanks,
> Mikhail
>
> 2006/3/21, Richard Liang <ri...@gmail.com>:
>> Geir Magnusson Jr wrote:
>>> Good unit tests are going to be testing things that are package
>>> protected. You can't do that if you aren't in the same package
>>> (obviously). With the "custom" of putting in things in o.a.h.t are we
>>> implicitly discouraging good testing practice? Given that this
>>> o.a.h.t.* pattern comes from Eclipse-land, how do they do it? I
>>> couldn't imagine that the Eclipse tests don't test package protected
>>> things.
>>>
>> Hello Geir,
>>
>> Maybe we should have two types of test suites:
>> 1. Test for APIs including public and protected methods which could be
>> run against different Java SE implementations.
>> ==>> If we want to test a protected method of a class, we could mock a
>> subclass of this class. And write test case against the subclass.
>> (Protected methods are accessible to subclass)
>>
>> 2. Test for internal implementation which may include tests for package
>> private methods and tests for other internal-used classes.
>> ==>>We must put the tests into the same package if we want to test
>> package private methods of a class.
>>
>> These are just some rough thinking ;-) Any comments? Thanks a lot.
>>> I've been short of Round Tuits lately, but I still would like to
>>> investigate a test harness that helps us by mitigating the security
>>> issues...
>>>
>>> geir
>>>
>>> Mark Hindess wrote:
>>>> I thought the crucial thing was that tests should be in a separate
>>>> namespace not in the namespace of the package they are testing (at
>>>> least not unless it was absolutely necessary).
>>>> -Mark.
>>>>
>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>> I'm doing it now.
>>>>>
>>>>> I need to go back and stare at our discussion on test setup, because
>>>>> I'm
>>>>> still not a raving fan of o.a.h.test....
>>>>>
>>>>> geir
>>>>>
>>>>> Mark Hindess wrote:
>>>>>> Don't worry, you'd have to be less subtle for me to take something
>>>>>> as criticism.
>>>>>>
>>>>>> I've had an attempt at moving beans out - HARMONY-218. If that gets
>>>>>> committed I'll do the other too.
>>>>>>
>>>>>> -Mark.
>>>>>>
>>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>>> That wasn't a criticism, btw. It seemed like a natural thing to
>>>>>>> do when
>>>>>>> I first saw it, but when I was actually dealing w/ it, my opinion
>>>>>>> changed.
>>>>>>>
>>>>>>> Yah, split away! That was going to be my next question, how to
>>>>>>> split..
>>>>>>>
>>>>>>> geir
>>>>>>>
>>>>>>> Mark Hindess wrote:
>>>>>>>> Fair enough.
>>>>>>>>
>>>>>>>> Mind if I redo the script/patch to split the three modules to match
>>>>>>>> the structure of the others? That is, into separate modules/math,
>>>>>>>> modules/beans, modules/regex directories?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mark.
>>>>>>>>
>>>>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>>>>> I just committed. There was some delay because of a missing
>>>>>>>>> CCLA. Sorry.
>>>>>>>>>
>>>>>>>>> I've committed the code as is from the JIRA. I'm going to do
>>>>>>>>> some basic
>>>>>>>>> cleanup and then look at hte patches to integrate.
>>>>>>>>>
>>>>>>>>> Looking at this (and 88?) I think that this "add patches"
>>>>>>>>> approach is a
>>>>>>>>> bad one, because it complicates what this JIRA is now.
>>>>>>>>>
>>>>>>>>> In the future, I think we should just create new JIRA's for
>>>>>>>>> add-ons (if
>>>>>>>>> the add-on contributor isn't the contributor of the original
>>>>>>>>> JIRA) and
>>>>>>>>> just link them so they are easy to keep track of...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Richard Liang wrote:
>>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>>> Despite a touch of trouble with the packaging of the
>>>>>>>>>>> contribution, it
>>>>>>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
>>>>>>>>>>>
>>>>>>>>>>> +1 from :
>>>>>>>>>>>
>>>>>>>>>>> Geir
>>>>>>>>>>> Stefano
>>>>>>>>>>> Dims
>>>>>>>>>>> Tim
>>>>>>>>>>> Leo
>>>>>>>>>>>
>>>>>>>>>>> In it comes....
>>>>>>>>>>>
>>>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can
>>>>>>>>>>>> assert
>>>>>>>>>>>> that the critical provenance paperwork is in order (although
>>>>>>>>>>>> not in
>>>>>>>>>>>> SVN yet).
>>>>>>>>>>>>
>>>>>>>>>>>> Please vote to accept or reject this codebase into the Apache
>>>>>>>>>>>> Harmony
>>>>>>>>>>>> class library :
>>>>>>>>>>>>
>>>>>>>>>>>> [ ] + 1 Accept
>>>>>>>>>>>> [ ] -1 Reject (provide reason below
>>>>>>>>>>>>
>>>>>>>>>>>> Lets let this run 3 days unless a) someone states they need
>>>>>>>>>>>> more time
>>>>>>>>>>>> or b) we get all committer votes before then.
>>>>>>>>>>>>
>>>>>>>>>>>> Go...
>>>>>>>>>>>>
>>>>>>>>>>>> geir
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> Hello Geir,
>>>>>>>>>>
>>>>>>>>>> As this contribution has been accepted for a long time, I'm
>>>>>>>>>> wondering
>>>>>>>>>> when the source code could be put into Harmony SVN.
>>>>>>>>>>
>>>>>>>>>> I'm working on the implementation of java.text.DecimalFormat
>>>>>>>>>> which has
>>>>>>>>>> enhancements on BigDecimal and BigInteger support. Now I just
>>>>>>>>>> use this
>>>>>>>>>> contribution as external jars in Eclipse.
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Mark Hindess <ma...@googlemail.com>
>>>>>>>> IBM Java Technology Centre, UK.
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> Mark Hindess <ma...@googlemail.com>
>>>>>> IBM Java Technology Centre, UK.
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Mark Hindess <ma...@googlemail.com>
>>>> IBM Java Technology Centre, UK.
>>>>
>>>>
>>
>> --
>> Richard Liang
>> China Software Development Lab, IBM
>>
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Dalibor Topic <ro...@kaffe.org>.
On Tue, Mar 21, 2006 at 09:18:45AM -0500, Geir Magnusson Jr wrote:
>
>
> Mikhail Loenko wrote:
> >Hi Richard
> >
> >Did I understand your "1." correctly that this suite (Test for APIs) would
> >be
> >something competing with Sun's TCK?
>
> No - nothing we do would compete. it could be the same functionality,
> but it's not competing in the sense of trying to surpass or displace.
> The TCK is the TCK.
>
> However, having our own suite (using Mauve too...) means that anyone can
> be running a rich set of tests w/o having to have the TCK and all the
> legal pain and suffering that goes along with it.
Yup. As one can see on the Jakarta TCK site, there is a lot of suffering
and legal gymnastics involved. If Sun actually cared about fostering
compatibility between implementations, rather than imposing barriers for
implementors, things would be different.
But alas, Sun currently sees other implementations as a threat to its
business model as a proprietary Java vendor, so one has to deal with
such things until they stop having a business interest in being a
proprietary Java vendor (yeah, right), or go bust (yeah, right), or
actually makes true on the 'participation age' and 'JDK community' talk
(yeah, right).
cheers,
dalibor topic
>
> geir
>
> >
> >Thanks,
> >Mikhail
> >
> >2006/3/21, Richard Liang <ri...@gmail.com>:
> >>Geir Magnusson Jr wrote:
> >>>Good unit tests are going to be testing things that are package
> >>>protected. You can't do that if you aren't in the same package
> >>>(obviously). With the "custom" of putting in things in o.a.h.t are we
> >>>implicitly discouraging good testing practice? Given that this
> >>>o.a.h.t.* pattern comes from Eclipse-land, how do they do it? I
> >>>couldn't imagine that the Eclipse tests don't test package protected
> >>>things.
> >>>
> >>Hello Geir,
> >>
> >>Maybe we should have two types of test suites:
> >>1. Test for APIs including public and protected methods which could be
> >>run against different Java SE implementations.
> >>==>> If we want to test a protected method of a class, we could mock a
> >>subclass of this class. And write test case against the subclass.
> >>(Protected methods are accessible to subclass)
> >>
> >>2. Test for internal implementation which may include tests for package
> >>private methods and tests for other internal-used classes.
> >>==>>We must put the tests into the same package if we want to test
> >>package private methods of a class.
> >>
> >>These are just some rough thinking ;-) Any comments? Thanks a lot.
> >>>I've been short of Round Tuits lately, but I still would like to
> >>>investigate a test harness that helps us by mitigating the security
> >>>issues...
> >>>
> >>>geir
> >>>
> >>>Mark Hindess wrote:
> >>>>I thought the crucial thing was that tests should be in a separate
> >>>>namespace not in the namespace of the package they are testing (at
> >>>>least not unless it was absolutely necessary).
> >>>>-Mark.
> >>>>
> >>>>On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>>>I'm doing it now.
> >>>>>
> >>>>>I need to go back and stare at our discussion on test setup, because
> >>>>>I'm
> >>>>> still not a raving fan of o.a.h.test....
> >>>>>
> >>>>>geir
> >>>>>
> >>>>>Mark Hindess wrote:
> >>>>>>Don't worry, you'd have to be less subtle for me to take something
> >>>>>>as criticism.
> >>>>>>
> >>>>>>I've had an attempt at moving beans out - HARMONY-218. If that gets
> >>>>>>committed I'll do the other too.
> >>>>>>
> >>>>>>-Mark.
> >>>>>>
> >>>>>>On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>>>>>That wasn't a criticism, btw. It seemed like a natural thing to
> >>>>>>>do when
> >>>>>>>I first saw it, but when I was actually dealing w/ it, my opinion
> >>>>>>>changed.
> >>>>>>>
> >>>>>>>Yah, split away! That was going to be my next question, how to
> >>>>>>>split..
> >>>>>>>
> >>>>>>>geir
> >>>>>>>
> >>>>>>>Mark Hindess wrote:
> >>>>>>>>Fair enough.
> >>>>>>>>
> >>>>>>>>Mind if I redo the script/patch to split the three modules to match
> >>>>>>>>the structure of the others? That is, into separate modules/math,
> >>>>>>>>modules/beans, modules/regex directories?
> >>>>>>>>
> >>>>>>>>Regards,
> >>>>>>>> Mark.
> >>>>>>>>
> >>>>>>>>On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>>>>>>>I just committed. There was some delay because of a missing
> >>>>>>>>>CCLA. Sorry.
> >>>>>>>>>
> >>>>>>>>>I've committed the code as is from the JIRA. I'm going to do
> >>>>>>>>>some basic
> >>>>>>>>>cleanup and then look at hte patches to integrate.
> >>>>>>>>>
> >>>>>>>>>Looking at this (and 88?) I think that this "add patches"
> >>>>>>>>>approach is a
> >>>>>>>>>bad one, because it complicates what this JIRA is now.
> >>>>>>>>>
> >>>>>>>>>In the future, I think we should just create new JIRA's for
> >>>>>>>>>add-ons (if
> >>>>>>>>>the add-on contributor isn't the contributor of the original
> >>>>>>>>>JIRA) and
> >>>>>>>>>just link them so they are easy to keep track of...
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>Richard Liang wrote:
> >>>>>>>>>>Geir Magnusson Jr wrote:
> >>>>>>>>>>>Despite a touch of trouble with the packaging of the
> >>>>>>>>>>>contribution, it
> >>>>>>>>>>>passed with flying colors ( or 'colours', for our UK friends...)
> >>>>>>>>>>>
> >>>>>>>>>>>+1 from :
> >>>>>>>>>>>
> >>>>>>>>>>>Geir
> >>>>>>>>>>>Stefano
> >>>>>>>>>>>Dims
> >>>>>>>>>>>Tim
> >>>>>>>>>>>Leo
> >>>>>>>>>>>
> >>>>>>>>>>>In it comes....
> >>>>>>>>>>>
> >>>>>>>>>>>Geir Magnusson Jr wrote:
> >>>>>>>>>>>>I have received the ACQs and the BCC for Harmony-39, so I can
> >>>>>>>>>>>>assert
> >>>>>>>>>>>>that the critical provenance paperwork is in order (although
> >>>>>>>>>>>>not in
> >>>>>>>>>>>>SVN yet).
> >>>>>>>>>>>>
> >>>>>>>>>>>>Please vote to accept or reject this codebase into the Apache
> >>>>>>>>>>>>Harmony
> >>>>>>>>>>>>class library :
> >>>>>>>>>>>>
> >>>>>>>>>>>>[ ] + 1 Accept
> >>>>>>>>>>>>[ ] -1 Reject (provide reason below
> >>>>>>>>>>>>
> >>>>>>>>>>>>Lets let this run 3 days unless a) someone states they need
> >>>>>>>>>>>>more time
> >>>>>>>>>>>>or b) we get all committer votes before then.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Go...
> >>>>>>>>>>>>
> >>>>>>>>>>>>geir
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>Hello Geir,
> >>>>>>>>>>
> >>>>>>>>>>As this contribution has been accepted for a long time, I'm
> >>>>>>>>>>wondering
> >>>>>>>>>>when the source code could be put into Harmony SVN.
> >>>>>>>>>>
> >>>>>>>>>>I'm working on the implementation of java.text.DecimalFormat
> >>>>>>>>>>which has
> >>>>>>>>>>enhancements on BigDecimal and BigInteger support. Now I just
> >>>>>>>>>>use this
> >>>>>>>>>>contribution as external jars in Eclipse.
> >>>>>>>>>>
> >>>>>>>>--
> >>>>>>>>Mark Hindess <ma...@googlemail.com>
> >>>>>>>>IBM Java Technology Centre, UK.
> >>>>>>>>
> >>>>>>>>
> >>>>>>--
> >>>>>>Mark Hindess <ma...@googlemail.com>
> >>>>>>IBM Java Technology Centre, UK.
> >>>>>>
> >>>>>>
> >>>>
> >>>>--
> >>>>Mark Hindess <ma...@googlemail.com>
> >>>>IBM Java Technology Centre, UK.
> >>>>
> >>>>
> >>
> >>--
> >>Richard Liang
> >>China Software Development Lab, IBM
> >>
> >>
> >>
> >
> >
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Mikhail Loenko wrote:
> Hi Richard
>
> Did I understand your "1." correctly that this suite (Test for APIs) would be
> something competing with Sun's TCK?
No - nothing we do would compete. it could be the same functionality,
but it's not competing in the sense of trying to surpass or displace.
The TCK is the TCK.
However, having our own suite (using Mauve too...) means that anyone can
be running a rich set of tests w/o having to have the TCK and all the
legal pain and suffering that goes along with it.
geir
>
> Thanks,
> Mikhail
>
> 2006/3/21, Richard Liang <ri...@gmail.com>:
>> Geir Magnusson Jr wrote:
>>> Good unit tests are going to be testing things that are package
>>> protected. You can't do that if you aren't in the same package
>>> (obviously). With the "custom" of putting in things in o.a.h.t are we
>>> implicitly discouraging good testing practice? Given that this
>>> o.a.h.t.* pattern comes from Eclipse-land, how do they do it? I
>>> couldn't imagine that the Eclipse tests don't test package protected
>>> things.
>>>
>> Hello Geir,
>>
>> Maybe we should have two types of test suites:
>> 1. Test for APIs including public and protected methods which could be
>> run against different Java SE implementations.
>> ==>> If we want to test a protected method of a class, we could mock a
>> subclass of this class. And write test case against the subclass.
>> (Protected methods are accessible to subclass)
>>
>> 2. Test for internal implementation which may include tests for package
>> private methods and tests for other internal-used classes.
>> ==>>We must put the tests into the same package if we want to test
>> package private methods of a class.
>>
>> These are just some rough thinking ;-) Any comments? Thanks a lot.
>>> I've been short of Round Tuits lately, but I still would like to
>>> investigate a test harness that helps us by mitigating the security
>>> issues...
>>>
>>> geir
>>>
>>> Mark Hindess wrote:
>>>> I thought the crucial thing was that tests should be in a separate
>>>> namespace not in the namespace of the package they are testing (at
>>>> least not unless it was absolutely necessary).
>>>> -Mark.
>>>>
>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>> I'm doing it now.
>>>>>
>>>>> I need to go back and stare at our discussion on test setup, because
>>>>> I'm
>>>>> still not a raving fan of o.a.h.test....
>>>>>
>>>>> geir
>>>>>
>>>>> Mark Hindess wrote:
>>>>>> Don't worry, you'd have to be less subtle for me to take something
>>>>>> as criticism.
>>>>>>
>>>>>> I've had an attempt at moving beans out - HARMONY-218. If that gets
>>>>>> committed I'll do the other too.
>>>>>>
>>>>>> -Mark.
>>>>>>
>>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>>> That wasn't a criticism, btw. It seemed like a natural thing to
>>>>>>> do when
>>>>>>> I first saw it, but when I was actually dealing w/ it, my opinion
>>>>>>> changed.
>>>>>>>
>>>>>>> Yah, split away! That was going to be my next question, how to
>>>>>>> split..
>>>>>>>
>>>>>>> geir
>>>>>>>
>>>>>>> Mark Hindess wrote:
>>>>>>>> Fair enough.
>>>>>>>>
>>>>>>>> Mind if I redo the script/patch to split the three modules to match
>>>>>>>> the structure of the others? That is, into separate modules/math,
>>>>>>>> modules/beans, modules/regex directories?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mark.
>>>>>>>>
>>>>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>>>>> I just committed. There was some delay because of a missing
>>>>>>>>> CCLA. Sorry.
>>>>>>>>>
>>>>>>>>> I've committed the code as is from the JIRA. I'm going to do
>>>>>>>>> some basic
>>>>>>>>> cleanup and then look at hte patches to integrate.
>>>>>>>>>
>>>>>>>>> Looking at this (and 88?) I think that this "add patches"
>>>>>>>>> approach is a
>>>>>>>>> bad one, because it complicates what this JIRA is now.
>>>>>>>>>
>>>>>>>>> In the future, I think we should just create new JIRA's for
>>>>>>>>> add-ons (if
>>>>>>>>> the add-on contributor isn't the contributor of the original
>>>>>>>>> JIRA) and
>>>>>>>>> just link them so they are easy to keep track of...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Richard Liang wrote:
>>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>>> Despite a touch of trouble with the packaging of the
>>>>>>>>>>> contribution, it
>>>>>>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
>>>>>>>>>>>
>>>>>>>>>>> +1 from :
>>>>>>>>>>>
>>>>>>>>>>> Geir
>>>>>>>>>>> Stefano
>>>>>>>>>>> Dims
>>>>>>>>>>> Tim
>>>>>>>>>>> Leo
>>>>>>>>>>>
>>>>>>>>>>> In it comes....
>>>>>>>>>>>
>>>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can
>>>>>>>>>>>> assert
>>>>>>>>>>>> that the critical provenance paperwork is in order (although
>>>>>>>>>>>> not in
>>>>>>>>>>>> SVN yet).
>>>>>>>>>>>>
>>>>>>>>>>>> Please vote to accept or reject this codebase into the Apache
>>>>>>>>>>>> Harmony
>>>>>>>>>>>> class library :
>>>>>>>>>>>>
>>>>>>>>>>>> [ ] + 1 Accept
>>>>>>>>>>>> [ ] -1 Reject (provide reason below
>>>>>>>>>>>>
>>>>>>>>>>>> Lets let this run 3 days unless a) someone states they need
>>>>>>>>>>>> more time
>>>>>>>>>>>> or b) we get all committer votes before then.
>>>>>>>>>>>>
>>>>>>>>>>>> Go...
>>>>>>>>>>>>
>>>>>>>>>>>> geir
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> Hello Geir,
>>>>>>>>>>
>>>>>>>>>> As this contribution has been accepted for a long time, I'm
>>>>>>>>>> wondering
>>>>>>>>>> when the source code could be put into Harmony SVN.
>>>>>>>>>>
>>>>>>>>>> I'm working on the implementation of java.text.DecimalFormat
>>>>>>>>>> which has
>>>>>>>>>> enhancements on BigDecimal and BigInteger support. Now I just
>>>>>>>>>> use this
>>>>>>>>>> contribution as external jars in Eclipse.
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Mark Hindess <ma...@googlemail.com>
>>>>>>>> IBM Java Technology Centre, UK.
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> Mark Hindess <ma...@googlemail.com>
>>>>>> IBM Java Technology Centre, UK.
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Mark Hindess <ma...@googlemail.com>
>>>> IBM Java Technology Centre, UK.
>>>>
>>>>
>>
>> --
>> Richard Liang
>> China Software Development Lab, IBM
>>
>>
>>
>
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Richard
Did I understand your "1." correctly that this suite (Test for APIs) would be
something competing with Sun's TCK?
Thanks,
Mikhail
2006/3/21, Richard Liang <ri...@gmail.com>:
> Geir Magnusson Jr wrote:
> > Good unit tests are going to be testing things that are package
> > protected. You can't do that if you aren't in the same package
> > (obviously). With the "custom" of putting in things in o.a.h.t are we
> > implicitly discouraging good testing practice? Given that this
> > o.a.h.t.* pattern comes from Eclipse-land, how do they do it? I
> > couldn't imagine that the Eclipse tests don't test package protected
> > things.
> >
> Hello Geir,
>
> Maybe we should have two types of test suites:
> 1. Test for APIs including public and protected methods which could be
> run against different Java SE implementations.
> ==>> If we want to test a protected method of a class, we could mock a
> subclass of this class. And write test case against the subclass.
> (Protected methods are accessible to subclass)
>
> 2. Test for internal implementation which may include tests for package
> private methods and tests for other internal-used classes.
> ==>>We must put the tests into the same package if we want to test
> package private methods of a class.
>
> These are just some rough thinking ;-) Any comments? Thanks a lot.
> > I've been short of Round Tuits lately, but I still would like to
> > investigate a test harness that helps us by mitigating the security
> > issues...
> >
> > geir
> >
> > Mark Hindess wrote:
> >> I thought the crucial thing was that tests should be in a separate
> >> namespace not in the namespace of the package they are testing (at
> >> least not unless it was absolutely necessary).
> >> -Mark.
> >>
> >> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>> I'm doing it now.
> >>>
> >>> I need to go back and stare at our discussion on test setup, because
> >>> I'm
> >>> still not a raving fan of o.a.h.test....
> >>>
> >>> geir
> >>>
> >>> Mark Hindess wrote:
> >>>> Don't worry, you'd have to be less subtle for me to take something
> >>>> as criticism.
> >>>>
> >>>> I've had an attempt at moving beans out - HARMONY-218. If that gets
> >>>> committed I'll do the other too.
> >>>>
> >>>> -Mark.
> >>>>
> >>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>>> That wasn't a criticism, btw. It seemed like a natural thing to
> >>>>> do when
> >>>>> I first saw it, but when I was actually dealing w/ it, my opinion
> >>>>> changed.
> >>>>>
> >>>>> Yah, split away! That was going to be my next question, how to
> >>>>> split..
> >>>>>
> >>>>> geir
> >>>>>
> >>>>> Mark Hindess wrote:
> >>>>>> Fair enough.
> >>>>>>
> >>>>>> Mind if I redo the script/patch to split the three modules to match
> >>>>>> the structure of the others? That is, into separate modules/math,
> >>>>>> modules/beans, modules/regex directories?
> >>>>>>
> >>>>>> Regards,
> >>>>>> Mark.
> >>>>>>
> >>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>>>>> I just committed. There was some delay because of a missing
> >>>>>>> CCLA. Sorry.
> >>>>>>>
> >>>>>>> I've committed the code as is from the JIRA. I'm going to do
> >>>>>>> some basic
> >>>>>>> cleanup and then look at hte patches to integrate.
> >>>>>>>
> >>>>>>> Looking at this (and 88?) I think that this "add patches"
> >>>>>>> approach is a
> >>>>>>> bad one, because it complicates what this JIRA is now.
> >>>>>>>
> >>>>>>> In the future, I think we should just create new JIRA's for
> >>>>>>> add-ons (if
> >>>>>>> the add-on contributor isn't the contributor of the original
> >>>>>>> JIRA) and
> >>>>>>> just link them so they are easy to keep track of...
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Richard Liang wrote:
> >>>>>>>> Geir Magnusson Jr wrote:
> >>>>>>>>> Despite a touch of trouble with the packaging of the
> >>>>>>>>> contribution, it
> >>>>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
> >>>>>>>>>
> >>>>>>>>> +1 from :
> >>>>>>>>>
> >>>>>>>>> Geir
> >>>>>>>>> Stefano
> >>>>>>>>> Dims
> >>>>>>>>> Tim
> >>>>>>>>> Leo
> >>>>>>>>>
> >>>>>>>>> In it comes....
> >>>>>>>>>
> >>>>>>>>> Geir Magnusson Jr wrote:
> >>>>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can
> >>>>>>>>>> assert
> >>>>>>>>>> that the critical provenance paperwork is in order (although
> >>>>>>>>>> not in
> >>>>>>>>>> SVN yet).
> >>>>>>>>>>
> >>>>>>>>>> Please vote to accept or reject this codebase into the Apache
> >>>>>>>>>> Harmony
> >>>>>>>>>> class library :
> >>>>>>>>>>
> >>>>>>>>>> [ ] + 1 Accept
> >>>>>>>>>> [ ] -1 Reject (provide reason below
> >>>>>>>>>>
> >>>>>>>>>> Lets let this run 3 days unless a) someone states they need
> >>>>>>>>>> more time
> >>>>>>>>>> or b) we get all committer votes before then.
> >>>>>>>>>>
> >>>>>>>>>> Go...
> >>>>>>>>>>
> >>>>>>>>>> geir
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> Hello Geir,
> >>>>>>>>
> >>>>>>>> As this contribution has been accepted for a long time, I'm
> >>>>>>>> wondering
> >>>>>>>> when the source code could be put into Harmony SVN.
> >>>>>>>>
> >>>>>>>> I'm working on the implementation of java.text.DecimalFormat
> >>>>>>>> which has
> >>>>>>>> enhancements on BigDecimal and BigInteger support. Now I just
> >>>>>>>> use this
> >>>>>>>> contribution as external jars in Eclipse.
> >>>>>>>>
> >>>>>> --
> >>>>>> Mark Hindess <ma...@googlemail.com>
> >>>>>> IBM Java Technology Centre, UK.
> >>>>>>
> >>>>>>
> >>>>
> >>>> --
> >>>> Mark Hindess <ma...@googlemail.com>
> >>>> IBM Java Technology Centre, UK.
> >>>>
> >>>>
> >>
> >>
> >> --
> >> Mark Hindess <ma...@googlemail.com>
> >> IBM Java Technology Centre, UK.
> >>
> >>
> >
>
>
> --
> Richard Liang
> China Software Development Lab, IBM
>
>
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Richard Liang <ri...@gmail.com>.
Geir Magnusson Jr wrote:
> Good unit tests are going to be testing things that are package
> protected. You can't do that if you aren't in the same package
> (obviously). With the "custom" of putting in things in o.a.h.t are we
> implicitly discouraging good testing practice? Given that this
> o.a.h.t.* pattern comes from Eclipse-land, how do they do it? I
> couldn't imagine that the Eclipse tests don't test package protected
> things.
>
Hello Geir,
Maybe we should have two types of test suites:
1. Test for APIs including public and protected methods which could be
run against different Java SE implementations.
==>> If we want to test a protected method of a class, we could mock a
subclass of this class. And write test case against the subclass.
(Protected methods are accessible to subclass)
2. Test for internal implementation which may include tests for package
private methods and tests for other internal-used classes.
==>>We must put the tests into the same package if we want to test
package private methods of a class.
These are just some rough thinking ;-) Any comments? Thanks a lot.
> I've been short of Round Tuits lately, but I still would like to
> investigate a test harness that helps us by mitigating the security
> issues...
>
> geir
>
> Mark Hindess wrote:
>> I thought the crucial thing was that tests should be in a separate
>> namespace not in the namespace of the package they are testing (at
>> least not unless it was absolutely necessary).
>> -Mark.
>>
>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>> I'm doing it now.
>>>
>>> I need to go back and stare at our discussion on test setup, because
>>> I'm
>>> still not a raving fan of o.a.h.test....
>>>
>>> geir
>>>
>>> Mark Hindess wrote:
>>>> Don't worry, you'd have to be less subtle for me to take something
>>>> as criticism.
>>>>
>>>> I've had an attempt at moving beans out - HARMONY-218. If that gets
>>>> committed I'll do the other too.
>>>>
>>>> -Mark.
>>>>
>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>> That wasn't a criticism, btw. It seemed like a natural thing to
>>>>> do when
>>>>> I first saw it, but when I was actually dealing w/ it, my opinion
>>>>> changed.
>>>>>
>>>>> Yah, split away! That was going to be my next question, how to
>>>>> split..
>>>>>
>>>>> geir
>>>>>
>>>>> Mark Hindess wrote:
>>>>>> Fair enough.
>>>>>>
>>>>>> Mind if I redo the script/patch to split the three modules to match
>>>>>> the structure of the others? That is, into separate modules/math,
>>>>>> modules/beans, modules/regex directories?
>>>>>>
>>>>>> Regards,
>>>>>> Mark.
>>>>>>
>>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>>> I just committed. There was some delay because of a missing
>>>>>>> CCLA. Sorry.
>>>>>>>
>>>>>>> I've committed the code as is from the JIRA. I'm going to do
>>>>>>> some basic
>>>>>>> cleanup and then look at hte patches to integrate.
>>>>>>>
>>>>>>> Looking at this (and 88?) I think that this "add patches"
>>>>>>> approach is a
>>>>>>> bad one, because it complicates what this JIRA is now.
>>>>>>>
>>>>>>> In the future, I think we should just create new JIRA's for
>>>>>>> add-ons (if
>>>>>>> the add-on contributor isn't the contributor of the original
>>>>>>> JIRA) and
>>>>>>> just link them so they are easy to keep track of...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Richard Liang wrote:
>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>> Despite a touch of trouble with the packaging of the
>>>>>>>>> contribution, it
>>>>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
>>>>>>>>>
>>>>>>>>> +1 from :
>>>>>>>>>
>>>>>>>>> Geir
>>>>>>>>> Stefano
>>>>>>>>> Dims
>>>>>>>>> Tim
>>>>>>>>> Leo
>>>>>>>>>
>>>>>>>>> In it comes....
>>>>>>>>>
>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can
>>>>>>>>>> assert
>>>>>>>>>> that the critical provenance paperwork is in order (although
>>>>>>>>>> not in
>>>>>>>>>> SVN yet).
>>>>>>>>>>
>>>>>>>>>> Please vote to accept or reject this codebase into the Apache
>>>>>>>>>> Harmony
>>>>>>>>>> class library :
>>>>>>>>>>
>>>>>>>>>> [ ] + 1 Accept
>>>>>>>>>> [ ] -1 Reject (provide reason below
>>>>>>>>>>
>>>>>>>>>> Lets let this run 3 days unless a) someone states they need
>>>>>>>>>> more time
>>>>>>>>>> or b) we get all committer votes before then.
>>>>>>>>>>
>>>>>>>>>> Go...
>>>>>>>>>>
>>>>>>>>>> geir
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> Hello Geir,
>>>>>>>>
>>>>>>>> As this contribution has been accepted for a long time, I'm
>>>>>>>> wondering
>>>>>>>> when the source code could be put into Harmony SVN.
>>>>>>>>
>>>>>>>> I'm working on the implementation of java.text.DecimalFormat
>>>>>>>> which has
>>>>>>>> enhancements on BigDecimal and BigInteger support. Now I just
>>>>>>>> use this
>>>>>>>> contribution as external jars in Eclipse.
>>>>>>>>
>>>>>> --
>>>>>> Mark Hindess <ma...@googlemail.com>
>>>>>> IBM Java Technology Centre, UK.
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Mark Hindess <ma...@googlemail.com>
>>>> IBM Java Technology Centre, UK.
>>>>
>>>>
>>
>>
>> --
>> Mark Hindess <ma...@googlemail.com>
>> IBM Java Technology Centre, UK.
>>
>>
>
--
Richard Liang
China Software Development Lab, IBM
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Good unit tests are going to be testing things that are package
protected. You can't do that if you aren't in the same package
(obviously). With the "custom" of putting in things in o.a.h.t are we
implicitly discouraging good testing practice? Given that this
o.a.h.t.* pattern comes from Eclipse-land, how do they do it? I
couldn't imagine that the Eclipse tests don't test package protected things.
I've been short of Round Tuits lately, but I still would like to
investigate a test harness that helps us by mitigating the security
issues...
geir
Mark Hindess wrote:
> I thought the crucial thing was that tests should be in a separate
> namespace not in the namespace of the package they are testing (at
> least not unless it was absolutely necessary).
> -Mark.
>
> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> I'm doing it now.
>>
>> I need to go back and stare at our discussion on test setup, because I'm
>> still not a raving fan of o.a.h.test....
>>
>> geir
>>
>> Mark Hindess wrote:
>>> Don't worry, you'd have to be less subtle for me to take something as criticism.
>>>
>>> I've had an attempt at moving beans out - HARMONY-218. If that gets
>>> committed I'll do the other too.
>>>
>>> -Mark.
>>>
>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>> That wasn't a criticism, btw. It seemed like a natural thing to do when
>>>> I first saw it, but when I was actually dealing w/ it, my opinion changed.
>>>>
>>>> Yah, split away! That was going to be my next question, how to split..
>>>>
>>>> geir
>>>>
>>>> Mark Hindess wrote:
>>>>> Fair enough.
>>>>>
>>>>> Mind if I redo the script/patch to split the three modules to match
>>>>> the structure of the others? That is, into separate modules/math,
>>>>> modules/beans, modules/regex directories?
>>>>>
>>>>> Regards,
>>>>> Mark.
>>>>>
>>>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>> I just committed. There was some delay because of a missing CCLA. Sorry.
>>>>>>
>>>>>> I've committed the code as is from the JIRA. I'm going to do some basic
>>>>>> cleanup and then look at hte patches to integrate.
>>>>>>
>>>>>> Looking at this (and 88?) I think that this "add patches" approach is a
>>>>>> bad one, because it complicates what this JIRA is now.
>>>>>>
>>>>>> In the future, I think we should just create new JIRA's for add-ons (if
>>>>>> the add-on contributor isn't the contributor of the original JIRA) and
>>>>>> just link them so they are easy to keep track of...
>>>>>>
>>>>>>
>>>>>>
>>>>>> Richard Liang wrote:
>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>> Despite a touch of trouble with the packaging of the contribution, it
>>>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
>>>>>>>>
>>>>>>>> +1 from :
>>>>>>>>
>>>>>>>> Geir
>>>>>>>> Stefano
>>>>>>>> Dims
>>>>>>>> Tim
>>>>>>>> Leo
>>>>>>>>
>>>>>>>> In it comes....
>>>>>>>>
>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can assert
>>>>>>>>> that the critical provenance paperwork is in order (although not in
>>>>>>>>> SVN yet).
>>>>>>>>>
>>>>>>>>> Please vote to accept or reject this codebase into the Apache Harmony
>>>>>>>>> class library :
>>>>>>>>>
>>>>>>>>> [ ] + 1 Accept
>>>>>>>>> [ ] -1 Reject (provide reason below
>>>>>>>>>
>>>>>>>>> Lets let this run 3 days unless a) someone states they need more time
>>>>>>>>> or b) we get all committer votes before then.
>>>>>>>>>
>>>>>>>>> Go...
>>>>>>>>>
>>>>>>>>> geir
>>>>>>>>>
>>>>>>>>>
>>>>>>> Hello Geir,
>>>>>>>
>>>>>>> As this contribution has been accepted for a long time, I'm wondering
>>>>>>> when the source code could be put into Harmony SVN.
>>>>>>>
>>>>>>> I'm working on the implementation of java.text.DecimalFormat which has
>>>>>>> enhancements on BigDecimal and BigInteger support. Now I just use this
>>>>>>> contribution as external jars in Eclipse.
>>>>>>>
>>>>> --
>>>>> Mark Hindess <ma...@googlemail.com>
>>>>> IBM Java Technology Centre, UK.
>>>>>
>>>>>
>>>
>>> --
>>> Mark Hindess <ma...@googlemail.com>
>>> IBM Java Technology Centre, UK.
>>>
>>>
>
>
> --
> Mark Hindess <ma...@googlemail.com>
> IBM Java Technology Centre, UK.
>
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Mark Hindess <ma...@googlemail.com>.
I thought the crucial thing was that tests should be in a separate
namespace not in the namespace of the package they are testing (at
least not unless it was absolutely necessary).
-Mark.
On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> I'm doing it now.
>
> I need to go back and stare at our discussion on test setup, because I'm
> still not a raving fan of o.a.h.test....
>
> geir
>
> Mark Hindess wrote:
> > Don't worry, you'd have to be less subtle for me to take something as criticism.
> >
> > I've had an attempt at moving beans out - HARMONY-218. If that gets
> > committed I'll do the other too.
> >
> > -Mark.
> >
> > On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> That wasn't a criticism, btw. It seemed like a natural thing to do when
> >> I first saw it, but when I was actually dealing w/ it, my opinion changed.
> >>
> >> Yah, split away! That was going to be my next question, how to split....
> >>
> >> geir
> >>
> >> Mark Hindess wrote:
> >>> Fair enough.
> >>>
> >>> Mind if I redo the script/patch to split the three modules to match
> >>> the structure of the others? That is, into separate modules/math,
> >>> modules/beans, modules/regex directories?
> >>>
> >>> Regards,
> >>> Mark.
> >>>
> >>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>> I just committed. There was some delay because of a missing CCLA. Sorry.
> >>>>
> >>>> I've committed the code as is from the JIRA. I'm going to do some basic
> >>>> cleanup and then look at hte patches to integrate.
> >>>>
> >>>> Looking at this (and 88?) I think that this "add patches" approach is a
> >>>> bad one, because it complicates what this JIRA is now.
> >>>>
> >>>> In the future, I think we should just create new JIRA's for add-ons (if
> >>>> the add-on contributor isn't the contributor of the original JIRA) and
> >>>> just link them so they are easy to keep track of...
> >>>>
> >>>>
> >>>>
> >>>> Richard Liang wrote:
> >>>>> Geir Magnusson Jr wrote:
> >>>>>> Despite a touch of trouble with the packaging of the contribution, it
> >>>>>> passed with flying colors ( or 'colours', for our UK friends...)
> >>>>>>
> >>>>>> +1 from :
> >>>>>>
> >>>>>> Geir
> >>>>>> Stefano
> >>>>>> Dims
> >>>>>> Tim
> >>>>>> Leo
> >>>>>>
> >>>>>> In it comes....
> >>>>>>
> >>>>>> Geir Magnusson Jr wrote:
> >>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can assert
> >>>>>>> that the critical provenance paperwork is in order (although not in
> >>>>>>> SVN yet).
> >>>>>>>
> >>>>>>> Please vote to accept or reject this codebase into the Apache Harmony
> >>>>>>> class library :
> >>>>>>>
> >>>>>>> [ ] + 1 Accept
> >>>>>>> [ ] -1 Reject (provide reason below
> >>>>>>>
> >>>>>>> Lets let this run 3 days unless a) someone states they need more time
> >>>>>>> or b) we get all committer votes before then.
> >>>>>>>
> >>>>>>> Go...
> >>>>>>>
> >>>>>>> geir
> >>>>>>>
> >>>>>>>
> >>>>> Hello Geir,
> >>>>>
> >>>>> As this contribution has been accepted for a long time, I'm wondering
> >>>>> when the source code could be put into Harmony SVN.
> >>>>>
> >>>>> I'm working on the implementation of java.text.DecimalFormat which has
> >>>>> enhancements on BigDecimal and BigInteger support. Now I just use this
> >>>>> contribution as external jars in Eclipse.
> >>>>>
> >>>
> >>> --
> >>> Mark Hindess <ma...@googlemail.com>
> >>> IBM Java Technology Centre, UK.
> >>>
> >>>
> >
> >
> > --
> > Mark Hindess <ma...@googlemail.com>
> > IBM Java Technology Centre, UK.
> >
> >
>
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I'm doing it now.
I need to go back and stare at our discussion on test setup, because I'm
still not a raving fan of o.a.h.test....
geir
Mark Hindess wrote:
> Don't worry, you'd have to be less subtle for me to take something as criticism.
>
> I've had an attempt at moving beans out - HARMONY-218. If that gets
> committed I'll do the other too.
>
> -Mark.
>
> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> That wasn't a criticism, btw. It seemed like a natural thing to do when
>> I first saw it, but when I was actually dealing w/ it, my opinion changed.
>>
>> Yah, split away! That was going to be my next question, how to split....
>>
>> geir
>>
>> Mark Hindess wrote:
>>> Fair enough.
>>>
>>> Mind if I redo the script/patch to split the three modules to match
>>> the structure of the others? That is, into separate modules/math,
>>> modules/beans, modules/regex directories?
>>>
>>> Regards,
>>> Mark.
>>>
>>> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>> I just committed. There was some delay because of a missing CCLA. Sorry.
>>>>
>>>> I've committed the code as is from the JIRA. I'm going to do some basic
>>>> cleanup and then look at hte patches to integrate.
>>>>
>>>> Looking at this (and 88?) I think that this "add patches" approach is a
>>>> bad one, because it complicates what this JIRA is now.
>>>>
>>>> In the future, I think we should just create new JIRA's for add-ons (if
>>>> the add-on contributor isn't the contributor of the original JIRA) and
>>>> just link them so they are easy to keep track of...
>>>>
>>>>
>>>>
>>>> Richard Liang wrote:
>>>>> Geir Magnusson Jr wrote:
>>>>>> Despite a touch of trouble with the packaging of the contribution, it
>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
>>>>>>
>>>>>> +1 from :
>>>>>>
>>>>>> Geir
>>>>>> Stefano
>>>>>> Dims
>>>>>> Tim
>>>>>> Leo
>>>>>>
>>>>>> In it comes....
>>>>>>
>>>>>> Geir Magnusson Jr wrote:
>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can assert
>>>>>>> that the critical provenance paperwork is in order (although not in
>>>>>>> SVN yet).
>>>>>>>
>>>>>>> Please vote to accept or reject this codebase into the Apache Harmony
>>>>>>> class library :
>>>>>>>
>>>>>>> [ ] + 1 Accept
>>>>>>> [ ] -1 Reject (provide reason below
>>>>>>>
>>>>>>> Lets let this run 3 days unless a) someone states they need more time
>>>>>>> or b) we get all committer votes before then.
>>>>>>>
>>>>>>> Go...
>>>>>>>
>>>>>>> geir
>>>>>>>
>>>>>>>
>>>>> Hello Geir,
>>>>>
>>>>> As this contribution has been accepted for a long time, I'm wondering
>>>>> when the source code could be put into Harmony SVN.
>>>>>
>>>>> I'm working on the implementation of java.text.DecimalFormat which has
>>>>> enhancements on BigDecimal and BigInteger support. Now I just use this
>>>>> contribution as external jars in Eclipse.
>>>>>
>>>
>>> --
>>> Mark Hindess <ma...@googlemail.com>
>>> IBM Java Technology Centre, UK.
>>>
>>>
>
>
> --
> Mark Hindess <ma...@googlemail.com>
> IBM Java Technology Centre, UK.
>
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Mark Hindess <ma...@googlemail.com>.
Don't worry, you'd have to be less subtle for me to take something as criticism.
I've had an attempt at moving beans out - HARMONY-218. If that gets
committed I'll do the other too.
-Mark.
On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> That wasn't a criticism, btw. It seemed like a natural thing to do when
> I first saw it, but when I was actually dealing w/ it, my opinion changed.
>
> Yah, split away! That was going to be my next question, how to split....
>
> geir
>
> Mark Hindess wrote:
> > Fair enough.
> >
> > Mind if I redo the script/patch to split the three modules to match
> > the structure of the others? That is, into separate modules/math,
> > modules/beans, modules/regex directories?
> >
> > Regards,
> > Mark.
> >
> > On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> I just committed. There was some delay because of a missing CCLA. Sorry.
> >>
> >> I've committed the code as is from the JIRA. I'm going to do some basic
> >> cleanup and then look at hte patches to integrate.
> >>
> >> Looking at this (and 88?) I think that this "add patches" approach is a
> >> bad one, because it complicates what this JIRA is now.
> >>
> >> In the future, I think we should just create new JIRA's for add-ons (if
> >> the add-on contributor isn't the contributor of the original JIRA) and
> >> just link them so they are easy to keep track of...
> >>
> >>
> >>
> >> Richard Liang wrote:
> >>> Geir Magnusson Jr wrote:
> >>>> Despite a touch of trouble with the packaging of the contribution, it
> >>>> passed with flying colors ( or 'colours', for our UK friends...)
> >>>>
> >>>> +1 from :
> >>>>
> >>>> Geir
> >>>> Stefano
> >>>> Dims
> >>>> Tim
> >>>> Leo
> >>>>
> >>>> In it comes....
> >>>>
> >>>> Geir Magnusson Jr wrote:
> >>>>> I have received the ACQs and the BCC for Harmony-39, so I can assert
> >>>>> that the critical provenance paperwork is in order (although not in
> >>>>> SVN yet).
> >>>>>
> >>>>> Please vote to accept or reject this codebase into the Apache Harmony
> >>>>> class library :
> >>>>>
> >>>>> [ ] + 1 Accept
> >>>>> [ ] -1 Reject (provide reason below
> >>>>>
> >>>>> Lets let this run 3 days unless a) someone states they need more time
> >>>>> or b) we get all committer votes before then.
> >>>>>
> >>>>> Go...
> >>>>>
> >>>>> geir
> >>>>>
> >>>>>
> >>> Hello Geir,
> >>>
> >>> As this contribution has been accepted for a long time, I'm wondering
> >>> when the source code could be put into Harmony SVN.
> >>>
> >>> I'm working on the implementation of java.text.DecimalFormat which has
> >>> enhancements on BigDecimal and BigInteger support. Now I just use this
> >>> contribution as external jars in Eclipse.
> >>>
> >
> >
> > --
> > Mark Hindess <ma...@googlemail.com>
> > IBM Java Technology Centre, UK.
> >
> >
>
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
That wasn't a criticism, btw. It seemed like a natural thing to do when
I first saw it, but when I was actually dealing w/ it, my opinion changed.
Yah, split away! That was going to be my next question, how to split....
geir
Mark Hindess wrote:
> Fair enough.
>
> Mind if I redo the script/patch to split the three modules to match
> the structure of the others? That is, into separate modules/math,
> modules/beans, modules/regex directories?
>
> Regards,
> Mark.
>
> On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> I just committed. There was some delay because of a missing CCLA. Sorry.
>>
>> I've committed the code as is from the JIRA. I'm going to do some basic
>> cleanup and then look at hte patches to integrate.
>>
>> Looking at this (and 88?) I think that this "add patches" approach is a
>> bad one, because it complicates what this JIRA is now.
>>
>> In the future, I think we should just create new JIRA's for add-ons (if
>> the add-on contributor isn't the contributor of the original JIRA) and
>> just link them so they are easy to keep track of...
>>
>>
>>
>> Richard Liang wrote:
>>> Geir Magnusson Jr wrote:
>>>> Despite a touch of trouble with the packaging of the contribution, it
>>>> passed with flying colors ( or 'colours', for our UK friends...)
>>>>
>>>> +1 from :
>>>>
>>>> Geir
>>>> Stefano
>>>> Dims
>>>> Tim
>>>> Leo
>>>>
>>>> In it comes....
>>>>
>>>> Geir Magnusson Jr wrote:
>>>>> I have received the ACQs and the BCC for Harmony-39, so I can assert
>>>>> that the critical provenance paperwork is in order (although not in
>>>>> SVN yet).
>>>>>
>>>>> Please vote to accept or reject this codebase into the Apache Harmony
>>>>> class library :
>>>>>
>>>>> [ ] + 1 Accept
>>>>> [ ] -1 Reject (provide reason below
>>>>>
>>>>> Lets let this run 3 days unless a) someone states they need more time
>>>>> or b) we get all committer votes before then.
>>>>>
>>>>> Go...
>>>>>
>>>>> geir
>>>>>
>>>>>
>>> Hello Geir,
>>>
>>> As this contribution has been accepted for a long time, I'm wondering
>>> when the source code could be put into Harmony SVN.
>>>
>>> I'm working on the implementation of java.text.DecimalFormat which has
>>> enhancements on BigDecimal and BigInteger support. Now I just use this
>>> contribution as external jars in Eclipse.
>>>
>
>
> --
> Mark Hindess <ma...@googlemail.com>
> IBM Java Technology Centre, UK.
>
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Mark Hindess <ma...@googlemail.com>.
Fair enough.
Mind if I redo the script/patch to split the three modules to match
the structure of the others? That is, into separate modules/math,
modules/beans, modules/regex directories?
Regards,
Mark.
On 3/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> I just committed. There was some delay because of a missing CCLA. Sorry.
>
> I've committed the code as is from the JIRA. I'm going to do some basic
> cleanup and then look at hte patches to integrate.
>
> Looking at this (and 88?) I think that this "add patches" approach is a
> bad one, because it complicates what this JIRA is now.
>
> In the future, I think we should just create new JIRA's for add-ons (if
> the add-on contributor isn't the contributor of the original JIRA) and
> just link them so they are easy to keep track of...
>
>
>
> Richard Liang wrote:
> > Geir Magnusson Jr wrote:
> >> Despite a touch of trouble with the packaging of the contribution, it
> >> passed with flying colors ( or 'colours', for our UK friends...)
> >>
> >> +1 from :
> >>
> >> Geir
> >> Stefano
> >> Dims
> >> Tim
> >> Leo
> >>
> >> In it comes....
> >>
> >> Geir Magnusson Jr wrote:
> >>> I have received the ACQs and the BCC for Harmony-39, so I can assert
> >>> that the critical provenance paperwork is in order (although not in
> >>> SVN yet).
> >>>
> >>> Please vote to accept or reject this codebase into the Apache Harmony
> >>> class library :
> >>>
> >>> [ ] + 1 Accept
> >>> [ ] -1 Reject (provide reason below
> >>>
> >>> Lets let this run 3 days unless a) someone states they need more time
> >>> or b) we get all committer votes before then.
> >>>
> >>> Go...
> >>>
> >>> geir
> >>>
> >>>
> >>
> > Hello Geir,
> >
> > As this contribution has been accepted for a long time, I'm wondering
> > when the source code could be put into Harmony SVN.
> >
> > I'm working on the implementation of java.text.DecimalFormat which has
> > enhancements on BigDecimal and BigInteger support. Now I just use this
> > contribution as external jars in Eclipse.
> >
>
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I just committed. There was some delay because of a missing CCLA. Sorry.
I've committed the code as is from the JIRA. I'm going to do some basic
cleanup and then look at hte patches to integrate.
Looking at this (and 88?) I think that this "add patches" approach is a
bad one, because it complicates what this JIRA is now.
In the future, I think we should just create new JIRA's for add-ons (if
the add-on contributor isn't the contributor of the original JIRA) and
just link them so they are easy to keep track of...
Richard Liang wrote:
> Geir Magnusson Jr wrote:
>> Despite a touch of trouble with the packaging of the contribution, it
>> passed with flying colors ( or 'colours', for our UK friends...)
>>
>> +1 from :
>>
>> Geir
>> Stefano
>> Dims
>> Tim
>> Leo
>>
>> In it comes....
>>
>> Geir Magnusson Jr wrote:
>>> I have received the ACQs and the BCC for Harmony-39, so I can assert
>>> that the critical provenance paperwork is in order (although not in
>>> SVN yet).
>>>
>>> Please vote to accept or reject this codebase into the Apache Harmony
>>> class library :
>>>
>>> [ ] + 1 Accept
>>> [ ] -1 Reject (provide reason below
>>>
>>> Lets let this run 3 days unless a) someone states they need more time
>>> or b) we get all committer votes before then.
>>>
>>> Go...
>>>
>>> geir
>>>
>>>
>>
> Hello Geir,
>
> As this contribution has been accepted for a long time, I'm wondering
> when the source code could be put into Harmony SVN.
>
> I'm working on the implementation of java.text.DecimalFormat which has
> enhancements on BigDecimal and BigInteger support. Now I just use this
> contribution as external jars in Eclipse.
>
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
beans, regex and math class library code
Posted by Richard Liang <ri...@gmail.com>.
Geir Magnusson Jr wrote:
> Despite a touch of trouble with the packaging of the contribution, it
> passed with flying colors ( or 'colours', for our UK friends...)
>
> +1 from :
>
> Geir
> Stefano
> Dims
> Tim
> Leo
>
> In it comes....
>
> Geir Magnusson Jr wrote:
>> I have received the ACQs and the BCC for Harmony-39, so I can assert
>> that the critical provenance paperwork is in order (although not in
>> SVN yet).
>>
>> Please vote to accept or reject this codebase into the Apache Harmony
>> class library :
>>
>> [ ] + 1 Accept
>> [ ] -1 Reject (provide reason below
>>
>> Lets let this run 3 days unless a) someone states they need more time
>> or b) we get all committer votes before then.
>>
>> Go...
>>
>> geir
>>
>>
>
Hello Geir,
As this contribution has been accepted for a long time, I'm wondering
when the source code could be put into Harmony SVN.
I'm working on the implementation of java.text.DecimalFormat which has
enhancements on BigDecimal and BigInteger support. Now I just use this
contribution as external jars in Eclipse.
--
Richard Liang
China Software Development Lab, IBM
[result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans,
regex and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Despite a touch of trouble with the packaging of the contribution, it
passed with flying colors ( or 'colours', for our UK friends...)
+1 from :
Geir
Stefano
Dims
Tim
Leo
In it comes....
Geir Magnusson Jr wrote:
> I have received the ACQs and the BCC for Harmony-39, so I can assert
> that the critical provenance paperwork is in order (although not in SVN
> yet).
>
> Please vote to accept or reject this codebase into the Apache Harmony
> class library :
>
> [ ] + 1 Accept
> [ ] -1 Reject (provide reason below
>
> Lets let this run 3 days unless a) someone states they need more time or
> b) we get all committer votes before then.
>
> Go...
>
> geir
>
>
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex
and math class library code
Posted by Tim Ellison <t....@gmail.com>.
+1
Geir Magnusson Jr wrote:
> I have received the ACQs and the BCC for Harmony-39, so I can assert
> that the critical provenance paperwork is in order (although not in SVN
> yet).
>
> Please vote to accept or reject this codebase into the Apache Harmony
> class library :
>
> [ ] + 1 Accept
> [ ] -1 Reject (provide reason below
>
> Lets let this run 3 days unless a) someone states they need more time or
> b) we get all committer votes before then.
>
> Go...
>
> geir
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me.
On 2/2/06, Stefano Mazzocchi <st...@apache.org> wrote:
> Geir Magnusson Jr wrote:
> > +1 from me...
> >
> > Geir Magnusson Jr wrote:
> >> I have received the ACQs and the BCC for Harmony-39, so I can assert
> >> that the critical provenance paperwork is in order (although not in
> >> SVN yet).
> >>
> >> Please vote to accept or reject this codebase into the Apache Harmony
> >> class library :
> >>
> >> [ ] + 1 Accept
> >> [ ] -1 Reject (provide reason below
> >>
> >> Lets let this run 3 days unless a) someone states they need more time
> >> or b) we get all committer votes before then.
>
> Sure, +1
>
> --
> Stefano.
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex
and math class library code
Posted by Stefano Mazzocchi <st...@apache.org>.
Geir Magnusson Jr wrote:
> +1 from me...
>
> Geir Magnusson Jr wrote:
>> I have received the ACQs and the BCC for Harmony-39, so I can assert
>> that the critical provenance paperwork is in order (although not in
>> SVN yet).
>>
>> Please vote to accept or reject this codebase into the Apache Harmony
>> class library :
>>
>> [ ] + 1 Accept
>> [ ] -1 Reject (provide reason below
>>
>> Lets let this run 3 days unless a) someone states they need more time
>> or b) we get all committer votes before then.
Sure, +1
--
Stefano.
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex
and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
+1 from me...
Geir Magnusson Jr wrote:
> I have received the ACQs and the BCC for Harmony-39, so I can assert
> that the critical provenance paperwork is in order (although not in SVN
> yet).
>
> Please vote to accept or reject this codebase into the Apache Harmony
> class library :
>
> [ ] + 1 Accept
> [ ] -1 Reject (provide reason below
>
> Lets let this run 3 days unless a) someone states they need more time or
> b) we get all committer votes before then.
>
> Go...
>
> geir
>
>
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex
and math class library code
Posted by Tim Ellison <t....@gmail.com>.
I downloaded the attachment successfully, and had a quick scan of the
code. I used Windows XP & WinZIP.
Regards,
Tim
Leo Simons wrote:
> On Thu, Feb 02, 2006 at 06:36:48AM -0800, Geir Magnusson Jr wrote:
>> I have received the ACQs and the BCC for Harmony-39, so I can assert
>> that the critical provenance paperwork is in order (although not in SVN
>> yet).
>>
>> Please vote to accept or reject this codebase into the Apache Harmony
>> class library :
>>
>> [ ] + 1 Accept
>> [ ] -1 Reject (provide reason below)
>
> -0.
>
> On a "stock" Mac OS X 10.4.4, I am unable to open the attachment at
>
> https://issues.apache.org/jira/browse/HARMONY-39
>
> [lsimons@kava]$ unzip regex_beans_math_src_20060120_1845-Harmony.zip
> downloads
> Archive: regex_beans_math_src_20060120_1845-Harmony.zip
> End-of-central-directory signature not found. Either this file is not
> a zipfile, or it constitutes one disk of a multi-part archive. In the
> latter case the central directory and zipfile comment will be found on
> the last disk(s) of this archive.
> unzip: cannot find zipfile directory in one of regex_beans_math_src_20060120_1845-Harmony.zip or
> regex_beans_math_src_20060120_1845-Harmony.zip.zip, and cannot find
> regex_beans_math_src_20060120_1845-Harmony.zip.ZIP, period.
>
> [lsimons@kava]$ jar xf regex_beans_math_src_20060120_1845-Harmony.zip
> downloads
> java.util.zip.ZipException: invalid entry size (expected 18091 but got 6227 bytes)
> at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:367)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:141)
> at sun.tools.jar.Main.extractFile(Main.java:715)
> at sun.tools.jar.Main.extract(Main.java:678)
> at sun.tools.jar.Main.run(Main.java:190)
> at sun.tools.jar.Main.main(Main.java:904)
>
> [lsimons@kava]$ md5sum regex_beans_math_src_20060120_1845-Harmony.zip
> MD5 (regex_beans_math_src_20060120_1845-Harmony.zip) = d78a289de559e84bb9b49cb766e9c917
> [lsimons@kava]$ ls -alh regex_beans_math_src_20060120_1845-Harmony.zip
> -rw-r--r-- 1 lsimons lsimons 390K Feb 4 16:39 regex_beans_math_src_20060120_1845-Harmony.zip
>
>> Lets let this run 3 days unless a) someone states they need more time or
>> b) we get all committer votes before then.
>
> I'm confused - were you guys able to open the file properly? I'm assuming so
> which is why its -0 and not -1, but I'm a little annoyed...
>
> - LSD
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex
and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrey Chernyshev wrote:
> On 2/4/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> you're right - it did the same thing for me on my mac. (Worked fine on
>> my windows box...) And shows the same problem under Linux (Ubuntu
>> whatever...)
>>
>> Andrey, can you fix and attach again to the JIRA?
>>
>> geir
>
> Hi Geir,
>
> I'm sorry about the broken archive, but... it looks to me strange - I
> can download and unpack it successfully both on my Windows and Linux
> boxes (sorry, I have no Mac in my hands at the moment to check).
Weird. I tried on Ubuntu 5.1 (?) and had the same problem reported by
Leo (and had the same problem on the mac). WinXP was fine.
Thanks for doing this - but I assume you want to figure out why this
happens. If you do, let us know - I'm curious...
geir
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex
and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrey Chernyshev wrote:
> Well, I was using zip included with the cygwin distribution, this
> could be the issue.
> It seems like it produces zip file which has a difference in one byte
> compared to the similar file produced by zip at my Linux machine (it
> was SuSE9 i586).
>
k
> BTW: is there any way to replace a file at JIRA issue? What will
> happen if I just upload the file with the same name?
Nothing, because it's a different name, right? One was .zip, one is
.tgz....
>
>>> What software are you using? Have you tried using 'jar'? That should be
>>> pretty cross-platform...
>
> I wouldn't speculate on that, but... I have a strong feeling that both
> zip and jar utilities are likely to have the same core - zlib library,
> hence the luck of creating equal zip files is likely to depend on it's
> portability anyways :).
Lets test. Send me (privately : geir@pobox.com) a small jar that I can
try on my ubuntu VM...
geir
>
>
> Thank you,
> Andrey Chernyshev
> Intel Middleware Products Division
>
>
> On 2/6/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> We're trying...
>>
>> Leo Simons wrote:
>>> On Mon, Feb 06, 2006 at 04:39:27PM +0300, Andrey Chernyshev wrote:
>>>> I'm sorry about the broken archive, but... it looks to me strange - I
>>>> can download and unpack it successfully both on my Windows and Linux
>>>> boxes (sorry, I have no Mac in my hands at the moment to check).
>>> What software are you using? Have you tried using 'jar'? That should be
>>> pretty cross-platform...
>>>
>>>> Anyways, I have attached the gtar-ed archive (see
>>>> https://issues.apache.org/jira/secure/attachment/12322666/regex_beans_math_src_20060120_1845-Harmony.tgz),
>>>> hopefully either one or another bundle will work for the everyone.
>>>>
>>>> Please let me know if there are still difficulties extracting the contents.
>>> Well I'm getting 503 service temporarily unavailable but there's hardly
>>> anything you can do about that. Lets gope infra@ gets jira back up soon :-)
>>>
>>> cheers,
>>>
>>> Leo
>>>
>>>
>
>
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Andrey Chernyshev <a....@gmail.com>.
Well, I was using zip included with the cygwin distribution, this
could be the issue.
It seems like it produces zip file which has a difference in one byte
compared to the similar file produced by zip at my Linux machine (it
was SuSE9 i586).
BTW: is there any way to replace a file at JIRA issue? What will
happen if I just upload the file with the same name?
> > What software are you using? Have you tried using 'jar'? That should be
> > pretty cross-platform...
I wouldn't speculate on that, but... I have a strong feeling that both
zip and jar utilities are likely to have the same core - zlib library,
hence the luck of creating equal zip files is likely to depend on it's
portability anyways :).
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
On 2/6/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> We're trying...
>
> Leo Simons wrote:
> > On Mon, Feb 06, 2006 at 04:39:27PM +0300, Andrey Chernyshev wrote:
> >> I'm sorry about the broken archive, but... it looks to me strange - I
> >> can download and unpack it successfully both on my Windows and Linux
> >> boxes (sorry, I have no Mac in my hands at the moment to check).
> >
> > What software are you using? Have you tried using 'jar'? That should be
> > pretty cross-platform...
> >
> >> Anyways, I have attached the gtar-ed archive (see
> >> https://issues.apache.org/jira/secure/attachment/12322666/regex_beans_math_src_20060120_1845-Harmony.tgz),
> >> hopefully either one or another bundle will work for the everyone.
> >>
> >> Please let me know if there are still difficulties extracting the contents.
> >
> > Well I'm getting 503 service temporarily unavailable but there's hardly
> > anything you can do about that. Lets gope infra@ gets jira back up soon :-)
> >
> > cheers,
> >
> > Leo
> >
> >
>
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex
and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
We're trying...
Leo Simons wrote:
> On Mon, Feb 06, 2006 at 04:39:27PM +0300, Andrey Chernyshev wrote:
>> I'm sorry about the broken archive, but... it looks to me strange - I
>> can download and unpack it successfully both on my Windows and Linux
>> boxes (sorry, I have no Mac in my hands at the moment to check).
>
> What software are you using? Have you tried using 'jar'? That should be
> pretty cross-platform...
>
>> Anyways, I have attached the gtar-ed archive (see
>> https://issues.apache.org/jira/secure/attachment/12322666/regex_beans_math_src_20060120_1845-Harmony.tgz),
>> hopefully either one or another bundle will work for the everyone.
>>
>> Please let me know if there are still difficulties extracting the contents.
>
> Well I'm getting 503 service temporarily unavailable but there's hardly
> anything you can do about that. Lets gope infra@ gets jira back up soon :-)
>
> cheers,
>
> Leo
>
>
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Leo Simons <ma...@leosimons.com>.
On Mon, Feb 06, 2006 at 04:39:27PM +0300, Andrey Chernyshev wrote:
> I'm sorry about the broken archive, but... it looks to me strange - I
> can download and unpack it successfully both on my Windows and Linux
> boxes (sorry, I have no Mac in my hands at the moment to check).
What software are you using? Have you tried using 'jar'? That should be
pretty cross-platform...
> Anyways, I have attached the gtar-ed archive (see
> https://issues.apache.org/jira/secure/attachment/12322666/regex_beans_math_src_20060120_1845-Harmony.tgz),
> hopefully either one or another bundle will work for the everyone.
>
> Please let me know if there are still difficulties extracting the contents.
Well I'm getting 503 service temporarily unavailable but there's hardly
anything you can do about that. Lets gope infra@ gets jira back up soon :-)
cheers,
Leo
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Andrey Chernyshev <a....@gmail.com>.
On 2/4/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> you're right - it did the same thing for me on my mac. (Worked fine on
> my windows box...) And shows the same problem under Linux (Ubuntu
> whatever...)
>
> Andrey, can you fix and attach again to the JIRA?
>
> geir
Hi Geir,
I'm sorry about the broken archive, but... it looks to me strange - I
can download and unpack it successfully both on my Windows and Linux
boxes (sorry, I have no Mac in my hands at the moment to check).
Anyways, I have attached the gtar-ed archive (see
https://issues.apache.org/jira/secure/attachment/12322666/regex_beans_math_src_20060120_1845-Harmony.tgz),
hopefully either one or another bundle will work for the everyone.
Please let me know if there are still difficulties extracting the contents.
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
>
>
> Geir Magnusson Jr wrote:
> > Ooh. That's not good. Let me check as well...
> >
> >
> >
> > Leo Simons wrote:
> >> On Thu, Feb 02, 2006 at 06:36:48AM -0800, Geir Magnusson Jr wrote:
> >>> I have received the ACQs and the BCC for Harmony-39, so I can assert
> >>> that the critical provenance paperwork is in order (although not in
> >>> SVN yet).
> >>>
> >>> Please vote to accept or reject this codebase into the Apache Harmony
> >>> class library :
> >>>
> >>> [ ] + 1 Accept
> >>> [ ] -1 Reject (provide reason below)
> >>
> >> -0.
> >>
> >> On a "stock" Mac OS X 10.4.4, I am unable to open the attachment at
> >>
> >> https://issues.apache.org/jira/browse/HARMONY-39
> >>
> >> [lsimons@kava]$ unzip
> >> regex_beans_math_src_20060120_1845-Harmony.zip
> >> downloads
> >> Archive: regex_beans_math_src_20060120_1845-Harmony.zip
> >> End-of-central-directory signature not found. Either this file is not
> >> a zipfile, or it constitutes one disk of a multi-part archive. In the
> >> latter case the central directory and zipfile comment will be found on
> >> the last disk(s) of this archive.
> >> unzip: cannot find zipfile directory in one of
> >> regex_beans_math_src_20060120_1845-Harmony.zip or
> >> regex_beans_math_src_20060120_1845-Harmony.zip.zip, and cannot
> >> find regex_beans_math_src_20060120_1845-Harmony.zip.ZIP, period.
> >>
> >> [lsimons@kava]$ jar xf
> >> regex_beans_math_src_20060120_1845-Harmony.zip
> >> downloads
> >> java.util.zip.ZipException: invalid entry size (expected 18091 but got
> >> 6227 bytes)
> >> at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:367)
> >> at java.util.zip.ZipInputStream.read(ZipInputStream.java:141)
> >> at sun.tools.jar.Main.extractFile(Main.java:715)
> >> at sun.tools.jar.Main.extract(Main.java:678)
> >> at sun.tools.jar.Main.run(Main.java:190)
> >> at sun.tools.jar.Main.main(Main.java:904)
> >>
> >> [lsimons@kava]$ md5sum regex_beans_math_src_20060120_1845-Harmony.zip
> >> MD5 (regex_beans_math_src_20060120_1845-Harmony.zip) =
> >> d78a289de559e84bb9b49cb766e9c917
> >> [lsimons@kava]$ ls -alh regex_beans_math_src_20060120_1845-Harmony.zip
> >> -rw-r--r-- 1 lsimons lsimons 390K Feb 4 16:39
> >> regex_beans_math_src_20060120_1845-Harmony.zip
> >>
> >>> Lets let this run 3 days unless a) someone states they need more time
> >>> or b) we get all committer votes before then.
> >>
> >> I'm confused - were you guys able to open the file properly? I'm
> >> assuming so
> >> which is why its -0 and not -1, but I'm a little annoyed...
> >>
> >> - LSD
> >>
> >>
> >
> >
>
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex
and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
you're right - it did the same thing for me on my mac. (Worked fine on
my windows box...) And shows the same problem under Linux (Ubuntu
whatever...)
Andrey, can you fix and attach again to the JIRA?
geir
Geir Magnusson Jr wrote:
> Ooh. That's not good. Let me check as well...
>
>
>
> Leo Simons wrote:
>> On Thu, Feb 02, 2006 at 06:36:48AM -0800, Geir Magnusson Jr wrote:
>>> I have received the ACQs and the BCC for Harmony-39, so I can assert
>>> that the critical provenance paperwork is in order (although not in
>>> SVN yet).
>>>
>>> Please vote to accept or reject this codebase into the Apache Harmony
>>> class library :
>>>
>>> [ ] + 1 Accept
>>> [ ] -1 Reject (provide reason below)
>>
>> -0.
>>
>> On a "stock" Mac OS X 10.4.4, I am unable to open the attachment at
>>
>> https://issues.apache.org/jira/browse/HARMONY-39
>>
>> [lsimons@kava]$ unzip
>> regex_beans_math_src_20060120_1845-Harmony.zip
>> downloads
>> Archive: regex_beans_math_src_20060120_1845-Harmony.zip
>> End-of-central-directory signature not found. Either this file is not
>> a zipfile, or it constitutes one disk of a multi-part archive. In the
>> latter case the central directory and zipfile comment will be found on
>> the last disk(s) of this archive.
>> unzip: cannot find zipfile directory in one of
>> regex_beans_math_src_20060120_1845-Harmony.zip or
>> regex_beans_math_src_20060120_1845-Harmony.zip.zip, and cannot
>> find regex_beans_math_src_20060120_1845-Harmony.zip.ZIP, period.
>>
>> [lsimons@kava]$ jar xf
>> regex_beans_math_src_20060120_1845-Harmony.zip
>> downloads
>> java.util.zip.ZipException: invalid entry size (expected 18091 but got
>> 6227 bytes)
>> at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:367)
>> at java.util.zip.ZipInputStream.read(ZipInputStream.java:141)
>> at sun.tools.jar.Main.extractFile(Main.java:715)
>> at sun.tools.jar.Main.extract(Main.java:678)
>> at sun.tools.jar.Main.run(Main.java:190)
>> at sun.tools.jar.Main.main(Main.java:904)
>>
>> [lsimons@kava]$ md5sum regex_beans_math_src_20060120_1845-Harmony.zip
>> MD5 (regex_beans_math_src_20060120_1845-Harmony.zip) =
>> d78a289de559e84bb9b49cb766e9c917
>> [lsimons@kava]$ ls -alh regex_beans_math_src_20060120_1845-Harmony.zip
>> -rw-r--r-- 1 lsimons lsimons 390K Feb 4 16:39
>> regex_beans_math_src_20060120_1845-Harmony.zip
>>
>>> Lets let this run 3 days unless a) someone states they need more time
>>> or b) we get all committer votes before then.
>>
>> I'm confused - were you guys able to open the file properly? I'm
>> assuming so
>> which is why its -0 and not -1, but I'm a little annoyed...
>>
>> - LSD
>>
>>
>
>
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex
and math class library code
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Ooh. That's not good. Let me check as well...
Leo Simons wrote:
> On Thu, Feb 02, 2006 at 06:36:48AM -0800, Geir Magnusson Jr wrote:
>> I have received the ACQs and the BCC for Harmony-39, so I can assert
>> that the critical provenance paperwork is in order (although not in SVN
>> yet).
>>
>> Please vote to accept or reject this codebase into the Apache Harmony
>> class library :
>>
>> [ ] + 1 Accept
>> [ ] -1 Reject (provide reason below)
>
> -0.
>
> On a "stock" Mac OS X 10.4.4, I am unable to open the attachment at
>
> https://issues.apache.org/jira/browse/HARMONY-39
>
> [lsimons@kava]$ unzip regex_beans_math_src_20060120_1845-Harmony.zip
> downloads
> Archive: regex_beans_math_src_20060120_1845-Harmony.zip
> End-of-central-directory signature not found. Either this file is not
> a zipfile, or it constitutes one disk of a multi-part archive. In the
> latter case the central directory and zipfile comment will be found on
> the last disk(s) of this archive.
> unzip: cannot find zipfile directory in one of regex_beans_math_src_20060120_1845-Harmony.zip or
> regex_beans_math_src_20060120_1845-Harmony.zip.zip, and cannot find
> regex_beans_math_src_20060120_1845-Harmony.zip.ZIP, period.
>
> [lsimons@kava]$ jar xf regex_beans_math_src_20060120_1845-Harmony.zip
> downloads
> java.util.zip.ZipException: invalid entry size (expected 18091 but got 6227 bytes)
> at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:367)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:141)
> at sun.tools.jar.Main.extractFile(Main.java:715)
> at sun.tools.jar.Main.extract(Main.java:678)
> at sun.tools.jar.Main.run(Main.java:190)
> at sun.tools.jar.Main.main(Main.java:904)
>
> [lsimons@kava]$ md5sum regex_beans_math_src_20060120_1845-Harmony.zip
> MD5 (regex_beans_math_src_20060120_1845-Harmony.zip) = d78a289de559e84bb9b49cb766e9c917
> [lsimons@kava]$ ls -alh regex_beans_math_src_20060120_1845-Harmony.zip
> -rw-r--r-- 1 lsimons lsimons 390K Feb 4 16:39 regex_beans_math_src_20060120_1845-Harmony.zip
>
>> Lets let this run 3 days unless a) someone states they need more time or
>> b) we get all committer votes before then.
>
> I'm confused - were you guys able to open the file properly? I'm assuming so
> which is why its -0 and not -1, but I'm a little annoyed...
>
> - LSD
>
>
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, Feb 02, 2006 at 06:36:48AM -0800, Geir Magnusson Jr wrote:
> I have received the ACQs and the BCC for Harmony-39, so I can assert
> that the critical provenance paperwork is in order (although not in SVN
> yet).
>
> Please vote to accept or reject this codebase into the Apache Harmony
> class library :
>
> [ ] + 1 Accept
> [ ] -1 Reject (provide reason below)
-0.
On a "stock" Mac OS X 10.4.4, I am unable to open the attachment at
https://issues.apache.org/jira/browse/HARMONY-39
[lsimons@kava]$ unzip regex_beans_math_src_20060120_1845-Harmony.zip
downloads
Archive: regex_beans_math_src_20060120_1845-Harmony.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of regex_beans_math_src_20060120_1845-Harmony.zip or
regex_beans_math_src_20060120_1845-Harmony.zip.zip, and cannot find
regex_beans_math_src_20060120_1845-Harmony.zip.ZIP, period.
[lsimons@kava]$ jar xf regex_beans_math_src_20060120_1845-Harmony.zip
downloads
java.util.zip.ZipException: invalid entry size (expected 18091 but got 6227 bytes)
at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:367)
at java.util.zip.ZipInputStream.read(ZipInputStream.java:141)
at sun.tools.jar.Main.extractFile(Main.java:715)
at sun.tools.jar.Main.extract(Main.java:678)
at sun.tools.jar.Main.run(Main.java:190)
at sun.tools.jar.Main.main(Main.java:904)
[lsimons@kava]$ md5sum regex_beans_math_src_20060120_1845-Harmony.zip
MD5 (regex_beans_math_src_20060120_1845-Harmony.zip) = d78a289de559e84bb9b49cb766e9c917
[lsimons@kava]$ ls -alh regex_beans_math_src_20060120_1845-Harmony.zip
-rw-r--r-- 1 lsimons lsimons 390K Feb 4 16:39 regex_beans_math_src_20060120_1845-Harmony.zip
> Lets let this run 3 days unless a) someone states they need more time or
> b) we get all committer votes before then.
I'm confused - were you guys able to open the file properly? I'm assuming so
which is why its -0 and not -1, but I'm a little annoyed...
- LSD
Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
Posted by Leo Simons <ma...@leosimons.com>.
+1. Thanks for the tarball!
Leo
On Thu, Feb 02, 2006 at 06:36:48AM -0800, Geir Magnusson Jr wrote:
> I have received the ACQs and the BCC for Harmony-39, so I can assert
> that the critical provenance paperwork is in order (although not in SVN
> yet).
>
> Please vote to accept or reject this codebase into the Apache Harmony
> class library :
>
> [ ] + 1 Accept
> [ ] -1 Reject (provide reason below
>
> Lets let this run 3 days unless a) someone states they need more time or
> b) we get all committer votes before then.
>
> Go...
>
> geir