Bug 227067

Summary: Review Request: javassist - Java Programming Assistant: bytecode manipulation
Product: [Fedora] Fedora Reporter: Rafael H. Schloming <rafaels>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: akurtako, keiths, tromey, tross, viveklak
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-18 21:14:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Rafael H. Schloming 2007-02-02 17:40:03 UTC
Spec URL: http://people.redhat.com/rafaels/specs/javassist-3.1-1jpp.spec
SRPM URL: ftp://jpackage.hmdc.harvard.edu/JPackage/1.7/generic/SRPMS.free/javassist-3.1-1jpp.src.rpm
Description: Javassist (Java Programming Assistant) makes Java
bytecode manipulation simple. It is a class library
for editing bytecodes in Java; it enables Java
programs to define a new class at runtime and to
modify a class file when the JVM loads it. Unlike
other similar bytecode editors, Javassist provides
two levels of API: source level and bytecode level.
If the users use the source-level API, they can edit
a class file without knowledge of the specifications
of the Java bytecode. The whole API is designed with
only the vocabulary of the Java language. You can even
specify inserted bytecode in the form of source text;
Javassist compiles it on the fly. On the other hand,
the bytecode-level API allows the users to directly
edit a class file as other editors.

Samples for javassist.

Javadoc for javassist.

Tutorial for javassist.

Comment 1 Kyu Lee 2007-02-12 17:14:47 UTC
Review Comments

* incorrect buildroot
 - should be:
   %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

* changelog should be in one of these formats: (without epoch)

  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> - 0.6-4
  - And fix the link syntax.

  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> 0.6-4
  - And fix the link syntax.

  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com>
  - 0.6-4
  - And fix the link syntax.

* Summary tag should not end in a period

* use macros appropriately and consistently
 - ie. %{buildroot} and %{optflags} vs. $RPM_BUILD_ROOT and $RPM_OPT_FLAGS

Comment 2 Kyu Lee 2007-02-12 17:15:59 UTC
Package won't build, here's first error.

 [javac] 55. ERROR in /notnfs/klee/RPMBUILDS/BUILD/javassist-3.1/src/main/jav
    [javac]  (at line 18)
    [javac]     import com.sun.jdi.*;
    [javac]            ^^^^^^^^^^^
    [javac] The import com.sun.jdi cannot be resolved

Comment 3 Kyu Lee 2007-02-12 17:28:48 UTC
After running rpmlint :

W: javassist non-standard-group Development/Libraries/Java
E: javassist unknown-key GPG#c431416d

Comment 4 Andrew Overholt 2007-02-12 21:49:38 UTC
So other than the comments you made, was the rest of the package okay?  Please
add the other comments in the future (ie. even the ones that aren't problems). 

Comment 5 Kyu Lee 2007-02-12 22:18:18 UTC
After double chekcing, 

* it should not have Vendor Tag.

And rest of them is okay.

Comment 6 Andrew Overholt 2007-02-12 22:43:37 UTC
Updated spec and SRPM:


Other things fixed:

Renamed specfile to javassist.spec
Remove %define section devel
Added .1%{?dist}

It still doesn't build due to the com.sun.jdi dependencies.  I don't see this
getting fixed until we import Keith's JDWP work.  CCing Keith Seitz and Tom
Tromey to get their opinion as to whether or not we'll have
com.sun.jdi.VirtualMachine any time soon.

Comment 7 Tom Tromey 2007-02-14 21:30:20 UTC
Nope, our JDWP implementation does not include com.sun.jdi.
In fact, I had never heard of that until just now :)

Comment 8 Andrew Overholt 2007-02-15 15:56:21 UTC
Keith:  have you heard of com.sun.jdi?

Comment 9 Keith Seitz 2007-02-15 19:18:00 UTC
Yeah, JDI is yet another of the API layers on top of JVMTI that one can use to
do all sorts of things to a VM. JDWP won't help because we don't use that layer.
We could, for sure, but just look at how JVMTI mucked with the schedule. More
info here: http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdi/index.html

Comment 10 Vivek Lakshmanan 2007-08-14 00:23:50 UTC
new version requested for review: bug 252099

Comment 11 Vivek Lakshmanan 2007-08-14 00:24:37 UTC
*** Bug 252099 has been marked as a duplicate of this bug. ***

Comment 13 Alexander Kurtakov 2010-11-04 12:20:41 UTC
Resetting assigned status to new because it wasn't really assigned to anyone.

Comment 14 Jason Tibbitts 2010-11-18 16:40:45 UTC
Can we get a package that's somewhat close to the current guidelines?  Is anyone associated with this ticket still around to drive it?

Comment 15 Jason Tibbitts 2010-11-18 21:14:33 UTC
Never mind, this must have been reviewed and approved in a different ticket.

*** This bug has been marked as a duplicate of bug 475508 ***