You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Jimmy, Jing Lv" <fi...@gmail.com> on 2006/08/02 05:40:10 UTC
[classlib] Plan on work on java.lang.instrument
Hi,
If no objection, I shall go on with the plan of instrument :)
Refer to Harmony status page[1], INSTRUMENT is missing, so this
module shall named as "instrument". I shall open a wiki-page for its
status like other modules on [2].
For Java codes, API classes/interfaces can be added to
modules/luni/src/main/java/java/lang/instrument, and implementation can
be added to
modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument
For native codes, instrument need a new directory in
modules/luni/src/main/native named "instrument", in my plan, there
should be two native code, one for instrument native implementation, and
another for laugher (for parameter "-javaagent"). Instrument shall be
compiled into a .DLL(.so) file alone.
Any suggestions? Thanks! :)
[1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
[2]http://wiki.apache.org/harmony/INSTRUMENT
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jimmy, Jing Lv wrote:
> Geir Magnusson Jr wrote:
>>
>> Jimmy, Jing Lv wrote:
>>> Richard Liang wrote:
>>>>
>>>> Jimmy, Jing Lv wrote:
>>>>> Hi,
>>>>>
>>>>> As it is hard to write unit test for package instrument, I now
>>>>> have an idea: write down some documents for details of non-unit test
>>>>> cases for instrument. The detail of such test cases contain:
>>>> Do you mean it's hard to *write* unit test or it's hard to integrate
>>>> the tests with Harmony build system?
>>>>
>>> Hard to write unit test, so record them in some document may be a better
>>> way :)
>>
>> Why is it hard to create unit tests?
>>
>
> To test java.lang.instrument, mostly we need to start up a new VM to see
> its behavior. Its function(premain, etc) may be run before most classes
> loaded, and almost all exceptions will cause VM abort. And the result is
> hard to be checked automatic. What's more, extra java/c code is needed
> for the test.
So...? It just means we need a different kind of testing framework,
right? I never believed that a unit test framework like TestNG or JUnit
would satisfy all our testing needs.
We *better* have a repeatable, mechanical, automated way of testing this.
> One thought was that we can use exec("java commands") in junit(is that
> OK to run exec in tests?), but how to check its output is still a problem.
Luke! Let go of your JUnit and let the testing force flow through you!
>
> I'll put unit test if any, but I believe most necessary and important
> tests are non-unit tests.
Absolutely agreed. That doesn't mean they are human run though.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Posted by Stepan Mishura <st...@gmail.com>.
On 8/8/06, Jimmy, Jing Lv wrote:
>
> Stepan Mishura wrote:
> > On 8/7/06, *Jimmy, Jing Lv* wrote:
> >
> > <SNIP>
> > Sounds pretty good :)
> > "exec" do helps, it can check simple situations.
> > What I'm concern is that if the return code is not enough for some
> > situations, e.g, what exception is thrown exactly, or what cause VM
> exit
> > abnormally. IMHO, it is still necessary for us.
> >
> >
> > Hi Jimmy,
> >
> > See attached test. It demonstrates VM forking. The test saves VM
> > output and prints it in the end.
> > So I expect that unit tests for 'instrument' module can do the same:
> > fork VM with predefined args, save output and compare it with expected
> > output.
> >
> > BWT, we have utility class[1] in 'support' for this task. It makes sense
> > to improve it for our needs.
> >
> > Thanks,
> > Stepan.
> >
>
> Thanks Stepan, this is very attractive to me :)
>
> According to your approach, I believe now it can be automatized well, at
> least for many test.
>
> One concern from me is that, how do you handle output comparison? For an
> example, if VM halt with a exception, it output some message, so you get
> the output, find the exception name in it? And what can we do if it
> output some information only, which RI and Harmony may not appear the
> same?
Is the output format specified?
We may look for exact message or just find exception name in it. Also if
there are Harmony impl. specific tests we can place them into Harmony impl.
test suite.
However this is a good idea, if no objections, I shall follow this
> approach in writing some test of instrument.
As I said we need to improve Support_Exec support class. Currently it is
designed to fork only two selected VMs. At least we have to add Harmony VM.
And ideally it'd great to have support class that is able to fork any
compatible VM.
Thanks,
Stepan.
> [1]
> >
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058&view=markup
> > <
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058&view=markup
> >
> >
> > > On 8/7/06, Jimmy, Jing Lv <firepure@gmail.com
> > <ma...@gmail.com>> wrote:
> > >>
> > >> Geir Magnusson Jr wrote:
> > >> >
> > >> > Jimmy, Jing Lv wrote:
> > >> >> Richard Liang wrote:
> > >> >>>
> > >> >>> Jimmy, Jing Lv wrote:
> > >> >>>> Hi,
> > >> >>>>
> > >> >>>> As it is hard to write unit test for package
> > instrument, I now
> > >> >>>> have an idea: write down some documents for details of
> > non-unit test
> > >> >>>> cases for instrument. The detail of such test cases
> contain:
> > >> >>> Do you mean it's hard to *write* unit test or it's hard to
> > integrate
> > >> >>> the tests with Harmony build system?
> > >> >>>
> > >> >> Hard to write unit test, so record them in some document may
> be a
> > >> better
> > >> >> way :)
> > >> >
> > >> > Why is it hard to create unit tests?
> > >> >
> > >>
> > >> To test java.lang.instrument, mostly we need to start up a new
> > VM to see
> > >> its behavior. Its function(premain, etc) may be run before most
> > classes
> > >> loaded, and almost all exceptions will cause VM abort. And the
> > result is
> > >> hard to be checked automatic. What's more, extra java/c code is
> > needed
> > >> for the test.
> > >>
> > >> One thought was that we can use exec("java commands") in
> > junit(is that
> > >> OK to run exec in tests?), but how to check its output is still
> a
> > >> problem.
> > >>
> > >> I'll put unit test if any, but I believe most necessary and
> > important
> > >> tests are non-unit tests.
> > >>
> > >> >>>> 1. The test run on which platform, including special
> > environment;
> > >> >>>> 2. The test description;
> > >> >>>> 3. How to run test (command line, etc.);
> > >> >>>> 4. test result;
> > >> >>>> 5. resource (or links) for tests, including c/java code for
> > test if
> > >> any.
> > >> >>>>
> > >> >>>> I hope ensure the code quality in this way. Like unit
> > test, such
> > >> >>>> tests can be checked and re-run for regression, though
> > >> un-automatically.
> > >> >>>>
> > >> >>>> And I'll put them in Harmony-wiki[1], and any
> > >> test-description is
> > >> >>>> welcome!. (Geir, I've found an advancement of wiki :) )
> > >> >>>>
> > >> >>>> Any suggestions? :)
> > >> >>>>
> > >> >>>> [1]http://wiki.apache.org/harmony/INSTRUMENT
> > >> >>>>
> > >> >>>>> Geir Magnusson Jr wrote:
> > >> >>>>> Never appeal to me using a Wiki as an authority :) It's
> like
> > >> finding
> > >> >>>>> something written in chalk on the sidewalk.
> > >> >>>>>
> > >> >>>>> However, if you had pointed out
> > >> >>>>>
> > >>
> > >>>>> http://incubator.apache.org/harmony/auth_cont_quest.html
> > <http://incubator.apache.org/harmony/auth_cont_quest.html>
> > >> >>>>>
> > >> >>>>> I'd have agreed w/o having the opportunity to make fun of
> > the Wiki.
> > >> >>>>>
> > >> >>>>> So I agree :)
> > >> >>>>>
> > >> >>>>> geir
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Posted by Leo Li <li...@gmail.com>.
On 8/7/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
>
> Leo Li wrote:
> > Hi, all:
> > I have some idea to test instrument.
> > For example, if we would like to test
> > Instrumentation.addTransformerwill throw NullPointerException if the
> > argument is null,
> > we can first write a TestInstrument with premain function.
> >
> > import java.lang.instrument.Instrumentation ;
> > public class TestInstrument {
> >
> > public static void premain(String agentArgs, Instrumentation inst)
> > {
> > try
> > {
> > inst.addTransformer(null);
> > }
> > catch(NullPointerException e)
> > {
> > //failed, we set error code
> > System.exit(1);
> > }
> > }
> > }
> > Normally, the VM will exit with zero as it return value if there is no
> > exception occurs in main class.
> >
> > then, we might write an JUnit Test:
> > public void test() throws Exception
> > {
> > Process process = Runtime.getRuntime().exec("java -javaagent
> > Test.jarTest");
> > //if premain runs as we expected, the exit code is zero.
> > assertEquals(0,process.waitFor());
> > }
> >
> > (Besides,Test is an ordinary class with a main function that will not
> throw
> > error. Test.jar with the manifest to denote the class of TestInstrument
> as
> > the premain class.}
> >
> > Is it all right? :)
> >
>
> Sounds pretty good :)
> "exec" do helps, it can check simple situations.
> What I'm concern is that if the return code is not enough for some
> situations, e.g, what exception is thrown exactly, or what cause VM exit
> abnormally. IMHO, it is still necessary for us.
Excuse for my confusing you.
Actually, in premain, I want to write:
public static void premain(String agentArgs, Instrumentation inst)
{
try
{
inst.addTransformer(null);
//failed, we set error code
System.exit(1);
}
catch(NullPointerException e)
{
//expected, the exit code is zero.
}
}
I think to set error code is enough to denote which exception has been
thrown out. When and only when the expected exception is thrown out and
no other exception has been thrown out or vm exits abnormally, the return
value is zero which we expect. (Of course, as Varlamov says, there is the
case that VM hangs for us to deal with.)
Besides the java exceptions, other reasons that cause VM to exit
abnormally, for example, the denoted premain class does not exists, are only
showed by some error strings. Except for these strings, as a black box, what
we know is just VM exits abnormally. Is it necessary for us to write
testcases to verify these error message as the causes? Is it enough for us
just to know VM exits abnormally at the specified stage? Or else maybe we
can use lProcess.getErrorStream() or getOutputStream() to get the error
message, I am not sure.:)
> On 8/7/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
> >>
> >> Geir Magnusson Jr wrote:
> >> >
> >> > Jimmy, Jing Lv wrote:
> >> >> Richard Liang wrote:
> >> >>>
> >> >>> Jimmy, Jing Lv wrote:
> >> >>>> Hi,
> >> >>>>
> >> >>>> As it is hard to write unit test for package instrument, I now
> >> >>>> have an idea: write down some documents for details of non-unit
> test
> >> >>>> cases for instrument. The detail of such test cases contain:
> >> >>> Do you mean it's hard to *write* unit test or it's hard to
> integrate
> >> >>> the tests with Harmony build system?
> >> >>>
> >> >> Hard to write unit test, so record them in some document may be a
> >> better
> >> >> way :)
> >> >
> >> > Why is it hard to create unit tests?
> >> >
> >>
> >> To test java.lang.instrument, mostly we need to start up a new VM to
> see
> >> its behavior. Its function(premain, etc) may be run before most classes
> >> loaded, and almost all exceptions will cause VM abort. And the result
> is
> >> hard to be checked automatic. What's more, extra java/c code is needed
> >> for the test.
> >>
> >> One thought was that we can use exec("java commands") in junit(is that
> >> OK to run exec in tests?), but how to check its output is still a
> >> problem.
> >>
> >> I'll put unit test if any, but I believe most necessary and important
> >> tests are non-unit tests.
> >>
> >> >>>> 1. The test run on which platform, including special environment;
> >> >>>> 2. The test description;
> >> >>>> 3. How to run test (command line, etc.);
> >> >>>> 4. test result;
> >> >>>> 5. resource (or links) for tests, including c/java code for test
> if
> >> any.
> >> >>>>
> >> >>>> I hope ensure the code quality in this way. Like unit test,
> such
> >> >>>> tests can be checked and re-run for regression, though
> >> un-automatically.
> >> >>>>
> >> >>>> And I'll put them in Harmony-wiki[1], and any
> >> test-description is
> >> >>>> welcome!. (Geir, I've found an advancement of wiki :) )
> >> >>>>
> >> >>>> Any suggestions? :)
> >> >>>>
> >> >>>> [1]http://wiki.apache.org/harmony/INSTRUMENT
> >> >>>>
> >> >>>>> Geir Magnusson Jr wrote:
> >> >>>>> Never appeal to me using a Wiki as an authority :) It's like
> >> finding
> >> >>>>> something written in chalk on the sidewalk.
> >> >>>>>
> >> >>>>> However, if you had pointed out
> >> >>>>>
> >> >>>>> http://incubator.apache.org/harmony/auth_cont_quest.html
> >> >>>>>
> >> >>>>> I'd have agreed w/o having the opportunity to make fun of the
> Wiki.
> >> >>>>>
> >> >>>>> So I agree :)
> >> >>>>>
> >> >>>>> geir
> >> >>>>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
>
> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> >> >
> >> >
> >>
> >>
> >> --
> >>
> >> Best Regards!
> >>
> >> Jimmy, Jing Lv
> >> China Software Development Lab, IBM
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Posted by Leo Li <li...@gmail.com>.
Hi, all:
I wonder if we need to get the exception from the exec framework. As an
exec result, we need only get whether it succeeds or not. Besides, I do not
think it is so reliable to parse error message to get exception.
We can design sophisticated testcase to deduce whether the expected
exception has been thrown out from the status of exec.
For example, during VM init there are some errors that can be caught by
some java class.
If we add a null object as Transformer, the VM will go down by
nullpointerexception. But it can be caught be its caller:
public static void premain(String agentArgs, Instrumentation inst)
{
try
{
inst.addTransformer(null);
//should throw NullPointerException
System.exit(1);
}
catch(NullPointerException e)
{
//expected
}
}
From the exec result, if there is no error, that is return value is 0, we
can deduce that the expected exception is thrown.
As for those fault errors raised from VM init, if they cannot be caught
by any java class, they are just error messages that can be got from
console. I do not think some application will depend on such message.
Furthermore, some of these messages cannot be classified to any exception
type: some are errors about runtime environment, some are related to VM.
Actually, in reality, some error events are related to Harmony's
implemenation. For example, in our instrumentation impl class, there are two
methods executePremain and transform, which are called duirng VM and might
cause VM to die if these methods cannot be invoked. In such circumstances,
we cannot behave just like RI.
So in my opinion, if the exception can be caught by any java class, we try
to design testcase to verify it; or else, they are just error messages that
are related to implementation.
On 8/17/06, Anton Luht <an...@gmail.com> wrote:
>
> Jimmy,
>
> > Ah, we are trying to catch the exact exception name, not its message. I
> > agree parsing the message is a bad idea, but find an exact exception
> > name in the output is still stable, am I right?
>
> Yes, it's stable.
>
> > In fact, I have no idea to catch an exception in "exec", it surely
> > contains no such function, right?
>
> No, it doesn't.
>
> --
> Regards,
> Anton Luht,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Posted by Anton Luht <an...@gmail.com>.
Jimmy,
> Ah, we are trying to catch the exact exception name, not its message. I
> agree parsing the message is a bad idea, but find an exact exception
> name in the output is still stable, am I right?
Yes, it's stable.
> In fact, I have no idea to catch an exception in "exec", it surely
> contains no such function, right?
No, it doesn't.
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument]
Documents for non-unit-tests)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Anton Luht wrote:
> IMHO analysis of exception stacktrace output is a bad idea. Tests
> should not produce uncatched exceptions unless they fail. Test authors
> should explicitly catch an exception and print some text to stdout.
> Reasons are:
>
> - exception messages are not standard, different JVMs can produce
> different output
> - localized messages can be printed, the test may fail because of locales
> - if test author expects IOException but subclass of this exception is
> thrown and printed, the test will fail while if the test was written
> in the way "catch IOException; print "PASSED" the test would pass
>
>
Ah, we are trying to catch the exact exception name, not its message. I
agree parsing the message is a bad idea, but find an exact exception
name in the output is still stable, am I right?
In fact, I have no idea to catch an exception in "exec", it surely
contains no such function, right?
> On 8/16/06, Stepan Mishura <st...@gmail.com> wrote:
>> On 8/16/06, Anton Luht wrote:
>> >
>> > Cool idea - rethrow exceptions from exec'ed java :) You exec jvm that
>> > dies because some exception (say, NPE) not catched, support_exec
>> > analyzes output, understands that NPE was thrown and rethrows it :)
>> > People who will look at those tests will certainly go mad.
>>
>>
>> You misunderstoond the idea for using support_exec - no exceptions
>> re-throwing should be made. A test will verify only that VM fails in
>> expected way (i.e. with expected error message).
>>
>> Do you have a better idea how to test that?
>>
>> Thanks,
>> Stepan.
>>
>> On 8/16/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
>> > > Paulex Yang wrote:
>> > > > Jimmy, Jing Lv wrote:
>> > > >> Hi,
>> > > >>
>> > > >> I'm trying to write some unit tests of instrument. As
>> discussed,
>> > > >> I'm using exec.
>> > > >> Currently I've tried Support_Exec and find it fairly easy to
>> > > >> use(Thanks Stepan :) ).
>> > > >>
>> > > >> For resources (jar files and utility classes), I make a new
>> > > >> directory:
>> > > >>
>> >
>> $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument
>>
>> > > >> and put them there.
>> > > >>
>> > > >> And I meet a problem here. Currently the default classpath in
>> > > >> running test is "$Harmony/modules/instrument/bin", so it meets
>> > problem
>> > > >> in loading those utility classes (it can load jar files though).
>> > > >> I remember Mark has plan to change the classpath in running
>> > > >> testcase, it'll be great if he make some progress.
>> > > >>
>> > > >> An another problem is checking, currently the result is
>> checked
>> > by
>> > > >> searching and compare in string(e.g, find "someException" in
>> result).
>> > > >> But the framework seems fails if any exception is thrown out.
>> Can it
>> > > >> make a little change that it passes and returns the error
>> message in
>> > > >> exec?
>> > > > Didn't catch up here, did you mean that you need to check the
>> > exception
>> > > > message as well as exception type?
>> > >
>> > > Not necessary to check messages. However we can not catch those
>> > > exceptions so we have to analysis output. For an example:
>> > >
>> > > run "java -javaagent:test.jar myclass"
>> > >
>> > > so get output:
>> > > Exception in thread "main"
>> java.lang.reflect.InvocationTargetException
>> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> > > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
>> Source)
>> > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>> > Source)
>> > > at java.lang.reflect.Method.invoke(Unknown Source)
>> > > at
>> > > sun.instrument.InstrumentationImpl.loadClassAndCallPremain(Unknown So
>> > > urce)
>> > > Caused by: java.lang.IllegalAccessError
>> > > ...
>> > >
>> > > In this case we can search for "InvocationTargetException" in the
>> output
>> > > to ensure the expected exception. Sometimes we may also check
>> "cause by"
>> > > exceptions.
>> > >
>> > > This approach seems not perfect. Any comments/suggestions? Thanks!
>> > >
>> > > <snip>
>> > > --
>> > >
>> > > Best Regards!
>> > >
>> > > Jimmy, Jing Lv
>> > > China Software Development Lab, IBM
>> > >
>> >
>> >
>>
>>
>> --
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>> ------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 16 August 2006 16:13 Anton Luht wrote:
> > For example, how you will test that VM is aborted during start-up with
> > NoClassDefFoundError (not with IllegalArgumentException or any other
> > exception) if it is impossible to load requested class?
>
> I think it should be done using some VM tests - maybe using JVMTI.
> Parsing output sounds too weak for me - anything that prints
> "NoClassDefFoundError args[0]" will do.
>
> This is too complicated though and I agree that parsing error output
> will work in most cases.
I've lost the beginning of the discussion so I've considered a limited number
of the emails sent today only. If I understood correctly you want to test a
correct exception for a child VM process and consider using JVMTI as the
testing solution for such exception.
I want to point out that JVMTI spec is quite vague in the description of VM
startup events sequence, the only guaranteed sequence statement can be found
in [1]. The LIVE phase should begin after the main thread has been started.
It says nothing about ClassLoad event for main application class, it may be
loaded before the main thread is created, therefore before LIVE phase.
The Exception event can and should occur only in LIVE phase, that is after
VMInit event has been sent. VM can fail and never send the VMInit event if it
can't find main application class or some class like the one supplied
via -javaagent option before LIVE phase has begun.
So I think this testing approach may fail if it relies on unspecified VM
behavior.
[1] http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#VMInit
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Posted by Anton Luht <an...@gmail.com>.
> For example, how you will test that VM is aborted during start-up with
> NoClassDefFoundError (not with IllegalArgumentException or any other
> exception) if it is impossible to load requested class?
I think it should be done using some VM tests - maybe using JVMTI.
Parsing output sounds too weak for me - anything that prints
"NoClassDefFoundError args[0]" will do.
This is too complicated though and I agree that parsing error output
will work in most cases.
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200608.mbox/%3c44D6AC2E.4000603@gmail.com%3e
>
> On 8/16/06, Stepan Mishura <st...@gmail.com> wrote:
> > > On 8/16/06, Anton Luht wrote:
> > > >
> > > > Cool idea - rethrow exceptions from exec'ed java :) You exec jvm that
> > > > dies because some exception (say, NPE) not catched, support_exec
> > > > analyzes output, understands that NPE was thrown and rethrows it :)
> > > > People who will look at those tests will certainly go mad.
> > >
> > >
> > > You misunderstoond the idea for using support_exec - no exceptions
> > > re-throwing should be made. A test will verify only that VM fails in
> > > expected way (i.e. with expected error message).
> > >
> > > Do you have a better idea how to test that?
> > >
> > > Thanks,
> > > Stepan.
> > >
> > > On 8/16/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
> > > > > Paulex Yang wrote:
> > > > > > Jimmy, Jing Lv wrote:
> > > > > >> Hi,
> > > > > >>
> > > > > >> I'm trying to write some unit tests of instrument. As
> > discussed,
> > > > > >> I'm using exec.
> > > > > >> Currently I've tried Support_Exec and find it fairly easy to
> > > > > >> use(Thanks Stepan :) ).
> > > > > >>
> > > > > >> For resources (jar files and utility classes), I make a new
> > > > > >> directory:
> > > > > >>
> > > >
> > $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument
> > > > > >> and put them there.
> > > > > >>
> > > > > >> And I meet a problem here. Currently the default classpath in
> > > > > >> running test is "$Harmony/modules/instrument/bin", so it meets
> > > > problem
> > > > > >> in loading those utility classes (it can load jar files though).
> > > > > >> I remember Mark has plan to change the classpath in running
> > > > > >> testcase, it'll be great if he make some progress.
> > > > > >>
> > > > > >> An another problem is checking, currently the result is
> > checked
> > > > by
> > > > > >> searching and compare in string(e.g, find "someException" in
> > result).
> > > > > >> But the framework seems fails if any exception is thrown out. Can
> > it
> > > > > >> make a little change that it passes and returns the error message
> > in
> > > > > >> exec?
> > > > > > Didn't catch up here, did you mean that you need to check the
> > > > exception
> > > > > > message as well as exception type?
> > > > >
> > > > > Not necessary to check messages. However we can not catch those
> > > > > exceptions so we have to analysis output. For an example:
> > > > >
> > > > > run "java -javaagent:test.jar myclass"
> > > > >
> > > > > so get output:
> > > > > Exception in thread "main"
> > java.lang.reflect.InvocationTargetException
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
> > Source)
> > > > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> > > > Source)
> > > > > at java.lang.reflect.Method.invoke(Unknown Source)
> > > > > at
> > > > > sun.instrument.InstrumentationImpl.loadClassAndCallPremain(Unknown
> > So
> > > > > urce)
> > > > > Caused by: java.lang.IllegalAccessError
> > > > > ...
> > > > >
> > > > > In this case we can search for "InvocationTargetException" in the
> > output
> > > > > to ensure the expected exception. Sometimes we may also check "cause
> > by"
> > > > > exceptions.
> > > > >
> > > > > This approach seems not perfect. Any comments/suggestions? Thanks!
> > > > >
> > > > > <snip>
> > > > > --
> > > > >
> > > > > Best Regards!
> > > > >
> > > > > Jimmy, Jing Lv
> > > > > China Software Development Lab, IBM
> >
> > ------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Posted by Stepan Mishura <st...@gmail.com>.
On 8/16/06, Anton Luht wrote:
>
> IMHO analysis of exception stacktrace output is a bad idea. Tests
> should not produce uncatched exceptions unless they fail. Test authors
> should explicitly catch an exception and print some text to stdout.
See [1] for testing details.
Reasons are:
>
> - exception messages are not standard, different JVMs can produce
> different output
> - localized messages can be printed, the test may fail because of locales
> - if test author expects IOException but subclass of this exception is
> thrown and printed, the test will fail while if the test was written
> in the way "catch IOException; print "PASSED" the test would pass
For example, how you will test that VM is aborted during start-up with
NoClassDefFoundError (not with IllegalArgumentException or any other
exception) if it is impossible to load requested class?
Thanks,
Stepan.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200608.mbox/%3c44D6AC2E.4000603@gmail.com%3e
On 8/16/06, Stepan Mishura <st...@gmail.com> wrote:
> > On 8/16/06, Anton Luht wrote:
> > >
> > > Cool idea - rethrow exceptions from exec'ed java :) You exec jvm that
> > > dies because some exception (say, NPE) not catched, support_exec
> > > analyzes output, understands that NPE was thrown and rethrows it :)
> > > People who will look at those tests will certainly go mad.
> >
> >
> > You misunderstoond the idea for using support_exec - no exceptions
> > re-throwing should be made. A test will verify only that VM fails in
> > expected way (i.e. with expected error message).
> >
> > Do you have a better idea how to test that?
> >
> > Thanks,
> > Stepan.
> >
> > On 8/16/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
> > > > Paulex Yang wrote:
> > > > > Jimmy, Jing Lv wrote:
> > > > >> Hi,
> > > > >>
> > > > >> I'm trying to write some unit tests of instrument. As
> discussed,
> > > > >> I'm using exec.
> > > > >> Currently I've tried Support_Exec and find it fairly easy to
> > > > >> use(Thanks Stepan :) ).
> > > > >>
> > > > >> For resources (jar files and utility classes), I make a new
> > > > >> directory:
> > > > >>
> > >
> $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument
> > > > >> and put them there.
> > > > >>
> > > > >> And I meet a problem here. Currently the default classpath in
> > > > >> running test is "$Harmony/modules/instrument/bin", so it meets
> > > problem
> > > > >> in loading those utility classes (it can load jar files though).
> > > > >> I remember Mark has plan to change the classpath in running
> > > > >> testcase, it'll be great if he make some progress.
> > > > >>
> > > > >> An another problem is checking, currently the result is
> checked
> > > by
> > > > >> searching and compare in string(e.g, find "someException" in
> result).
> > > > >> But the framework seems fails if any exception is thrown out. Can
> it
> > > > >> make a little change that it passes and returns the error message
> in
> > > > >> exec?
> > > > > Didn't catch up here, did you mean that you need to check the
> > > exception
> > > > > message as well as exception type?
> > > >
> > > > Not necessary to check messages. However we can not catch those
> > > > exceptions so we have to analysis output. For an example:
> > > >
> > > > run "java -javaagent:test.jar myclass"
> > > >
> > > > so get output:
> > > > Exception in thread "main"
> java.lang.reflect.InvocationTargetException
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
> Source)
> > > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> > > Source)
> > > > at java.lang.reflect.Method.invoke(Unknown Source)
> > > > at
> > > > sun.instrument.InstrumentationImpl.loadClassAndCallPremain(Unknown
> So
> > > > urce)
> > > > Caused by: java.lang.IllegalAccessError
> > > > ...
> > > >
> > > > In this case we can search for "InvocationTargetException" in the
> output
> > > > to ensure the expected exception. Sometimes we may also check "cause
> by"
> > > > exceptions.
> > > >
> > > > This approach seems not perfect. Any comments/suggestions? Thanks!
> > > >
> > > > <snip>
> > > > --
> > > >
> > > > Best Regards!
> > > >
> > > > Jimmy, Jing Lv
> > > > China Software Development Lab, IBM
>
> ------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Posted by Anton Luht <an...@gmail.com>.
IMHO analysis of exception stacktrace output is a bad idea. Tests
should not produce uncatched exceptions unless they fail. Test authors
should explicitly catch an exception and print some text to stdout.
Reasons are:
- exception messages are not standard, different JVMs can produce
different output
- localized messages can be printed, the test may fail because of locales
- if test author expects IOException but subclass of this exception is
thrown and printed, the test will fail while if the test was written
in the way "catch IOException; print "PASSED" the test would pass
On 8/16/06, Stepan Mishura <st...@gmail.com> wrote:
> On 8/16/06, Anton Luht wrote:
> >
> > Cool idea - rethrow exceptions from exec'ed java :) You exec jvm that
> > dies because some exception (say, NPE) not catched, support_exec
> > analyzes output, understands that NPE was thrown and rethrows it :)
> > People who will look at those tests will certainly go mad.
>
>
> You misunderstoond the idea for using support_exec - no exceptions
> re-throwing should be made. A test will verify only that VM fails in
> expected way (i.e. with expected error message).
>
> Do you have a better idea how to test that?
>
> Thanks,
> Stepan.
>
> On 8/16/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
> > > Paulex Yang wrote:
> > > > Jimmy, Jing Lv wrote:
> > > >> Hi,
> > > >>
> > > >> I'm trying to write some unit tests of instrument. As discussed,
> > > >> I'm using exec.
> > > >> Currently I've tried Support_Exec and find it fairly easy to
> > > >> use(Thanks Stepan :) ).
> > > >>
> > > >> For resources (jar files and utility classes), I make a new
> > > >> directory:
> > > >>
> > $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument
> > > >> and put them there.
> > > >>
> > > >> And I meet a problem here. Currently the default classpath in
> > > >> running test is "$Harmony/modules/instrument/bin", so it meets
> > problem
> > > >> in loading those utility classes (it can load jar files though).
> > > >> I remember Mark has plan to change the classpath in running
> > > >> testcase, it'll be great if he make some progress.
> > > >>
> > > >> An another problem is checking, currently the result is checked
> > by
> > > >> searching and compare in string(e.g, find "someException" in result).
> > > >> But the framework seems fails if any exception is thrown out. Can it
> > > >> make a little change that it passes and returns the error message in
> > > >> exec?
> > > > Didn't catch up here, did you mean that you need to check the
> > exception
> > > > message as well as exception type?
> > >
> > > Not necessary to check messages. However we can not catch those
> > > exceptions so we have to analysis output. For an example:
> > >
> > > run "java -javaagent:test.jar myclass"
> > >
> > > so get output:
> > > Exception in thread "main" java.lang.reflect.InvocationTargetException
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> > Source)
> > > at java.lang.reflect.Method.invoke(Unknown Source)
> > > at
> > > sun.instrument.InstrumentationImpl.loadClassAndCallPremain(Unknown So
> > > urce)
> > > Caused by: java.lang.IllegalAccessError
> > > ...
> > >
> > > In this case we can search for "InvocationTargetException" in the output
> > > to ensure the expected exception. Sometimes we may also check "cause by"
> > > exceptions.
> > >
> > > This approach seems not perfect. Any comments/suggestions? Thanks!
> > >
> > > <snip>
> > > --
> > >
> > > Best Regards!
> > >
> > > Jimmy, Jing Lv
> > > China Software Development Lab, IBM
> > >
> >
> >
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 8/7/06, Alexey Varlamov <al...@gmail.com> wrote:
>
>
> And you forgot to mention cases when tested VM hangs :)
> Still, almost any of those situations may be tested automatically,
> just fork a tested JVM and setup timeout watchdog. You may examine
> 1) return value (via j.lProcess.exitValue());
> 2) out/err streams of the forked process (j.lProcess.getErrorStream()
> & j.lProcess.getInputStream ());
>
> Though I'm unsure this is readily possible with Ant+junit, likely more
> functional harness is needed.
I thought about testing using exec() and testing using jasmin-written tests
and management of tests via metadata and here what came into my mind as
requirements to the harness which would solve current and future issues we
will face as we have more and more tests of various types:
General
· Multi-platform (Java-written)
· Easy to install, configure and run tests.
· Fully automated test execution (batch mode with no user interaction)
· Support of two modes – each test in separate VM, all tests in one VM.
- Each test in separate VM - to avoid test influence or VM crash
should not lead to test run stop.
- All tests in one VM – useful mode to test runtime for
stability/reliability and allows reducing test suite execution time.
· Be independent of test directory structure or test naming conventions.
Managing test execution
· Selection of tests for execution:
- By some property (platform-specific tests only, Harmony
implementation tests only, do not run buggy tests)
- By sub-directory and/or using list of tests to execute and/or
fitting test name pattern.
· Harness should control test execution timeout & kill test process when
timeout expires.
· Unexpected abnormal test/runtime completion does not stop test
execution.
· Test run environment should be configurable (best – all settings are in
one place – in some configuration file, for example)
Logging and reporting
· Harness should provide good reporting capabilities – easy to understand
and navigate.
Do we have in mind test harness which meets majority of requirements?
Thanks, Vladimir
--
> Regards,
> Alexey
>
> [snip]
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Posted by Alexey Varlamov <al...@gmail.com>.
2006/8/7, Jimmy, Jing Lv <fi...@gmail.com>:
> Leo Li wrote:
> > Hi, all:
> > I have some idea to test instrument.
> > For example, if we would like to test
> > Instrumentation.addTransformerwill throw NullPointerException if the
> > argument is null,
> > we can first write a TestInstrument with premain function.
> >
> > import java.lang.instrument.Instrumentation;
> > public class TestInstrument {
> >
> > public static void premain(String agentArgs, Instrumentation inst)
> > {
> > try
> > {
> > inst.addTransformer(null);
> > }
> > catch(NullPointerException e)
> > {
> > //failed, we set error code
> > System.exit(1);
> > }
> > }
> > }
> > Normally, the VM will exit with zero as it return value if there is no
> > exception occurs in main class.
> >
> > then, we might write an JUnit Test:
> > public void test() throws Exception
> > {
> > Process process = Runtime.getRuntime().exec("java -javaagent
> > Test.jarTest");
> > //if premain runs as we expected, the exit code is zero.
> > assertEquals(0,process.waitFor());
> > }
> >
> > (Besides,Test is an ordinary class with a main function that will not throw
> > error. Test.jar with the manifest to denote the class of TestInstrument as
> > the premain class.}
> >
> > Is it all right? :)
> >
>
> Sounds pretty good :)
> "exec" do helps, it can check simple situations.
> What I'm concern is that if the return code is not enough for some
> situations, e.g, what exception is thrown exactly, or what cause VM exit
> abnormally. IMHO, it is still necessary for us.
And you forgot to mention cases when tested VM hangs :)
Still, almost any of those situations may be tested automatically,
just fork a tested JVM and setup timeout watchdog. You may examine
1) return value (via j.lProcess.exitValue());
2) out/err streams of the forked process (j.lProcess.getErrorStream()
& j.lProcess.getInputStream());
Though I'm unsure this is readily possible with Ant+junit, likely more
functional harness is needed.
--
Regards,
Alexey
[snip]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Posted by Stepan Mishura <st...@gmail.com>.
On 8/16/06, Anton Luht wrote:
>
> Cool idea - rethrow exceptions from exec'ed java :) You exec jvm that
> dies because some exception (say, NPE) not catched, support_exec
> analyzes output, understands that NPE was thrown and rethrows it :)
> People who will look at those tests will certainly go mad.
You misunderstoond the idea for using support_exec - no exceptions
re-throwing should be made. A test will verify only that VM fails in
expected way (i.e. with expected error message).
Do you have a better idea how to test that?
Thanks,
Stepan.
On 8/16/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
> > Paulex Yang wrote:
> > > Jimmy, Jing Lv wrote:
> > >> Hi,
> > >>
> > >> I'm trying to write some unit tests of instrument. As discussed,
> > >> I'm using exec.
> > >> Currently I've tried Support_Exec and find it fairly easy to
> > >> use(Thanks Stepan :) ).
> > >>
> > >> For resources (jar files and utility classes), I make a new
> > >> directory:
> > >>
> $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument
> > >> and put them there.
> > >>
> > >> And I meet a problem here. Currently the default classpath in
> > >> running test is "$Harmony/modules/instrument/bin", so it meets
> problem
> > >> in loading those utility classes (it can load jar files though).
> > >> I remember Mark has plan to change the classpath in running
> > >> testcase, it'll be great if he make some progress.
> > >>
> > >> An another problem is checking, currently the result is checked
> by
> > >> searching and compare in string(e.g, find "someException" in result).
> > >> But the framework seems fails if any exception is thrown out. Can it
> > >> make a little change that it passes and returns the error message in
> > >> exec?
> > > Didn't catch up here, did you mean that you need to check the
> exception
> > > message as well as exception type?
> >
> > Not necessary to check messages. However we can not catch those
> > exceptions so we have to analysis output. For an example:
> >
> > run "java -javaagent:test.jar myclass"
> >
> > so get output:
> > Exception in thread "main" java.lang.reflect.InvocationTargetException
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)
> > at java.lang.reflect.Method.invoke(Unknown Source)
> > at
> > sun.instrument.InstrumentationImpl.loadClassAndCallPremain(Unknown So
> > urce)
> > Caused by: java.lang.IllegalAccessError
> > ...
> >
> > In this case we can search for "InvocationTargetException" in the output
> > to ensure the expected exception. Sometimes we may also check "cause by"
> > exceptions.
> >
> > This approach seems not perfect. Any comments/suggestions? Thanks!
> >
> > <snip>
> > --
> >
> > Best Regards!
> >
> > Jimmy, Jing Lv
> > China Software Development Lab, IBM
> >
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Posted by Anton Luht <an...@gmail.com>.
Cool idea - rethrow exceptions from exec'ed java :) You exec jvm that
dies because some exception (say, NPE) not catched, support_exec
analyzes output, understands that NPE was thrown and rethrows it :)
People who will look at those tests will certainly go mad.
On 8/16/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
> Paulex Yang wrote:
> > Jimmy, Jing Lv wrote:
> >> Hi,
> >>
> >> I'm trying to write some unit tests of instrument. As discussed,
> >> I'm using exec.
> >> Currently I've tried Support_Exec and find it fairly easy to
> >> use(Thanks Stepan :) ).
> >>
> >> For resources (jar files and utility classes), I make a new
> >> directory:
> >> $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument
> >> and put them there.
> >>
> >> And I meet a problem here. Currently the default classpath in
> >> running test is "$Harmony/modules/instrument/bin", so it meets problem
> >> in loading those utility classes (it can load jar files though).
> >> I remember Mark has plan to change the classpath in running
> >> testcase, it'll be great if he make some progress.
> >>
> >> An another problem is checking, currently the result is checked by
> >> searching and compare in string(e.g, find "someException" in result).
> >> But the framework seems fails if any exception is thrown out. Can it
> >> make a little change that it passes and returns the error message in
> >> exec?
> > Didn't catch up here, did you mean that you need to check the exception
> > message as well as exception type?
>
> Not necessary to check messages. However we can not catch those
> exceptions so we have to analysis output. For an example:
>
> run "java -javaagent:test.jar myclass"
>
> so get output:
> Exception in thread "main" java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> sun.instrument.InstrumentationImpl.loadClassAndCallPremain(Unknown So
> urce)
> Caused by: java.lang.IllegalAccessError
> ...
>
> In this case we can search for "InvocationTargetException" in the output
> to ensure the expected exception. Sometimes we may also check "cause by"
> exceptions.
>
> This approach seems not perfect. Any comments/suggestions? Thanks!
>
> <snip>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument]
Documents for non-unit-tests)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Paulex Yang wrote:
> Jimmy, Jing Lv wrote:
>> Hi,
>>
>> I'm trying to write some unit tests of instrument. As discussed,
>> I'm using exec.
>> Currently I've tried Support_Exec and find it fairly easy to
>> use(Thanks Stepan :) ).
>>
>> For resources (jar files and utility classes), I make a new
>> directory:
>> $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument
>> and put them there.
>>
>> And I meet a problem here. Currently the default classpath in
>> running test is "$Harmony/modules/instrument/bin", so it meets problem
>> in loading those utility classes (it can load jar files though).
>> I remember Mark has plan to change the classpath in running
>> testcase, it'll be great if he make some progress.
>>
>> An another problem is checking, currently the result is checked by
>> searching and compare in string(e.g, find "someException" in result).
>> But the framework seems fails if any exception is thrown out. Can it
>> make a little change that it passes and returns the error message in
>> exec?
> Didn't catch up here, did you mean that you need to check the exception
> message as well as exception type?
Not necessary to check messages. However we can not catch those
exceptions so we have to analysis output. For an example:
run "java -javaagent:test.jar myclass"
so get output:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
sun.instrument.InstrumentationImpl.loadClassAndCallPremain(Unknown So
urce)
Caused by: java.lang.IllegalAccessError
...
In this case we can search for "InvocationTargetException" in the output
to ensure the expected exception. Sometimes we may also check "cause by"
exceptions.
This approach seems not perfect. Any comments/suggestions? Thanks!
<snip>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument]
Documents for non-unit-tests)
Posted by Paulex Yang <pa...@gmail.com>.
Jimmy, Jing Lv wrote:
> Hi,
>
> I'm trying to write some unit tests of instrument. As discussed,
> I'm using exec.
> Currently I've tried Support_Exec and find it fairly easy to
> use(Thanks Stepan :) ).
>
> For resources (jar files and utility classes), I make a new
> directory:
> $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument
> and put them there.
>
> And I meet a problem here. Currently the default classpath in
> running test is "$Harmony/modules/instrument/bin", so it meets problem
> in loading those utility classes (it can load jar files though).
> I remember Mark has plan to change the classpath in running
> testcase, it'll be great if he make some progress.
>
> An another problem is checking, currently the result is checked by
> searching and compare in string(e.g, find "someException" in result).
> But the framework seems fails if any exception is thrown out. Can it
> make a little change that it passes and returns the error message in
> exec?
Didn't catch up here, did you mean that you need to check the exception
message as well as exception type?
>
>
> Jimmy, Jing Lv wrote:
>> Stepan Mishura wrote:
>>> On 8/7/06, *Jimmy, Jing Lv* wrote:
>>>
>>> <SNIP>
>>> Sounds pretty good :)
>>> "exec" do helps, it can check simple situations.
>>> What I'm concern is that if the return code is not enough for some
>>> situations, e.g, what exception is thrown exactly, or what cause
>>> VM exit
>>> abnormally. IMHO, it is still necessary for us.
>>>
>>>
>>> Hi Jimmy,
>>>
>>> See attached test. It demonstrates VM forking. The test saves VM
>>> output and prints it in the end.
>>> So I expect that unit tests for 'instrument' module can do the same:
>>> fork VM with predefined args, save output and compare it with
>>> expected output.
>>>
>>> BWT, we have utility class[1] in 'support' for this task. It makes
>>> sense to improve it for our needs.
>>>
>>> Thanks,
>>> Stepan.
>>>
>>
>> Thanks Stepan, this is very attractive to me :)
>>
>> According to your approach, I believe now it can be automatized well,
>> at least for many test.
>>
>> One concern from me is that, how do you handle output comparison? For
>> an example, if VM halt with a exception, it output some message, so
>> you get the output, find the exception name in it? And what can we do
>> if it output some information only, which RI and Harmony may not
>> appear the same?
>>
>> However this is a good idea, if no objections, I shall follow this
>> approach in writing some test of instrument.
>>
>>> [1]
>>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058&view=markup
>>> <http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058&view=markup>
>>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
[classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument]
Documents for non-unit-tests)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Hi,
I'm trying to write some unit tests of instrument. As discussed,
I'm using exec.
Currently I've tried Support_Exec and find it fairly easy to
use(Thanks Stepan :) ).
For resources (jar files and utility classes), I make a new directory:
$Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument
and put them there.
And I meet a problem here. Currently the default classpath in
running test is "$Harmony/modules/instrument/bin", so it meets problem
in loading those utility classes (it can load jar files though).
I remember Mark has plan to change the classpath in running
testcase, it'll be great if he make some progress.
An another problem is checking, currently the result is checked by
searching and compare in string(e.g, find "someException" in result).
But the framework seems fails if any exception is thrown out. Can it
make a little change that it passes and returns the error message in exec?
Jimmy, Jing Lv wrote:
> Stepan Mishura wrote:
>> On 8/7/06, *Jimmy, Jing Lv* wrote:
>>
>> <SNIP>
>> Sounds pretty good :)
>> "exec" do helps, it can check simple situations.
>> What I'm concern is that if the return code is not enough for some
>> situations, e.g, what exception is thrown exactly, or what cause
>> VM exit
>> abnormally. IMHO, it is still necessary for us.
>>
>>
>> Hi Jimmy,
>>
>> See attached test. It demonstrates VM forking. The test saves VM
>> output and prints it in the end.
>> So I expect that unit tests for 'instrument' module can do the same:
>> fork VM with predefined args, save output and compare it with expected
>> output.
>>
>> BWT, we have utility class[1] in 'support' for this task. It makes
>> sense to improve it for our needs.
>>
>> Thanks,
>> Stepan.
>>
>
> Thanks Stepan, this is very attractive to me :)
>
> According to your approach, I believe now it can be automatized well, at
> least for many test.
>
> One concern from me is that, how do you handle output comparison? For an
> example, if VM halt with a exception, it output some message, so you get
> the output, find the exception name in it? And what can we do if it
> output some information only, which RI and Harmony may not appear the same?
>
> However this is a good idea, if no objections, I shall follow this
> approach in writing some test of instrument.
>
>> [1]
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058&view=markup
>> <http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058&view=markup>
>>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Stepan Mishura wrote:
> On 8/7/06, *Jimmy, Jing Lv* wrote:
>
> <SNIP>
> Sounds pretty good :)
> "exec" do helps, it can check simple situations.
> What I'm concern is that if the return code is not enough for some
> situations, e.g, what exception is thrown exactly, or what cause VM exit
> abnormally. IMHO, it is still necessary for us.
>
>
> Hi Jimmy,
>
> See attached test. It demonstrates VM forking. The test saves VM
> output and prints it in the end.
> So I expect that unit tests for 'instrument' module can do the same:
> fork VM with predefined args, save output and compare it with expected
> output.
>
> BWT, we have utility class[1] in 'support' for this task. It makes sense
> to improve it for our needs.
>
> Thanks,
> Stepan.
>
Thanks Stepan, this is very attractive to me :)
According to your approach, I believe now it can be automatized well, at
least for many test.
One concern from me is that, how do you handle output comparison? For an
example, if VM halt with a exception, it output some message, so you get
the output, find the exception name in it? And what can we do if it
output some information only, which RI and Harmony may not appear the same?
However this is a good idea, if no objections, I shall follow this
approach in writing some test of instrument.
> [1]
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058&view=markup
> <http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058&view=markup>
>
> > On 8/7/06, Jimmy, Jing Lv <firepure@gmail.com
> <ma...@gmail.com>> wrote:
> >>
> >> Geir Magnusson Jr wrote:
> >> >
> >> > Jimmy, Jing Lv wrote:
> >> >> Richard Liang wrote:
> >> >>>
> >> >>> Jimmy, Jing Lv wrote:
> >> >>>> Hi,
> >> >>>>
> >> >>>> As it is hard to write unit test for package
> instrument, I now
> >> >>>> have an idea: write down some documents for details of
> non-unit test
> >> >>>> cases for instrument. The detail of such test cases contain:
> >> >>> Do you mean it's hard to *write* unit test or it's hard to
> integrate
> >> >>> the tests with Harmony build system?
> >> >>>
> >> >> Hard to write unit test, so record them in some document may be a
> >> better
> >> >> way :)
> >> >
> >> > Why is it hard to create unit tests?
> >> >
> >>
> >> To test java.lang.instrument, mostly we need to start up a new
> VM to see
> >> its behavior. Its function(premain, etc) may be run before most
> classes
> >> loaded, and almost all exceptions will cause VM abort. And the
> result is
> >> hard to be checked automatic. What's more, extra java/c code is
> needed
> >> for the test.
> >>
> >> One thought was that we can use exec("java commands") in
> junit(is that
> >> OK to run exec in tests?), but how to check its output is still a
> >> problem.
> >>
> >> I'll put unit test if any, but I believe most necessary and
> important
> >> tests are non-unit tests.
> >>
> >> >>>> 1. The test run on which platform, including special
> environment;
> >> >>>> 2. The test description;
> >> >>>> 3. How to run test (command line, etc.);
> >> >>>> 4. test result;
> >> >>>> 5. resource (or links) for tests, including c/java code for
> test if
> >> any.
> >> >>>>
> >> >>>> I hope ensure the code quality in this way. Like unit
> test, such
> >> >>>> tests can be checked and re-run for regression, though
> >> un-automatically.
> >> >>>>
> >> >>>> And I'll put them in Harmony-wiki[1], and any
> >> test-description is
> >> >>>> welcome!. (Geir, I've found an advancement of wiki :) )
> >> >>>>
> >> >>>> Any suggestions? :)
> >> >>>>
> >> >>>> [1]http://wiki.apache.org/harmony/INSTRUMENT
> >> >>>>
> >> >>>>> Geir Magnusson Jr wrote:
> >> >>>>> Never appeal to me using a Wiki as an authority :) It's like
> >> finding
> >> >>>>> something written in chalk on the sidewalk.
> >> >>>>>
> >> >>>>> However, if you had pointed out
> >> >>>>>
> >>
> >>>>> http://incubator.apache.org/harmony/auth_cont_quest.html
> <http://incubator.apache.org/harmony/auth_cont_quest.html>
> >> >>>>>
> >> >>>>> I'd have agreed w/o having the opportunity to make fun of
> the Wiki.
> >> >>>>>
> >> >>>>> So I agree :)
> >> >>>>>
> >> >>>>> geir
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> <ma...@incubator.apache.org>
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> <ma...@incubator.apache.org>
>
>
> ------------------------------------------------------------------------
>
> import java.io.*;
>
> public class test {
>
> public static void main(String []av) throws Exception {
> Runtime r = Runtime.getRuntime();
>
> String[] args = new String[3];
>
> args[0] = System.getProperty("java.home") + "/bin/java";
> args[1] = "-showversion";
> args[2] = "NoSuchClass";
>
> Process proc = r.exec(args);
>
> MyReader err = new MyReader(proc.getErrorStream());
> MyReader out = new MyReader(proc.getInputStream());
>
> new Thread(err).start();
> new Thread(out).start();
>
> int status = proc.waitFor();
>
> System.out.println("======OUT=========");
> System.out.println(out.out.toString());
> System.out.println("======ERR=========");
> System.out.println(err.out.toString());
> System.out.println("======EXIT=========");
> System.out.println(status);
>
> }
> }
>
> class MyReader implements Runnable{
>
> InputStream in;
> ByteArrayOutputStream out = new ByteArrayOutputStream();
>
> public MyReader(InputStream in){
> this.in = in;
> }
>
> public void run() {
> try {
> for (int b = in.read(); b != -1; b = in.read()) {
> out.write(b);
> }
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> }
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Posted by Stepan Mishura <st...@gmail.com>.
On 8/7/06, Jimmy, Jing Lv wrote:
>
> <SNIP>
> Sounds pretty good :)
> "exec" do helps, it can check simple situations.
> What I'm concern is that if the return code is not enough for some
> situations, e.g, what exception is thrown exactly, or what cause VM exit
> abnormally. IMHO, it is still necessary for us.
Hi Jimmy,
See attached test. It demonstrates VM forking. The test saves VM output and
prints it in the end.
So I expect that unit tests for 'instrument' module can do the same: fork VM
with predefined args, save output and compare it with expected output.
BWT, we have utility class[1] in 'support' for this task. It makes sense to
improve it for our needs.
Thanks,
Stepan.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058&view=markup
> On 8/7/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
> >>
> >> Geir Magnusson Jr wrote:
> >> >
> >> > Jimmy, Jing Lv wrote:
> >> >> Richard Liang wrote:
> >> >>>
> >> >>> Jimmy, Jing Lv wrote:
> >> >>>> Hi,
> >> >>>>
> >> >>>> As it is hard to write unit test for package instrument, I now
> >> >>>> have an idea: write down some documents for details of non-unit
> test
> >> >>>> cases for instrument. The detail of such test cases contain:
> >> >>> Do you mean it's hard to *write* unit test or it's hard to
> integrate
> >> >>> the tests with Harmony build system?
> >> >>>
> >> >> Hard to write unit test, so record them in some document may be a
> >> better
> >> >> way :)
> >> >
> >> > Why is it hard to create unit tests?
> >> >
> >>
> >> To test java.lang.instrument, mostly we need to start up a new VM to
> see
> >> its behavior. Its function(premain, etc) may be run before most classes
> >> loaded, and almost all exceptions will cause VM abort. And the result
> is
> >> hard to be checked automatic. What's more, extra java/c code is needed
> >> for the test.
> >>
> >> One thought was that we can use exec("java commands") in junit(is that
> >> OK to run exec in tests?), but how to check its output is still a
> >> problem.
> >>
> >> I'll put unit test if any, but I believe most necessary and important
> >> tests are non-unit tests.
> >>
> >> >>>> 1. The test run on which platform, including special environment;
> >> >>>> 2. The test description;
> >> >>>> 3. How to run test (command line, etc.);
> >> >>>> 4. test result;
> >> >>>> 5. resource (or links) for tests, including c/java code for test
> if
> >> any.
> >> >>>>
> >> >>>> I hope ensure the code quality in this way. Like unit test,
> such
> >> >>>> tests can be checked and re-run for regression, though
> >> un-automatically.
> >> >>>>
> >> >>>> And I'll put them in Harmony-wiki[1], and any
> >> test-description is
> >> >>>> welcome!. (Geir, I've found an advancement of wiki :) )
> >> >>>>
> >> >>>> Any suggestions? :)
> >> >>>>
> >> >>>> [1]http://wiki.apache.org/harmony/INSTRUMENT
> >> >>>>
> >> >>>>> Geir Magnusson Jr wrote:
> >> >>>>> Never appeal to me using a Wiki as an authority :) It's like
> >> finding
> >> >>>>> something written in chalk on the sidewalk.
> >> >>>>>
> >> >>>>> However, if you had pointed out
> >> >>>>>
> >> >>>>> http://incubator.apache.org/harmony/auth_cont_quest.html
> >> >>>>>
> >> >>>>> I'd have agreed w/o having the opportunity to make fun of the
> Wiki.
> >> >>>>>
> >> >>>>> So I agree :)
> >> >>>>>
> >> >>>>> geir
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Leo Li wrote:
> Hi, all:
> I have some idea to test instrument.
> For example, if we would like to test
> Instrumentation.addTransformerwill throw NullPointerException if the
> argument is null,
> we can first write a TestInstrument with premain function.
>
> import java.lang.instrument.Instrumentation;
> public class TestInstrument {
>
> public static void premain(String agentArgs, Instrumentation inst)
> {
> try
> {
> inst.addTransformer(null);
> }
> catch(NullPointerException e)
> {
> //failed, we set error code
> System.exit(1);
> }
> }
> }
> Normally, the VM will exit with zero as it return value if there is no
> exception occurs in main class.
>
> then, we might write an JUnit Test:
> public void test() throws Exception
> {
> Process process = Runtime.getRuntime().exec("java -javaagent
> Test.jarTest");
> //if premain runs as we expected, the exit code is zero.
> assertEquals(0,process.waitFor());
> }
>
> (Besides,Test is an ordinary class with a main function that will not throw
> error. Test.jar with the manifest to denote the class of TestInstrument as
> the premain class.}
>
> Is it all right? :)
>
Sounds pretty good :)
"exec" do helps, it can check simple situations.
What I'm concern is that if the return code is not enough for some
situations, e.g, what exception is thrown exactly, or what cause VM exit
abnormally. IMHO, it is still necessary for us.
> On 8/7/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
>>
>> Geir Magnusson Jr wrote:
>> >
>> > Jimmy, Jing Lv wrote:
>> >> Richard Liang wrote:
>> >>>
>> >>> Jimmy, Jing Lv wrote:
>> >>>> Hi,
>> >>>>
>> >>>> As it is hard to write unit test for package instrument, I now
>> >>>> have an idea: write down some documents for details of non-unit test
>> >>>> cases for instrument. The detail of such test cases contain:
>> >>> Do you mean it's hard to *write* unit test or it's hard to integrate
>> >>> the tests with Harmony build system?
>> >>>
>> >> Hard to write unit test, so record them in some document may be a
>> better
>> >> way :)
>> >
>> > Why is it hard to create unit tests?
>> >
>>
>> To test java.lang.instrument, mostly we need to start up a new VM to see
>> its behavior. Its function(premain, etc) may be run before most classes
>> loaded, and almost all exceptions will cause VM abort. And the result is
>> hard to be checked automatic. What's more, extra java/c code is needed
>> for the test.
>>
>> One thought was that we can use exec("java commands") in junit(is that
>> OK to run exec in tests?), but how to check its output is still a
>> problem.
>>
>> I'll put unit test if any, but I believe most necessary and important
>> tests are non-unit tests.
>>
>> >>>> 1. The test run on which platform, including special environment;
>> >>>> 2. The test description;
>> >>>> 3. How to run test (command line, etc.);
>> >>>> 4. test result;
>> >>>> 5. resource (or links) for tests, including c/java code for test if
>> any.
>> >>>>
>> >>>> I hope ensure the code quality in this way. Like unit test, such
>> >>>> tests can be checked and re-run for regression, though
>> un-automatically.
>> >>>>
>> >>>> And I'll put them in Harmony-wiki[1], and any
>> test-description is
>> >>>> welcome!. (Geir, I've found an advancement of wiki :) )
>> >>>>
>> >>>> Any suggestions? :)
>> >>>>
>> >>>> [1]http://wiki.apache.org/harmony/INSTRUMENT
>> >>>>
>> >>>>> Geir Magnusson Jr wrote:
>> >>>>> Never appeal to me using a Wiki as an authority :) It's like
>> finding
>> >>>>> something written in chalk on the sidewalk.
>> >>>>>
>> >>>>> However, if you had pointed out
>> >>>>>
>> >>>>> http://incubator.apache.org/harmony/auth_cont_quest.html
>> >>>>>
>> >>>>> I'd have agreed w/o having the opportunity to make fun of the Wiki.
>> >>>>>
>> >>>>> So I agree :)
>> >>>>>
>> >>>>> geir
>> >>>>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Posted by Leo Li <li...@gmail.com>.
Hi, all:
I have some idea to test instrument.
For example, if we would like to test
Instrumentation.addTransformerwill throw NullPointerException if the
argument is null,
we can first write a TestInstrument with premain function.
import java.lang.instrument.Instrumentation;
public class TestInstrument {
public static void premain(String agentArgs, Instrumentation inst)
{
try
{
inst.addTransformer(null);
}
catch(NullPointerException e)
{
//failed, we set error code
System.exit(1);
}
}
}
Normally, the VM will exit with zero as it return value if there is no
exception occurs in main class.
then, we might write an JUnit Test:
public void test() throws Exception
{
Process process = Runtime.getRuntime().exec("java -javaagent Test.jarTest");
//if premain runs as we expected, the exit code is zero.
assertEquals(0,process.waitFor());
}
(Besides,Test is an ordinary class with a main function that will not throw
error. Test.jar with the manifest to denote the class of TestInstrument as
the premain class.}
Is it all right? :)
On 8/7/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
>
> Geir Magnusson Jr wrote:
> >
> > Jimmy, Jing Lv wrote:
> >> Richard Liang wrote:
> >>>
> >>> Jimmy, Jing Lv wrote:
> >>>> Hi,
> >>>>
> >>>> As it is hard to write unit test for package instrument, I now
> >>>> have an idea: write down some documents for details of non-unit test
> >>>> cases for instrument. The detail of such test cases contain:
> >>> Do you mean it's hard to *write* unit test or it's hard to integrate
> >>> the tests with Harmony build system?
> >>>
> >> Hard to write unit test, so record them in some document may be a
> better
> >> way :)
> >
> > Why is it hard to create unit tests?
> >
>
> To test java.lang.instrument, mostly we need to start up a new VM to see
> its behavior. Its function(premain, etc) may be run before most classes
> loaded, and almost all exceptions will cause VM abort. And the result is
> hard to be checked automatic. What's more, extra java/c code is needed
> for the test.
>
> One thought was that we can use exec("java commands") in junit(is that
> OK to run exec in tests?), but how to check its output is still a problem.
>
> I'll put unit test if any, but I believe most necessary and important
> tests are non-unit tests.
>
> >>>> 1. The test run on which platform, including special environment;
> >>>> 2. The test description;
> >>>> 3. How to run test (command line, etc.);
> >>>> 4. test result;
> >>>> 5. resource (or links) for tests, including c/java code for test if
> any.
> >>>>
> >>>> I hope ensure the code quality in this way. Like unit test, such
> >>>> tests can be checked and re-run for regression, though
> un-automatically.
> >>>>
> >>>> And I'll put them in Harmony-wiki[1], and any test-description is
> >>>> welcome!. (Geir, I've found an advancement of wiki :) )
> >>>>
> >>>> Any suggestions? :)
> >>>>
> >>>> [1]http://wiki.apache.org/harmony/INSTRUMENT
> >>>>
> >>>>> Geir Magnusson Jr wrote:
> >>>>> Never appeal to me using a Wiki as an authority :) It's like
> finding
> >>>>> something written in chalk on the sidewalk.
> >>>>>
> >>>>> However, if you had pointed out
> >>>>>
> >>>>> http://incubator.apache.org/harmony/auth_cont_quest.html
> >>>>>
> >>>>> I'd have agreed w/o having the opportunity to make fun of the Wiki.
> >>>>>
> >>>>> So I agree :)
> >>>>>
> >>>>> geir
> >>>>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Geir Magnusson Jr wrote:
>
> Jimmy, Jing Lv wrote:
>> Richard Liang wrote:
>>>
>>> Jimmy, Jing Lv wrote:
>>>> Hi,
>>>>
>>>> As it is hard to write unit test for package instrument, I now
>>>> have an idea: write down some documents for details of non-unit test
>>>> cases for instrument. The detail of such test cases contain:
>>> Do you mean it's hard to *write* unit test or it's hard to integrate
>>> the tests with Harmony build system?
>>>
>> Hard to write unit test, so record them in some document may be a better
>> way :)
>
> Why is it hard to create unit tests?
>
To test java.lang.instrument, mostly we need to start up a new VM to see
its behavior. Its function(premain, etc) may be run before most classes
loaded, and almost all exceptions will cause VM abort. And the result is
hard to be checked automatic. What's more, extra java/c code is needed
for the test.
One thought was that we can use exec("java commands") in junit(is that
OK to run exec in tests?), but how to check its output is still a problem.
I'll put unit test if any, but I believe most necessary and important
tests are non-unit tests.
>>>> 1. The test run on which platform, including special environment;
>>>> 2. The test description;
>>>> 3. How to run test (command line, etc.);
>>>> 4. test result;
>>>> 5. resource (or links) for tests, including c/java code for test if any.
>>>>
>>>> I hope ensure the code quality in this way. Like unit test, such
>>>> tests can be checked and re-run for regression, though un-automatically.
>>>>
>>>> And I'll put them in Harmony-wiki[1], and any test-description is
>>>> welcome!. (Geir, I've found an advancement of wiki :) )
>>>>
>>>> Any suggestions? :)
>>>>
>>>> [1]http://wiki.apache.org/harmony/INSTRUMENT
>>>>
>>>>> Geir Magnusson Jr wrote:
>>>>> Never appeal to me using a Wiki as an authority :) It's like finding
>>>>> something written in chalk on the sidewalk.
>>>>>
>>>>> However, if you had pointed out
>>>>>
>>>>> http://incubator.apache.org/harmony/auth_cont_quest.html
>>>>>
>>>>> I'd have agreed w/o having the opportunity to make fun of the Wiki.
>>>>>
>>>>> So I agree :)
>>>>>
>>>>> geir
>>>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jimmy, Jing Lv wrote:
> Richard Liang wrote:
>>
>>
>> Jimmy, Jing Lv wrote:
>>> Hi,
>>>
>>> As it is hard to write unit test for package instrument, I now
>>> have an idea: write down some documents for details of non-unit test
>>> cases for instrument. The detail of such test cases contain:
>> Do you mean it's hard to *write* unit test or it's hard to integrate
>> the tests with Harmony build system?
>>
>
> Hard to write unit test, so record them in some document may be a better
> way :)
Why is it hard to create unit tests?
>
>>> 1. The test run on which platform, including special environment;
>>> 2. The test description;
>>> 3. How to run test (command line, etc.);
>>> 4. test result;
>>> 5. resource (or links) for tests, including c/java code for test if any.
>>>
>>> I hope ensure the code quality in this way. Like unit test, such
>>> tests can be checked and re-run for regression, though un-automatically.
>>>
>>> And I'll put them in Harmony-wiki[1], and any test-description is
>>> welcome!. (Geir, I've found an advancement of wiki :) )
>>>
>>> Any suggestions? :)
>>>
>>> [1]http://wiki.apache.org/harmony/INSTRUMENT
>>>
>>> > Geir Magnusson Jr wrote:
>>>> Never appeal to me using a Wiki as an authority :) It's like finding
>>>> something written in chalk on the sidewalk.
>>>>
>>>> However, if you had pointed out
>>>>
>>>> http://incubator.apache.org/harmony/auth_cont_quest.html
>>>>
>>>> I'd have agreed w/o having the opportunity to make fun of the Wiki.
>>>>
>>>> So I agree :)
>>>>
>>>> geir
>>>
>>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Richard Liang wrote:
>
>
> Jimmy, Jing Lv wrote:
>> Richard Liang wrote:
>>>
>>>
>>> Jimmy, Jing Lv wrote:
>>>> Hi,
>>>>
>>>> As it is hard to write unit test for package instrument, I now
>>>> have an idea: write down some documents for details of non-unit test
>>>> cases for instrument. The detail of such test cases contain:
>>> Do you mean it's hard to *write* unit test or it's hard to integrate
>>> the tests with Harmony build system?
>>>
>>
>> Hard to write unit test, so record them in some document may be a
>> better way :)
>>
> Sounds reasonable :-) But what does the "test" mean in "3. How to run
> test (command line, etc.); "? Do you mean we will test instrument
> manually? Please correct me if I'm wrong. Thanks a lot.
Yes, if no automatic way can be use to run the documented test, I guess
we should setup environment, build java/c code, and run on command
lines. In this way, such guide to these special test may be necessary.
>>>> 1. The test run on which platform, including special environment;
>>>> 2. The test description;
>>>> 3. How to run test (command line, etc.);
>>>> 4. test result;
>>>> 5. resource (or links) for tests, including c/java code for test if
>>>> any.
>>>>
>>>> I hope ensure the code quality in this way. Like unit test, such
>>>> tests can be checked and re-run for regression, though
>>>> un-automatically.
>>>>
>>>> And I'll put them in Harmony-wiki[1], and any test-description
>>>> is welcome!. (Geir, I've found an advancement of wiki :) )
>>>>
>>>> Any suggestions? :)
>>>>
>>>> [1]http://wiki.apache.org/harmony/INSTRUMENT
>>>>
>>>> > Geir Magnusson Jr wrote:
>>>>> Never appeal to me using a Wiki as an authority :) It's like finding
>>>>> something written in chalk on the sidewalk.
>>>>>
>>>>> However, if you had pointed out
>>>>>
>>>>> http://incubator.apache.org/harmony/auth_cont_quest.html
>>>>>
>>>>> I'd have agreed w/o having the opportunity to make fun of the Wiki.
>>>>>
>>>>> So I agree :)
>>>>>
>>>>> geir
>>>>
>>>>
>>>
>>
>>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by Richard Liang <ri...@gmail.com>.
Jimmy, Jing Lv wrote:
> Richard Liang wrote:
>>
>>
>> Jimmy, Jing Lv wrote:
>>> Hi,
>>>
>>> As it is hard to write unit test for package instrument, I now
>>> have an idea: write down some documents for details of non-unit test
>>> cases for instrument. The detail of such test cases contain:
>> Do you mean it's hard to *write* unit test or it's hard to integrate
>> the tests with Harmony build system?
>>
>
> Hard to write unit test, so record them in some document may be a
> better way :)
>
Sounds reasonable :-) But what does the "test" mean in "3. How to run
test (command line, etc.); "? Do you mean we will test instrument
manually? Please correct me if I'm wrong. Thanks a lot.
>>> 1. The test run on which platform, including special environment;
>>> 2. The test description;
>>> 3. How to run test (command line, etc.);
>>> 4. test result;
>>> 5. resource (or links) for tests, including c/java code for test if
>>> any.
>>>
>>> I hope ensure the code quality in this way. Like unit test, such
>>> tests can be checked and re-run for regression, though
>>> un-automatically.
>>>
>>> And I'll put them in Harmony-wiki[1], and any test-description
>>> is welcome!. (Geir, I've found an advancement of wiki :) )
>>>
>>> Any suggestions? :)
>>>
>>> [1]http://wiki.apache.org/harmony/INSTRUMENT
>>>
>>> > Geir Magnusson Jr wrote:
>>>> Never appeal to me using a Wiki as an authority :) It's like finding
>>>> something written in chalk on the sidewalk.
>>>>
>>>> However, if you had pointed out
>>>>
>>>> http://incubator.apache.org/harmony/auth_cont_quest.html
>>>>
>>>> I'd have agreed w/o having the opportunity to make fun of the Wiki.
>>>>
>>>> So I agree :)
>>>>
>>>> geir
>>>
>>>
>>
>
>
--
Richard Liang
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Richard Liang wrote:
>
>
> Jimmy, Jing Lv wrote:
>> Hi,
>>
>> As it is hard to write unit test for package instrument, I now
>> have an idea: write down some documents for details of non-unit test
>> cases for instrument. The detail of such test cases contain:
> Do you mean it's hard to *write* unit test or it's hard to integrate the
> tests with Harmony build system?
>
Hard to write unit test, so record them in some document may be a better
way :)
>> 1. The test run on which platform, including special environment;
>> 2. The test description;
>> 3. How to run test (command line, etc.);
>> 4. test result;
>> 5. resource (or links) for tests, including c/java code for test if any.
>>
>> I hope ensure the code quality in this way. Like unit test, such
>> tests can be checked and re-run for regression, though un-automatically.
>>
>> And I'll put them in Harmony-wiki[1], and any test-description is
>> welcome!. (Geir, I've found an advancement of wiki :) )
>>
>> Any suggestions? :)
>>
>> [1]http://wiki.apache.org/harmony/INSTRUMENT
>>
>> > Geir Magnusson Jr wrote:
>>> Never appeal to me using a Wiki as an authority :) It's like finding
>>> something written in chalk on the sidewalk.
>>>
>>> However, if you had pointed out
>>>
>>> http://incubator.apache.org/harmony/auth_cont_quest.html
>>>
>>> I'd have agreed w/o having the opportunity to make fun of the Wiki.
>>>
>>> So I agree :)
>>>
>>> geir
>>
>>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by Richard Liang <ri...@gmail.com>.
Jimmy, Jing Lv wrote:
> Hi,
>
> As it is hard to write unit test for package instrument, I now
> have an idea: write down some documents for details of non-unit test
> cases for instrument. The detail of such test cases contain:
Do you mean it's hard to *write* unit test or it's hard to integrate the
tests with Harmony build system?
> 1. The test run on which platform, including special environment;
> 2. The test description;
> 3. How to run test (command line, etc.);
> 4. test result;
> 5. resource (or links) for tests, including c/java code for test if any.
>
> I hope ensure the code quality in this way. Like unit test, such
> tests can be checked and re-run for regression, though un-automatically.
>
> And I'll put them in Harmony-wiki[1], and any test-description is
> welcome!. (Geir, I've found an advancement of wiki :) )
>
> Any suggestions? :)
>
> [1]http://wiki.apache.org/harmony/INSTRUMENT
>
> > Geir Magnusson Jr wrote:
>> Never appeal to me using a Wiki as an authority :) It's like finding
>> something written in chalk on the sidewalk.
>>
>> However, if you had pointed out
>>
>> http://incubator.apache.org/harmony/auth_cont_quest.html
>>
>> I'd have agreed w/o having the opportunity to make fun of the Wiki.
>>
>> So I agree :)
>>
>> geir
>
>
--
Richard Liang
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Paulex Yang wrote:
> Jimmy, Jing Lv wrote:
>> Hi,
>>
>> As it is hard to write unit test for package instrument, I now
>> have an idea: write down some documents for details of non-unit test
>> cases for instrument. The detail of such test cases contain:
>> 1. The test run on which platform, including special environment;
>> 2. The test description;
>> 3. How to run test (command line, etc.);
>> 4. test result;
>> 5. resource (or links) for tests, including c/java code for test if any.
>>
>> I hope ensure the code quality in this way. Like unit test, such
>> tests can be checked and re-run for regression, though un-automatically.
> You mean these tests' result need to be checked manually? I think it is
> not acceptable. IIUC, the issue here is some instrument agent needs to
> be specified in JVM args, so these tests are somthing that need special
> startup configuration, we can find a way to handle these tests, say,
> specify the configuration in instrument's build.xml, we can even fork a
> new JVM process per these tests, (Not sure if TestNG has any special
> support for this?).
Sorry I did not explain myself very well. Some of the tests for
instrument, IMO, can not be test automatic well. However, other tests of
instrument can be certainly written into unit test, or check automatic.
The main difference between the tests of instrument and other modules is
that it should raise a new VM to run. I believe it can be controlled by
ant or something.
Most happy paths can be checked automatic, e.g, check if the certain
class has been transformed, the size of the object is correct, etc.
However, there are still lots of things that can not be checked well: VM
crashes, exceptions, and special output by VM, etc. These documented and
undocumented behavior should be checked carefully, but is not easy for
automatization as I have explained. Only in this situation shall I take
action to document them down as tests.
After all, any suggestion on these special tests are welcome. I hope we
can find out a way to deal these issue without documents, but with an
automatic mechanism.
>>
>> And I'll put them in Harmony-wiki[1], and any test-description is
>> welcome!. (Geir, I've found an advancement of wiki :) )
>>
>> Any suggestions? :)
>>
>> [1]http://wiki.apache.org/harmony/INSTRUMENT
>>
>> > Geir Magnusson Jr wrote:
>>> Never appeal to me using a Wiki as an authority :) It's like finding
>>> something written in chalk on the sidewalk.
>>>
>>> However, if you had pointed out
>>>
>>> http://incubator.apache.org/harmony/auth_cont_quest.html
>>>
>>> I'd have agreed w/o having the opportunity to make fun of the Wiki.
>>>
>>> So I agree :)
>>>
>>> geir
>>
>>
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by Paulex Yang <pa...@gmail.com>.
Jimmy, Jing Lv wrote:
> Hi,
>
> As it is hard to write unit test for package instrument, I now
> have an idea: write down some documents for details of non-unit test
> cases for instrument. The detail of such test cases contain:
> 1. The test run on which platform, including special environment;
> 2. The test description;
> 3. How to run test (command line, etc.);
> 4. test result;
> 5. resource (or links) for tests, including c/java code for test if any.
>
> I hope ensure the code quality in this way. Like unit test, such
> tests can be checked and re-run for regression, though un-automatically.
You mean these tests' result need to be checked manually? I think it is
not acceptable. IIUC, the issue here is some instrument agent needs to
be specified in JVM args, so these tests are somthing that need special
startup configuration, we can find a way to handle these tests, say,
specify the configuration in instrument's build.xml, we can even fork a
new JVM process per these tests, (Not sure if TestNG has any special
support for this?).
>
> And I'll put them in Harmony-wiki[1], and any test-description is
> welcome!. (Geir, I've found an advancement of wiki :) )
>
> Any suggestions? :)
>
> [1]http://wiki.apache.org/harmony/INSTRUMENT
>
> > Geir Magnusson Jr wrote:
>> Never appeal to me using a Wiki as an authority :) It's like finding
>> something written in chalk on the sidewalk.
>>
>> However, if you had pointed out
>>
>> http://incubator.apache.org/harmony/auth_cont_quest.html
>>
>> I'd have agreed w/o having the opportunity to make fun of the Wiki.
>>
>> So I agree :)
>>
>> geir
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
[classlib][Instrument] Documents for non-unit-tests (was Re:[classlib]
Plan on work on java.lang.instrument)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Hi,
As it is hard to write unit test for package instrument, I now have
an idea: write down some documents for details of non-unit test cases
for instrument. The detail of such test cases contain:
1. The test run on which platform, including special environment;
2. The test description;
3. How to run test (command line, etc.);
4. test result;
5. resource (or links) for tests, including c/java code for test if any.
I hope ensure the code quality in this way. Like unit test, such
tests can be checked and re-run for regression, though un-automatically.
And I'll put them in Harmony-wiki[1], and any test-description is
welcome!. (Geir, I've found an advancement of wiki :) )
Any suggestions? :)
[1]http://wiki.apache.org/harmony/INSTRUMENT
> Geir Magnusson Jr wrote:
> Never appeal to me using a Wiki as an authority :) It's like finding
> something written in chalk on the sidewalk.
>
> However, if you had pointed out
>
> http://incubator.apache.org/harmony/auth_cont_quest.html
>
> I'd have agreed w/o having the opportunity to make fun of the Wiki.
>
> So I agree :)
>
> geir
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Never appeal to me using a Wiki as an authority :) It's like finding
something written in chalk on the sidewalk.
However, if you had pointed out
http://incubator.apache.org/harmony/auth_cont_quest.html
I'd have agreed w/o having the opportunity to make fun of the Wiki.
So I agree :)
geir
Stepan Mishura wrote:
> Yes, it is. But accoriding to [1] the code should be put into separate
> 'instrument' module.
> So the patch should start with 'modules/'instrument'.
>
> Thanks,
> Stepan.
> [1]http://wiki.apache.org/harmony/componentization
>
>
> On 8/2/06, Geir Magnusson Jr wrote:
>>
>> It is a lang package, right?
>>
>> Stepan Mishura wrote:
>> > On 8/2/06, Jimmy, Jing Lv wrote:
>> >>
>> >> Hi,
>> >>
>> >> If no objection, I shall go on with the plan of instrument :)
>> >> Refer to Harmony status page[1], INSTRUMENT is missing, so this
>> >> module shall named as "instrument". I shall open a wiki-page for its
>> >> status like other modules on [2].
>> >>
>> >> For Java codes, API classes/interfaces can be added to
>> >> modules/luni/src/main/java/java/lang/instrument, and implementation
>> can
>> >> be added to
>> >>
>> >>
>> modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument
>>
>> >>
>> >
>> >
>> > Sorry, I didn't catch why you are going to put code to 'luni' module
>> > Did you mean:
>> > modules/
>> > instrument/
>> > src/main/java/java/lang/instrument
>> > src/main/java/org/apache/harmony/luni/internal/lang/instrument
>> >
>> > Thanks,
>> > Stepan.
>> >
>> > For native codes, instrument need a new directory in
>> >> modules/luni/src/main/native named "instrument", in my plan, there
>> >> should be two native code, one for instrument native implementation,
>> and
>> >> another for laugher (for parameter "-javaagent"). Instrument shall be
>> >> compiled into a .DLL(.so) file alone.
>> >>
>> >> Any suggestions? Thanks! :)
>> >>
>> >>
>> >>
>> [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
>>
>> >>
>> >> [2]http://wiki.apache.org/harmony/INSTRUMENT
>> >>
>> >>
>> >> --
>> >>
>> >> Best Regards!
>> >>
>> >> Jimmy, Jing Lv
>> >> China Software Development Lab, IBM
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Stepan Mishura wrote:
> Yes, it is. But accoriding to [1] the code should be put into separate
> 'instrument' module.
> So the patch should start with 'modules/'instrument'.
>
Ah ... you are right, thanks very much Stepan! :)
So I shall put code to
modules/
instrument/
src/main/java/java/lang/instrument
> Thanks,
> Stepan.
> [1]http://wiki.apache.org/harmony/componentization
>
>
> On 8/2/06, Geir Magnusson Jr wrote:
>>
>> It is a lang package, right?
>>
>> Stepan Mishura wrote:
>> > On 8/2/06, Jimmy, Jing Lv wrote:
>> >>
>> >> Hi,
>> >>
>> >> If no objection, I shall go on with the plan of instrument :)
>> >> Refer to Harmony status page[1], INSTRUMENT is missing, so this
>> >> module shall named as "instrument". I shall open a wiki-page for its
>> >> status like other modules on [2].
>> >>
>> >> For Java codes, API classes/interfaces can be added to
>> >> modules/luni/src/main/java/java/lang/instrument, and implementation
>> can
>> >> be added to
>> >>
>> >>
>> modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument
>>
>> >>
>> >
>> >
>> > Sorry, I didn't catch why you are going to put code to 'luni' module
>> > Did you mean:
>> > modules/
>> > instrument/
>> > src/main/java/java/lang/instrument
>> > src/main/java/org/apache/harmony/luni/internal/lang/instrument
>> >
>> > Thanks,
>> > Stepan.
>> >
>> > For native codes, instrument need a new directory in
>> >> modules/luni/src/main/native named "instrument", in my plan, there
>> >> should be two native code, one for instrument native implementation,
>> and
>> >> another for laugher (for parameter "-javaagent"). Instrument shall be
>> >> compiled into a .DLL(.so) file alone.
>> >>
>> >> Any suggestions? Thanks! :)
>> >>
>> >>
>> >>
>> [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
>>
>> >>
>> >> [2]http://wiki.apache.org/harmony/INSTRUMENT
>> >>
>> >>
>> >> --
>> >>
>> >> Best Regards!
>> >>
>> >> Jimmy, Jing Lv
>> >> China Software Development Lab, IBM
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by Stepan Mishura <st...@gmail.com>.
Yes, it is. But accoriding to [1] the code should be put into separate
'instrument' module.
So the patch should start with 'modules/'instrument'.
Thanks,
Stepan.
[1]http://wiki.apache.org/harmony/componentization
On 8/2/06, Geir Magnusson Jr wrote:
>
> It is a lang package, right?
>
> Stepan Mishura wrote:
> > On 8/2/06, Jimmy, Jing Lv wrote:
> >>
> >> Hi,
> >>
> >> If no objection, I shall go on with the plan of instrument :)
> >> Refer to Harmony status page[1], INSTRUMENT is missing, so this
> >> module shall named as "instrument". I shall open a wiki-page for its
> >> status like other modules on [2].
> >>
> >> For Java codes, API classes/interfaces can be added to
> >> modules/luni/src/main/java/java/lang/instrument, and implementation can
> >> be added to
> >>
> >>
> modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument
> >>
> >
> >
> > Sorry, I didn't catch why you are going to put code to 'luni' module
> > Did you mean:
> > modules/
> > instrument/
> > src/main/java/java/lang/instrument
> > src/main/java/org/apache/harmony/luni/internal/lang/instrument
> >
> > Thanks,
> > Stepan.
> >
> > For native codes, instrument need a new directory in
> >> modules/luni/src/main/native named "instrument", in my plan, there
> >> should be two native code, one for instrument native implementation,
> and
> >> another for laugher (for parameter "-javaagent"). Instrument shall be
> >> compiled into a .DLL(.so) file alone.
> >>
> >> Any suggestions? Thanks! :)
> >>
> >>
> >>
> [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
> >>
> >> [2]http://wiki.apache.org/harmony/INSTRUMENT
> >>
> >>
> >> --
> >>
> >> Best Regards!
> >>
> >> Jimmy, Jing Lv
> >> China Software Development Lab, IBM
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by Geir Magnusson Jr <ge...@pobox.com>.
It is a lang package, right?
Stepan Mishura wrote:
> On 8/2/06, Jimmy, Jing Lv wrote:
>>
>> Hi,
>>
>> If no objection, I shall go on with the plan of instrument :)
>> Refer to Harmony status page[1], INSTRUMENT is missing, so this
>> module shall named as "instrument". I shall open a wiki-page for its
>> status like other modules on [2].
>>
>> For Java codes, API classes/interfaces can be added to
>> modules/luni/src/main/java/java/lang/instrument, and implementation can
>> be added to
>>
>> modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument
>>
>
>
> Sorry, I didn't catch why you are going to put code to 'luni' module
> Did you mean:
> modules/
> instrument/
> src/main/java/java/lang/instrument
> src/main/java/org/apache/harmony/luni/internal/lang/instrument
>
> Thanks,
> Stepan.
>
> For native codes, instrument need a new directory in
>> modules/luni/src/main/native named "instrument", in my plan, there
>> should be two native code, one for instrument native implementation, and
>> another for laugher (for parameter "-javaagent"). Instrument shall be
>> compiled into a .DLL(.so) file alone.
>>
>> Any suggestions? Thanks! :)
>>
>>
>> [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
>>
>> [2]http://wiki.apache.org/harmony/INSTRUMENT
>>
>>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Jimmy, Jing Lv wrote:
> Stepan Mishura wrote:
>> On 8/2/06, Jimmy, Jing Lv wrote:
>>>
>>> Hi,
>>>
>>> If no objection, I shall go on with the plan of instrument :)
>>> Refer to Harmony status page[1], INSTRUMENT is missing, so this
>>> module shall named as "instrument". I shall open a wiki-page for its
>>> status like other modules on [2].
>>>
>>> For Java codes, API classes/interfaces can be added to
>>> modules/luni/src/main/java/java/lang/instrument, and implementation can
>>> be added to
>>>
>>> modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument
>>>
>>
>>
>> Sorry, I didn't catch why you are going to put code to 'luni' module
>> Did you mean:
>> modules/
>> instrument/
>> src/main/java/java/lang/instrument
>> src/main/java/org/apache/harmony/luni/internal/lang/instrument
>>
>
> Hi,
> It is "java.lang.instrument", so IMHO it can be put to "luni"
> module. And another reason is that it is rather small to be a single
> module. :)
>
Oops, my mail server meets some problem.
Please ignore this letter, sorry for inconvenience.
>> Thanks,
>> Stepan.
>>
>> For native codes, instrument need a new directory in
>>> modules/luni/src/main/native named "instrument", in my plan, there
>>> should be two native code, one for instrument native implementation, and
>>> another for laugher (for parameter "-javaagent"). Instrument shall be
>>> compiled into a .DLL(.so) file alone.
>>>
>>> Any suggestions? Thanks! :)
>>>
>>>
>>> [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
>>>
>>> [2]http://wiki.apache.org/harmony/INSTRUMENT
>>>
>>>
>>> --
>>>
>>> Best Regards!
>>>
>>> Jimmy, Jing Lv
>>> China Software Development Lab, IBM
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>
>>
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Stepan Mishura wrote:
> On 8/2/06, Jimmy, Jing Lv wrote:
>>
>> Hi,
>>
>> If no objection, I shall go on with the plan of instrument :)
>> Refer to Harmony status page[1], INSTRUMENT is missing, so this
>> module shall named as "instrument". I shall open a wiki-page for its
>> status like other modules on [2].
>>
>> For Java codes, API classes/interfaces can be added to
>> modules/luni/src/main/java/java/lang/instrument, and implementation can
>> be added to
>>
>> modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument
>>
>
>
> Sorry, I didn't catch why you are going to put code to 'luni' module
> Did you mean:
> modules/
> instrument/
> src/main/java/java/lang/instrument
> src/main/java/org/apache/harmony/luni/internal/lang/instrument
>
Hi,
It is "java.lang.instrument", so IMHO it can be put to "luni"
module. And another reason is that it is rather small to be a single
module. :)
> Thanks,
> Stepan.
>
> For native codes, instrument need a new directory in
>> modules/luni/src/main/native named "instrument", in my plan, there
>> should be two native code, one for instrument native implementation, and
>> another for laugher (for parameter "-javaagent"). Instrument shall be
>> compiled into a .DLL(.so) file alone.
>>
>> Any suggestions? Thanks! :)
>>
>>
>> [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
>>
>> [2]http://wiki.apache.org/harmony/INSTRUMENT
>>
>>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by Stepan Mishura <st...@gmail.com>.
On 8/2/06, Jimmy, Jing Lv wrote:
>
> Hi,
>
> If no objection, I shall go on with the plan of instrument :)
> Refer to Harmony status page[1], INSTRUMENT is missing, so this
> module shall named as "instrument". I shall open a wiki-page for its
> status like other modules on [2].
>
> For Java codes, API classes/interfaces can be added to
> modules/luni/src/main/java/java/lang/instrument, and implementation can
> be added to
>
> modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument
Sorry, I didn't catch why you are going to put code to 'luni' module
Did you mean:
modules/
instrument/
src/main/java/java/lang/instrument
src/main/java/org/apache/harmony/luni/internal/lang/instrument
Thanks,
Stepan.
For native codes, instrument need a new directory in
> modules/luni/src/main/native named "instrument", in my plan, there
> should be two native code, one for instrument native implementation, and
> another for laugher (for parameter "-javaagent"). Instrument shall be
> compiled into a .DLL(.so) file alone.
>
> Any suggestions? Thanks! :)
>
>
> [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
> [2]http://wiki.apache.org/harmony/INSTRUMENT
>
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Paulex Yang wrote:
> Gregory Shimansky wrote:
>> On Wednesday 02 August 2006 17:30 Paulex Yang wrote:
>>
>>> Alexey Varlamov wrote:
>>>
>>>> [SNIP]
>>>>
>>>>
>>>>> For native codes, instrument need a new directory in
>>>>> modules/luni/src/main/native named "instrument", in my plan, there
>>>>> should be two native code, one for instrument native
>>>>> implementation, and
>>>>> another for laugher (for parameter "-javaagent"). Instrument shall be
>>>>> compiled into a .DLL(.so) file alone.
>>>>>
>>>> Jimmy,
>>>> Could you please add some details on the launcher part? I'd rather
>>>> think that common VM launcher should be updated to support
>>>> "-javaagent:" option
>>>>
>>> Agree, it should can be handled by common launcher.
>>>
>>>
>>>> - which is basically a second class to launch.
>>>>
>>> I think there is some difference, actually I expect it parses the
>>> parameters following "-javaagent:", then converts it to
>>> "-agentlib:hyinstrument.dll..." and at last passes them to VM.
>>>
>>
>> I don't think there is any conversion required. I believe -javaagent
>> is a VM option and should be handled internally by the invocation API
>> in case there is a 3rd party launcher/plugin which tries to use VM's
>> invocation API directly. The agent library may be even linked
>> statically to VM and hidden from direct use on the command line.
>>
> The agent library (instrument implementation) is implemented in
> classlib and is independent with VM, why it needs to be linked
> statically? Even RI, which seems don't think too much on the classlib/VM
> modulazation, has the instrument.dll separated.
>
> Considering 3rd party launcher, I agree that it is convenient to put the
> -javaagent parsing in VM directly, but then VM must be aware of the
> agent lib's name, though it may be fine because it is not likely for
> Harmony to change it frequently.
Agreed with Paulex, at least it can be a convenient, VM guys can choose
using it or not. So let's make it. :)
>> On a side note, -agentlib specifies agent library in OS independent
>> way so it should be "-agentlib:hyinstrument=..."
>>
>>
> Thanks for point it out, I actually meant the same thing.
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by Gregory Shimansky <gs...@gmail.com>.
2006/8/3, Paulex Yang <pa...@gmail.com>:
>
> Gregory Shimansky wrote:
> > I don't think there is any conversion required. I believe -javaagent is
> a VM
> > option and should be handled internally by the invocation API in case
> there
> > is a 3rd party launcher/plugin which tries to use VM's invocation API
> > directly. The agent library may be even linked statically to VM and
> hidden
> > from direct use on the command line.
> >
> The agent library (instrument implementation) is implemented in
> classlib and is independent with VM, why it needs to be linked
> statically? Even RI, which seems don't think too much on the classlib/VM
> modulazation, has the instrument.dll separated.
Ok I didn't know that RI has it separated. It is fine to me if it exists as
an instrument.dll.
Considering 3rd party launcher, I agree that it is convenient to put the
> -javaagent parsing in VM directly, but then VM must be aware of the
> agent lib's name, though it may be fine because it is not likely for
> Harmony to change it frequently.
I agree. VM should know the name of this special agent.
--
Gregory Shimansky, Intel Middleware Products Division
Re: [classlib] Plan on work on java.lang.instrument
Posted by Paulex Yang <pa...@gmail.com>.
Gregory Shimansky wrote:
> On Wednesday 02 August 2006 17:30 Paulex Yang wrote:
>
>> Alexey Varlamov wrote:
>>
>>> [SNIP]
>>>
>>>
>>>> For native codes, instrument need a new directory in
>>>> modules/luni/src/main/native named "instrument", in my plan, there
>>>> should be two native code, one for instrument native implementation, and
>>>> another for laugher (for parameter "-javaagent"). Instrument shall be
>>>> compiled into a .DLL(.so) file alone.
>>>>
>>> Jimmy,
>>> Could you please add some details on the launcher part? I'd rather
>>> think that common VM launcher should be updated to support
>>> "-javaagent:" option
>>>
>> Agree, it should can be handled by common launcher.
>>
>>
>>> - which is basically a second class to launch.
>>>
>> I think there is some difference, actually I expect it parses the
>> parameters following "-javaagent:", then converts it to
>> "-agentlib:hyinstrument.dll..." and at last passes them to VM.
>>
>
> I don't think there is any conversion required. I believe -javaagent is a VM
> option and should be handled internally by the invocation API in case there
> is a 3rd party launcher/plugin which tries to use VM's invocation API
> directly. The agent library may be even linked statically to VM and hidden
> from direct use on the command line.
>
The agent library (instrument implementation) is implemented in
classlib and is independent with VM, why it needs to be linked
statically? Even RI, which seems don't think too much on the classlib/VM
modulazation, has the instrument.dll separated.
Considering 3rd party launcher, I agree that it is convenient to put the
-javaagent parsing in VM directly, but then VM must be aware of the
agent lib's name, though it may be fine because it is not likely for
Harmony to change it frequently.
> On a side note, -agentlib specifies agent library in OS independent way so it
> should be "-agentlib:hyinstrument=..."
>
>
Thanks for point it out, I actually meant the same thing.
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 02 August 2006 17:30 Paulex Yang wrote:
> Alexey Varlamov wrote:
> > [SNIP]
> >
> >> For native codes, instrument need a new directory in
> >> modules/luni/src/main/native named "instrument", in my plan, there
> >> should be two native code, one for instrument native implementation, and
> >> another for laugher (for parameter "-javaagent"). Instrument shall be
> >> compiled into a .DLL(.so) file alone.
> >
> > Jimmy,
> > Could you please add some details on the launcher part? I'd rather
> > think that common VM launcher should be updated to support
> > "-javaagent:" option
>
> Agree, it should can be handled by common launcher.
>
> > - which is basically a second class to launch.
>
> I think there is some difference, actually I expect it parses the
> parameters following "-javaagent:", then converts it to
> "-agentlib:hyinstrument.dll..." and at last passes them to VM.
I don't think there is any conversion required. I believe -javaagent is a VM
option and should be handled internally by the invocation API in case there
is a 3rd party launcher/plugin which tries to use VM's invocation API
directly. The agent library may be even linked statically to VM and hidden
from direct use on the command line.
On a side note, -agentlib specifies agent library in OS independent way so it
should be "-agentlib:hyinstrument=..."
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by Paulex Yang <pa...@gmail.com>.
Alexey Varlamov wrote:
> [SNIP]
>> For native codes, instrument need a new directory in
>> modules/luni/src/main/native named "instrument", in my plan, there
>> should be two native code, one for instrument native implementation, and
>> another for laugher (for parameter "-javaagent"). Instrument shall be
>> compiled into a .DLL(.so) file alone.
>
> Jimmy,
> Could you please add some details on the launcher part? I'd rather
> think that common VM launcher should be updated to support
> "-javaagent:" option
Agree, it should can be handled by common launcher.
> - which is basically a second class to launch.
I think there is some difference, actually I expect it parses the
parameters following "-javaagent:", then converts it to
"-agentlib:hyinstrument.dll..." and at last passes them to VM.
> --
> Alexey
>
>>
>> Any suggestions? Thanks! :)
>>
>> [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
>>
>> [2]http://wiki.apache.org/harmony/INSTRUMENT
>>
>>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Plan on work on java.lang.instrument
Posted by Alexey Varlamov <al...@gmail.com>.
[SNIP]
> For native codes, instrument need a new directory in
> modules/luni/src/main/native named "instrument", in my plan, there
> should be two native code, one for instrument native implementation, and
> another for laugher (for parameter "-javaagent"). Instrument shall be
> compiled into a .DLL(.so) file alone.
Jimmy,
Could you please add some details on the launcher part? I'd rather
think that common VM launcher should be updated to support
"-javaagent:" option - which is basically a second class to launch.
--
Alexey
>
> Any suggestions? Thanks! :)
>
> [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
> [2]http://wiki.apache.org/harmony/INSTRUMENT
>
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org