headers
pmpereira | 7 Feb 2003 16:45

BCEL J2ME jdk 1.1 compliant code generation


Hi,

Is it possible to generate code ready to be preverified and to be able to run on
MIDP?

thanks in advance...
Pedro Pereira
Permalink | Reply | 3 comments |
headers
Jose Andrés Pérez | 7 Feb 2003 16:58
Favicon

RE: BCEL J2ME jdk 1.1 compliant code generation

Every code you modify using BCEL could be run on any VM (JVM or KVM), but
you should take into account that if the code will be run on KVM you should
include the StackMap attribute (it is an attribute added to the class files
by the preverifier. This is only for CLDC applications) on the code (see the
KVM or CLDC Specifications).

Jose

> -----Original Message-----
> From:
> bcel-user-return-261-joseandres.perez=m-centric.com <at> jakarta.apache.org
> [mailto:bcel-user-return-261-joseandres.perez=m-centric.com <at> jakarta.apac
> he.org]On Behalf Of pmpereira <at> wit-software.com
> Sent: viernes, 07 de febrero de 2003 16:46
> To: bcel-user <at> jakarta.apache.org
> Subject: BCEL J2ME jdk 1.1 compliant code generation
>
>
>
> Hi,
>
> Is it possible to generate code ready to be preverified and to be
> able to run on
> MIDP?
>
> thanks in advance...
> Pedro Pereira
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-user-unsubscribe <at> jakarta.apache.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
pmpereira | 7 Feb 2003 16:56

RE: BCEL J2ME jdk 1.1 compliant code generation


Hi,

thanks a lot for your answer.

I did not found any example or documentation on including the StackMap attribute . 
Could you point me to some docs?

again, thanks a lot...
Pedro Pereira

Quoting Jose Andrés Pérez <joseandres.perez <at> m-centric.com>:

> Every code you modify using BCEL could be run on any VM (JVM or KVM), but
> you should take into account that if the code will be run on KVM you should
> include the StackMap attribute (it is an attribute added to the class files
> by the preverifier. This is only for CLDC applications) on the code (see
> the
> KVM or CLDC Specifications).
> 
> Jose
> 
> 
> > -----Original Message-----
> > From:
> > bcel-user-return-261-joseandres.perez=m-centric.com <at> jakarta.apache.org
> > [mailto:bcel-user-return-261-joseandres.perez=m-centric.com <at> jakarta.apac
> > he.org]On Behalf Of pmpereira <at> wit-software.com
> > Sent: viernes, 07 de febrero de 2003 16:46
> > To: bcel-user <at> jakarta.apache.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jose Andrés Pérez | 7 Feb 2003 17:16
Favicon

RE: BCEL J2ME jdk 1.1 compliant code generation

> I did not found any example or documentation on including the
> StackMap attribute .
> Could you point me to some docs?

You should follow the Preverifier specification on the CLDC or KVM
Specification (I don´t remember exactly). One of these documents explains to
you how the preverifier works or what it should do.

The BCEL last version includes a class that represents the StackMap
attribute.

Jose

>
> again, thanks a lot...
> Pedro Pereira
>
> Quoting Jose Andrés Pérez <joseandres.perez <at> m-centric.com>:
>
> > Every code you modify using BCEL could be run on any VM (JVM or
> KVM), but
> > you should take into account that if the code will be run on
> KVM you should
> > include the StackMap attribute (it is an attribute added to the
> class files
> > by the preverifier. This is only for CLDC applications) on the code (see
> > the
> > KVM or CLDC Specifications).
> >
> > Jose
(Continue reading)

Permalink | Reply | 0 comments |
headers
Al | 9 Feb 2003 00:33
Favicon

Copying a JavaClass with XXXGen and visitor

Hi,

Im having trouble understanding the use of the various XXXGen classes. For
my application I want to begin by copying a JavaClass. I will later wish to
have some control over this process so I was trying to use a ClassGen and a
visitor to add stuff to it. My naive attempt is below. Of course it doesnt
quite work. I imagine Ill have to make use of other XXGen classes but Im not
sure and Im not sure how. I hoped someone here would talk me through what
EmptyVisitor methods I should override and what I should be doing in them.

Any help greatly appreciated, A.

/**
 * My attempt to copy a JavaClass using ClassGen and a visitor
 */
public class EVisitor extends de.fub.bytecode.classfile.EmptyVisitor
{ private String className;
  private de.fub.bytecode.generic.ClassGen cg;
  private de.fub.bytecode.generic.ConstantPoolGen cpg;

  public static void main(String[] args)
  { try
    { de.fub.bytecode.classfile.JavaClass c = new
de.fub.bytecode.classfile.ClassParser(args[0]).parse();

      de.fub.bytecode.generic.ClassGen cg = new
de.fub.bytecode.generic.ClassGen(c.getClassName(), c.getSuperclassName(),
c.getFileName(), c.getAccessFlags(), c.getInterfaceNames());

      new de.fub.bytecode.classfile.DescendingVisitor(c, new
(Continue reading)

Permalink | Reply | 0 comments |
headers
Burt Wagner | 11 Feb 2003 19:47

Illegal constant pool index exception from the byte code verifier

I work on a project in which we instrument EJBs on Weblogic application
servers.  I have successfully instrumented EJBs on Weblogic 6.X and 7.X
servers (after many, many trials and tribulations).  Hence I have a lot
of "in the trenches" experience and success using BCEL.  However, when I
take my methodologies to Weblogic 8.X servers I am getting an error on
some - not all - of the EJBs that I instrument and it has me a bit
stumped.  What I do know that has changed is that Weblogic moved form
JDK 1.3.X to 1.4.X so I suspect that the byte code verifier may be more
picky, or at least just different.  Has anyone seen a similar issue?  I
believe that I may be just missing some step in my methodology that the
old byte code verifier did not care about but the new one does.

Also note that the EJB being instrumented is final and if I have my
system ignore (not modify) all final classes that does seem to work.
However, what has got me a bit baffled is that the verifier only
complains about a small subset of the final classes that I instrument -
most of the modified final classes are passed with no problems.

I guess the basic questions I have are:  How would the byte code
verifier even know that I have changed the class?  Why is it only
complaining about changes to final classes?  And why only some of the
final classes (not all of them)?

The error I am getting is:

[EJB:011006]Unable to bind a cluster-aware stateless session EJBObject
to the name: Patient Enterprise AppSession-EJBsRe
cordSessionEJB_EO. Please ensure that the jndi-name in the
weblogic-ejb-jar.xml is correct.
javax.naming.CommunicationException.  Root exception is
(Continue reading)

Permalink | Reply | 1 comment |
headers
Markus Dahm | 12 Feb 2003 13:01
Picon
Picon

Re: Illegal constant pool index exception from the byte code verifier

Hi,

first of all, what does JustIce say to your code?
Second, the verifier may very well be  more picky, e.g. about cp references
that are
illegal but haven't been used and things like that.
Maybe a look at the generated code would help to clear that. (listclass
-code)

Cheers
  Markus

--

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
Permalink | Reply | 0 comments |
headers
Burt Wagner | 13 Feb 2003 21:14

RE: Illegal constant pool index exception from the byte code verifier

Thanks for all your help with my "Illegal constant pool index exception."

I upgraded to the latest version of BCEL (which was a bit of a pain in the behind because of the change in
package names and the elimination of one of the classes I was using) and the problem magically went away.

Thanks again, Burt

-----Original Message-----
From: Markus Dahm [mailto:m.dahm <at> gmx.de] 
Sent: Wednesday, February 12, 2003 5:02 AM
To: BCEL Users List
Subject: Re: Illegal constant pool index exception from the byte code verifier

Hi,

first of all, what does JustIce say to your code?
Second, the verifier may very well be  more picky, e.g. about cp references
that are
illegal but haven't been used and things like that.
Maybe a look at the generated code would help to clear that. (listclass
-code)

Cheers
  Markus

--

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

---------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Cheng | 13 Feb 2003 23:41
Picon

J2ME CLDC pre-verifier

I am thinking of writing a J2ME CLDC preverifier using BCEL.

It appears that most of the functionality is already in BCEL. JustICE,
implementing Pass 3b of the verification process, already generates all the
information necessary for producing StackMap. It should be relatively easy
to modify the do_Verify() in Pass3bVerifier.java to actually generate
StackMap attributes after calling circulationPump().

Does this sounds like a plausible plan? Am I missing something?
Is there any missing functionality in JustICE that I should be aware of?
Has anyone already done this?

Thanks,
Stephen
Permalink | Reply | 1 comment |
headers
Stephen Cheng | 17 Feb 2003 09:43
Picon

J2ME CLDC pre-verifier

I am thinking of writing a J2ME CLDC preverifier using BCEL.

It appears that most of the functionality is already in BCEL. JustICE,
implementing Pass 3b of the verification process, already generates all the
information necessary for producing StackMap. It should be relatively easy
to modify the do_Verify() in Pass3bVerifier.java to actually generate
StackMap attributes after calling circulationPump().

Does this sounds like a plausible plan? Am I missing something?
Is there any missing functionality in JustICE that I should be aware of?
Has anyone already done this?

Thanks,
Stephen
Permalink | Reply | 0 comments |

Gmane