If you need to parse Java, it is safer to parse the output of javap. Admittedly that does not give you the names of the parameters as they were coded because .class files don't have the information.
I did this for Java::Swing, which includes a grammar for parsing the decompiled files in the all_listeners script in the Swing/Generate subdirectory of the distribution. Perhaps you can then go to the source trolling for parameters names with more confidence. Phil --- Jay Strauss <[EMAIL PROTECTED]> wrote: > > > > You won't find the parameters names in there > because they are not > > needed when calling a method. Java doesn't even > provide them through > > reflection. Why do you need them? > > > > Patrick > > Hi, > > The module in question is: > http://search.cpan.org/src/JSTRAUSS/Finance-InteractiveBrokers-TWS-v0.0.8/lib/Finance/InteractiveBrokers/TWS.pm > > The Inline Java methods follow the form of: > > public void tickSize(int tickerId, int field, > int size) > { > try { > perlobj.InvokeMethod("tickSize", new > Object [] { > tickerId, field, size > }); > } > catch (InlineJavaPerlException pe){ } > catch (InlineJavaException pe) { > pe.printStackTrace() ;} > } > > Where tickSize makes a callback to some user defined > Perl code > sending, positionally, the parameters defined in the > "public void > tickSize(int tickerId, int field, int size) ". > Which means, the > user/programmer has to know, beforehand, the number > and purpose of > each parm they receive. > > I thought it would be nice instead, to provide a > function to convert > the list into a hash containing the variable names > and values. That > way they don't have to read through the source to > figure out what they > are getting. > > I was just trying to make things easy for my users. > Right now I'm > using a conf file that contains the variable names, > but that sucks, > because everytime the vender changes the API, I have > to change the > Inline Java AND the conf file to match (a bug > waiting to happen). > > So I wrote a parser, to read the source of the > running module at > runtime to parse the Java and pull out the relevent > info. But I'm not > 100% confident in my regex'ing skills, so I'm afraid > something will > slip in that I didn't test for. > > So I figured maybe Inline::Java already did it for > me, and I could > sidestep my (admittedly) weak programming skills. > > Thanks > Jay > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
