[BCEL] Re: How can I recover .class references separate from other references to classes using BCEL?

[Stephan Herrmann]

quick guess: check if the previous instruction is ldc.

HTH,
Stephan

On 10.09.2017 21:50, Showalter, Jim wrote:

The use case is, suppose you want to recover the source from a .class file.

In the original source, it said:

public class SomeExperiment {
  public static void main(String[] args) {
  System.out.println(SomeOtherClass.class); <<< WANT TO RECOVER THE 
".class" FROM HERE
  }
}

In the visitor I wrote, there's an override:

  public void visitConstantClass(final ConstantClass obj) {
String className = 
JavaUtils.dotsToSlashes(javaClass().getConstantPool().getConstant(obj.getNameIndex()).toString());
   System.out.println(class file name + ": " + className);
  }

Dumping out the data on a .class from a .java file that contains no occurrences of the 
string ".class", I get:

com/intuit/qbo/Misc.class: com/intuit/qbo/Misc$Reader
com/intuit/qbo/Misc.class: com/intuit/qbo/util/SomeException
com/intuit/qbo/Misc.class: com/intuit/qbo/Misc
com/intuit/qbo/Misc.class: com/intuit/qbo/api/MiscIf

This means ClassConstant isn't just for .class references. It's for all 
references to classes.

How can I use BCEL to recover the original ".class" reference in SomeExperiment?

Jim Showalter
Programmer
Intuit, 2003H-265Z
Garcia Avenue
Mountain View, CA 94043
(408) 353-4954
(408) 204-1661





-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Release BCEL 6.1?

[Stephan Herrmann]

Hi Benedikt,

I may be too late for 6.1., but I just reallized that my patch & test in
https://issues.apache.org/jira/browse/BCEL-267 has never received an answer.

Would you mind having a quick look?

thanks,
Stephan


On 30.08.2017 20:51, Benedikt Ritter wrote:

Hello Andreas,


Am 30.08.2017 um 11:23 schrieb Andreas Sewe :

Hi Benedikt,

you wrote:

I’ll have a look into this and come back to you. Probably on Sunday since I’ll 
be on the train then and will have some time.


sounds good. Thank you for looking into this.


Sorry, no internet on the train yesterday… Looking into this tonight :o)


Any news on this? (Another journey by train planned, perhaps ;-)


I’m going through the patches pointed out by Mark Roberts [1].
Further more there are some breaking chances, and I need to find out how to 
handle them [2].

Cheers,
Benedikt

[1] 
https://lists.apache.org/thread.html/69c1fbc63fb9d9841cab3c27049fe6943cf50ce312a8ce73389ecc72@%3Cdev.commons.apache.org%3E
 

[2] 
https://lists.apache.org/thread.html/fe080d184a6a6de75b90d1df87b50e3906e5af72bc2878af7e0c4125@%3Cdev.commons.apache.org%3E
 



Best wishes,

Andreas

--
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940







-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [bcel] perspective?

[Stephan Herrmann]

Thanks, Mark,

This is very helpful information!

Please don't read my questions as demanding.
I know the tragedy of the commons.

As an Eclipse committer I'm used to time-boxed releases, but I understand
that things work differently at Apache. OK.

After playing a bit with an RC of BCEL 6.0 I have one more question:
I see that progress has been made to support the mandatory StackMapTable,
but BCEL does not automatically update this when modifying / creating an
instruction list.

So, how are people using (going to use) BCEL 6 on a JVM 8, in particular,
tools that need to create new byte codes? Are you happily adding new
Frames to the StackMapTable as you insert instructions?
In our existing implementation we forced the class file version of
modified classes to be 50.0 so that falling back to the old verifier
would still work. This probably won't work as soon as bytecodes
contain lambdas, right?

Anybody using BCEL to transform Java 8 bytecodes?

thanks,
Stephan


On 10/04/2015 11:22 PM, Mark Thomas wrote:

On 04/10/2015 17:56, Stephan Herrmann wrote:

Hence, my primary question: can we realistically expect a release of
BCEL 6.0 any time soon?


Define soon. Progress is being made. The more folks that contribute
(particularly patches and reviews of proposed patches) the faster that
progress will be. There is no set date I am aware of.

I'll note at this point there has been an awful lot of people demanding
more progress in BCEL and very few actually stepping up and contributing.


Secondly, what happens when future versions of Java introduce new
bytecodes? Currently it seems like Java 9 will only introduce one new
access flag and a new attribute, but of course future additions can
never be ruled out. Is there any commitment in the BCEL team to
support future bytecodes? I would be happy to help by way of bug
reports, possibly patches, but obviously some committer(s) would need
to drive this process. Is this something I could expect?


As long as BCEL is in Commons proper then that is a reasonable expectation.

Tomcat depends on BCEL so it is a safe bet that BCEL will be updated to
handle any parsing issues that emerge with new bytecodes. However,
Tomcat depends on fork of the source so it doesn't drive BCEL releases.


Lastly, already in version 5.2 we had to patch two files, because two
mutable static fields in BCEL prohibit the use in a multi threaded
application [3]. Note, that I'm not asking to make BCEL thread safe,
just to make client-side synchronization possible (without forcing
"stop-the-world-we-want-to-call-into-bcel"). As we have a modified
version of the two affected classes in use for several years, I wonder
if the proposed change could get some support?


Sounds reasonable to me. Open a Jira, provide the patch and someone
should take a look.


In all those years we were quite happy with BCEL. Unfortunately, we
have to make a hard decision pretty soon. From what I saw on this list,
I'm not sure, if staying with BCEL is viable.


Only you can make that choice.

Mark




Can anyone comment?
TIA,
Stephan
--
https://projects.eclipse.org/users/stephan-herrmann


[1] http://www.eclipse.org/objectteams
[2] http://www.eclipse.org/orbit
[3] https://issues.apache.org/jira/browse/BCEL-267

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[bcel] perspective?

[Stephan Herrmann]

Hi,

The Object Teams project[1] has been successfully using BCEL for around
13 years now. As Java 8 becomes widely used, we obviously can no longer
use BCEL 5.2. For a while it seemed as if BCEL was dead, but I was happy
to see more activity as of late. This now puts as on a crossroad between
two options:
(1) migrate to BCEL 6.0
(2) rewrite our 10 kLOC bytecode transformers using another library

I would like to avoid the immense effort involved with (2), but I'm not
quite sure if (1) is a viable and sustainable option.

First, as an Eclipse project we cannot ship a private version of BCEL.
We have to go through the Eclipse IP process in order to put BCEL into
"Orbit"[2]. This in general requires a release of the upstream project.
(BCEL 5.2 is in Orbit since 2007).

Hence, my primary question: can we realistically expect a release of
BCEL 6.0 any time soon?

Secondly, what happens when future versions of Java introduce new
bytecodes? Currently it seems like Java 9 will only introduce one new
access flag and a new attribute, but of course future additions can
never be ruled out. Is there any commitment in the BCEL team to
support future bytecodes? I would be happy to help by way of bug
reports, possibly patches, but obviously some committer(s) would need
to drive this process. Is this something I could expect?

Lastly, already in version 5.2 we had to patch two files, because two
mutable static fields in BCEL prohibit the use in a multi threaded
application [3]. Note, that I'm not asking to make BCEL thread safe,
just to make client-side synchronization possible (without forcing
"stop-the-world-we-want-to-call-into-bcel"). As we have a modified
version of the two affected classes in use for several years, I wonder
if the proposed change could get some support?

In all those years we were quite happy with BCEL. Unfortunately, we
have to make a hard decision pretty soon. From what I saw on this list,
I'm not sure, if staying with BCEL is viable.

Can anyone comment?
TIA,
Stephan
--
https://projects.eclipse.org/users/stephan-herrmann


[1] http://www.eclipse.org/objectteams
[2] http://www.eclipse.org/orbit
[3] https://issues.apache.org/jira/browse/BCEL-267

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org