Re: ImportScrubberTask

[Geir Magnusson Jr.]

On 10/22/01 1:23 PM, Pier Fumagalli [EMAIL PROTECTED] wrote:

 Jon Stevens at [EMAIL PROTECTED] wrote:
 
 import email.RequireApproval.vm;
 
 Wow. When did Velocity files become ok to import? :-)
 
 You didn't know? They're adding those to the VM spec, so that you can
 directly write in Velocity without having the hassle to pass thru Java :) :)
 
   Pier (being ready to be flamed by JG! :)
 

From what I understand, Sun likes it so much its going to be part of system
services in the next major rev of Solaris.  Sort of like how Microsoft
'integrated' IE into their OS.

geir

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety. - Benjamin Franklin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Markus Dahm]

On Monday 22 October 2001 22:21, you wrote:
Hi,

 When writing JNI code which references Java classes, one has to use
 special markup on the fully qualified class names.
 I.e. Lorg/apache/turbine/Turbine; would be the string literal
 corresponding to the class org.apache.turbine.Turbine, and something
 like (Ljava/lang/String;Ljava/lang/String;)V to denote a method
 which takes two String parameters.  Looking at some bytecode using
 `strings`, I notice that this seems to apply to at least part of a
 method signature.  Not a lot of help here, but maybe something to
 think about.  shrug/

ok, here's my two cents (or was it dimes?): There are two ways how classes 
can be referenced in class files: either through a direct reference to a 
ConstantClass object in the constant pool, or through the signature of a 
method/field. The former case is easy to detect, because you just have to 
scan the constant pool. The latter is a little more difficult to detect, but 
I think you can do it by scanning the byte code and just take only those 
constant pool entries (i.e. strings) into account that are referenced by a, 
say, GETFIELD instruction. I think I even introduced an interface into BCEL 
to denote such instructions named LoadClass.
It takes a little more time than the heuristic method, but is still O(n) ;-)

Cheers
Markus
-- 
Email:  [EMAIL PROTECTED]   Phone: +49 30 838 75141
WWW:http://www.berlin.de/~markus.dahm/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Tom_Copeland]

Hi Markus -

 Thanks much - I'm going to give that a whirl and see if it improves
Importscrubber's accuracy - it certainly should

 Thanks,

Tom Copeland
[EMAIL PROTECTED]
703-317-5193


   
   
Markus Dahm
   
markus.dahm@To: [EMAIL PROTECTED]
   
berlin.de   cc:   
   
 Subject: Re: ImportScrubberTask   
   
10/23/2001 
   
05:43 AM   
   
Please 
   
respond to 
   
general
   
   
   
   
   




On Monday 22 October 2001 22:21, you wrote:
Hi,

 When writing JNI code which references Java classes, one has to use
 special markup on the fully qualified class names.
 I.e. Lorg/apache/turbine/Turbine; would be the string literal
 corresponding to the class org.apache.turbine.Turbine, and something
 like (Ljava/lang/String;Ljava/lang/String;)V to denote a method
 which takes two String parameters.  Looking at some bytecode using
 `strings`, I notice that this seems to apply to at least part of a
 method signature.  Not a lot of help here, but maybe something to
 think about.  shrug/

ok, here's my two cents (or was it dimes?): There are two ways how classes
can be referenced in class files: either through a direct reference to a
ConstantClass object in the constant pool, or through the signature of a
method/field. The former case is easy to detect, because you just have to
scan the constant pool. The latter is a little more difficult to detect,
but
I think you can do it by scanning the byte code and just take only those
constant pool entries (i.e. strings) into account that are referenced by a,

say, GETFIELD instruction. I think I even introduced an interface into BCEL

to denote such instructions named LoadClass.
It takes a little more time than the heuristic method, but is still O(n) ;
-)

Cheers
   Markus
--
Email:  [EMAIL PROTECTED]Phone: +49 30 838
75141
WWW:http://www.berlin.de/~markus.dahm/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




 -- 


This email may contain confidential and proprietary information which is
for the sole use of the intended recipient.  If you received this email in
error, please notify the sender and delete this email from your computer.
Any review, distribution or retransmission of or reliance on this email by
anyone other than the intended recipient is forbidden.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Jason van Zyl]

On 10/21/01 11:52 PM, Jon Stevens [EMAIL PROTECTED] wrote:

 on 10/21/01 8:40 PM, Pier Fumagalli [EMAIL PROTECTED] wrote:
 
 Jon Stevens at [EMAIL PROTECTED] wrote:
 
 http://importscrubber.sourceforge.net/ant.html
 
 org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrubberTask
 
 Given that this isn't an official Jakarta project, shouldn't the tool choose
 another namespace?
 
 Indeed...
 
   Pier
 
 
 That said, I just tried running importscrubber against Scarab's code and it
 totally f*cked it up. I highly recommend not using it or at least being very
 careful with it.
 

It works fine, but there is a problem with the imports being placed in the
wrong place when there is text right after the package declaration. I asked
Tom Copeland to fix this for me and he said he would get to it today. It
does the job correctly, it just doesn't put the imports in the right place.

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Tom_Copeland]

Hello Jon -

 That's too bad that importscrubber messed up the Scarab source code.
Importscrubber is still definitely a work in progress, and there are some
things that it is definitely going to miss.  For example, since the
compiler inlines references to static finals, and importscrubber looks in
the class file for class references it's going to miss those
references.  Which is unfortunate.  Also, if a string looks a lot like a
class name, Importscrubber may think its a class name and try to turn it
into an import statement.

 At any rate, I'll take a look at how importscrubber mangles the Scarab
code and see if there's anything I can fix.  Thanks for the feedback,

 Yours,

Tom Copeland
[EMAIL PROTECTED]
703-317-5193


   
   
Jon Stevens
   
jon@latchkeyTo: [EMAIL PROTECTED] 
[EMAIL PROTECTED]
.comcc: [EMAIL PROTECTED]   
   
 Subject: Re: ImportScrubberTask   
   
10/21/2001 
   
11:52 PM   
   
   
   
   
   




on 10/21/01 8:40 PM, Pier Fumagalli [EMAIL PROTECTED] wrote:

 Jon Stevens at [EMAIL PROTECTED] wrote:

 http://importscrubber.sourceforge.net/ant.html

 org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrubberTask

 Given that this isn't an official Jakarta project, shouldn't the tool
choose
 another namespace?

 Indeed...

   Pier


That said, I just tried running importscrubber against Scarab's code and it
totally f*cked it up. I highly recommend not using it or at least being
very
careful with it.

Tom, feel free to try yourself...I added the following to Scarab's
build.xml:

!-- ==
--
!-- Tool to create proper import statements
--
!-- ==
--
target name=scrub depends=om-peer,prepare
taskdef name=scrub

classname
=org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrub
berTask/

property name=tmp.dir value=tmp/

delete dir=${tmp.dir} quiet=true/

copy todir=${tmp.dir}/org
  fileset dir=${build.src.scarab}/org/
/copy

javac srcdir=${tmp.dir}
destdir=${tmp.dir}
excludes=**/package.html,torque/**
debug=true

  classpath refid=classpath/

  classpath
fileset dir=${build.project.webinf.lib}
  include name=**/torque*.jar/
/fileset
  /classpath
/javac

scrub root=${tmp.dir} format=nobreaks recurse=true/

delete
  fileset dir=${tmp.dir} includes=**/*.class/
/delete

copy todir=${src.java.dir.scarab}/org overwrite=true
  fileset dir=${tmp.dir}/org/
/copy

/target

-jon




 -- 


This email may contain confidential and proprietary information which is
for the sole use of the intended recipient.  If you received this email in
error, please notify the sender and delete this email from your computer.
Any review, distribution or retransmission of or reliance on this email by
anyone other than the intended recipient is forbidden.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Jon Stevens]

on 10/22/01 6:22 AM, Jason van Zyl [EMAIL PROTECTED] wrote:

 It works fine, but there is a problem with the imports being placed in the
 wrong place when there is text right after the package declaration. I asked
 Tom Copeland to fix this for me and he said he would get to it today. It
 does the job correctly, it just doesn't put the imports in the right place.

Run the ant target that I pasted here against Scarab and you will see that
it does NOT work fine at all. I pasted it here so that I wouldn't get a
response like you just gave me.

Here is an example of some imports it f*cked up:

[196][ src/org/tigris/scarab/om ]% more Attachment.java
package org.tigris.scarab.om;

import text.plain;
import org.apache.fulcrum.upload.FileItem;
import org.apache.torque.om.NumberKey;
import org.apache.torque.om.Persistent;

I never knew that text.plain is a proper import. :-)

Here is another one:

[197][ src/org/tigris/scarab/om ]% more IssueTemplateInfo.java
package org.tigris.scarab.om;

import email.RequireApproval.vm;
import org.apache.turbine.Turbine;
import org.apache.fulcrum.template.TemplateContext;
import org.apache.torque.om.NumberKey;
import org.apache.torque.om.UnsecurePersistent;
import org.tigris.scarab.security.ScarabSecurity;
import org.tigris.scarab.security.SecurityFactory;
import org.tigris.scarab.tools.Email;
import org.tigris.scarab.util.ScarabException;
import org.tigris.scarab.services.module.ModuleEntity;

Wow. When did Velocity files become ok to import? :-)

It appears that in its search through files, it finds any mention of a
foo.bar and sticks it into an import. That does not seem like a very good
assumption.

Another problem I noticed is that it imports java.util.Set when it doesn't
need to as well.

Yes, I compiled with debugging on.

I'm starting to think that post processing JAD (the java decompiler) output
would be a better idea.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Pier Fumagalli]

Jon Stevens at [EMAIL PROTECTED] wrote:

 import email.RequireApproval.vm;
 
 Wow. When did Velocity files become ok to import? :-)

You didn't know? They're adding those to the VM spec, so that you can
directly write in Velocity without having the hassle to pass thru Java :) :)

Pier (being ready to be flamed by JG! :)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Jason van Zyl]

On 10/22/01 1:04 PM, Jon Stevens [EMAIL PROTECTED] wrote:

 on 10/22/01 6:22 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
 
 It works fine, but there is a problem with the imports being placed in the
 wrong place when there is text right after the package declaration. I asked
 Tom Copeland to fix this for me and he said he would get to it today. It
 does the job correctly, it just doesn't put the imports in the right place.
 
 Run the ant target that I pasted here against Scarab and you will see that
 it does NOT work fine at all. I pasted it here so that I wouldn't get a
 response like you just gave me.

I only ran it on a small body of source, but Scarab is a good test bed.
 
 Here is an example of some imports it f*cked up:
 
 [196][ src/org/tigris/scarab/om ]% more Attachment.java
 package org.tigris.scarab.om;
 
 import text.plain;
 import org.apache.fulcrum.upload.FileItem;
 import org.apache.torque.om.NumberKey;
 import org.apache.torque.om.Persistent;
 
 I never knew that text.plain is a proper import. :-)
 
 Here is another one:
 
 [197][ src/org/tigris/scarab/om ]% more IssueTemplateInfo.java
 package org.tigris.scarab.om;
 
 import email.RequireApproval.vm;
 import org.apache.turbine.Turbine;
 import org.apache.fulcrum.template.TemplateContext;
 import org.apache.torque.om.NumberKey;
 import org.apache.torque.om.UnsecurePersistent;
 import org.tigris.scarab.security.ScarabSecurity;
 import org.tigris.scarab.security.SecurityFactory;
 import org.tigris.scarab.tools.Email;
 import org.tigris.scarab.util.ScarabException;
 import org.tigris.scarab.services.module.ModuleEntity;
 
 Wow. When did Velocity files become ok to import? :-)

But it did a pretty good job, I think after a couple rounds of fixes it will
be fine.
 
 It appears that in its search through files, it finds any mention of a
 foo.bar and sticks it into an import. That does not seem like a very good
 assumption.

Poking around in the constants pool isn't necessarily straight forward even
though BCEL makes it much easier.
 
 Another problem I noticed is that it imports java.util.Set when it doesn't
 need to as well.

I think that's a superclass problem. Same thing I ran into with the little
hack I whipped up.
 
 Yes, I compiled with debugging on.
 
 I'm starting to think that post processing JAD (the java decompiler) output
 would be a better idea.

I think in a couple of days it will do the trick just fine. I ran it on the
Tambora source and it wasn't that bad. It doesn't work yet but it's pretty
close.
 
 -jon
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Jon Stevens]

on 10/22/01 10:56 AM, Jason van Zyl [EMAIL PROTECTED] wrote:

 I only ran it on a small body of source, but Scarab is a good test bed.

Scarab is something like 256 classes...most of it is Torque generated
though...

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Glenn Nielsen]

Jon Stevens wrote:

 on 10/22/01 10:23 AM, Pier Fumagalli [EMAIL PROTECTED] wrote:
 
 
You didn't know? They're adding those to the VM spec, so that you can
directly write in Velocity without having the hassle to pass thru Java :) :)

  Pier (being ready to be flamed by JG! :)

 
 Na...we would have to rename Velocity - JSP.
 
 :-)
 
 I wonder how many people have tried importing a compiled JSP page. Oh wait,
 you can't easily do that because Jasper makes up some f*cked up name for the
 class because no one could figure out how to implement reloading properly.
 :-)
 
 -jon
 
 


You might want to qualilfy the above statemenet.  Jasper in Tomcat 4
uses a sane scheme for package and class naming that supports reloading
of JSP pages.  And it performs 25-33% faster due to just that change.
(Taking this even further off topic) ;-)


--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Tom_Copeland]

Hi Dan -

 Thanks very much.  Yup, a lot of the constant strings that BCEL emits
look just like the JNI method signature components.  In a previous life I
wrote a LOT of Win32 JNI and got very familiar with all that gibberish.
Now I'm a happy pure-Java programmer :-)

 Thanks,

Tom Copeland
[EMAIL PROTECTED]
703-317-5193


   
 
Daniel Rall
 
dlr@finemaltcodingTo: [EMAIL PROTECTED]  
 
.com  cc: 
 
Sent by:   Subject: Re: ImportScrubberTask 
 
[EMAIL PROTECTED]
 
coding.com 
 
   
 
   
 
10/22/2001 04:21 PM
 
Please respond to  
 
general
 
   
 
   
 




[EMAIL PROTECTED] writes:

  That's too bad that importscrubber messed up the Scarab source code.
 Importscrubber is still definitely a work in progress, and there are some
 things that it is definitely going to miss.  For example, since the
 compiler inlines references to static finals, and importscrubber looks in
 the class file for class references it's going to miss those
 references.  Which is unfortunate.  Also, if a string looks a lot like a
 class name, Importscrubber may think its a class name and try to turn it
 into an import statement.

When writing JNI code which references Java classes, one has to use
special markup on the fully qualified class names.
I.e. Lorg/apache/turbine/Turbine; would be the string literal
corresponding to the class org.apache.turbine.Turbine, and something
like (Ljava/lang/String;Ljava/lang/String;)V to denote a method
which takes two String parameters.  Looking at some bytecode using
`strings`, I notice that this seems to apply to at least part of a
method signature.  Not a lot of help here, but maybe something to
think about.  shrug/

 Dan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




 -- 


This email may contain confidential and proprietary information which is
for the sole use of the intended recipient.  If you received this email in
error, please notify the sender and delete this email from your computer.
Any review, distribution or retransmission of or reliance on this email by
anyone other than the intended recipient is forbidden.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Daniel Rall]

[EMAIL PROTECTED] writes:

  That's too bad that importscrubber messed up the Scarab source code.
 Importscrubber is still definitely a work in progress, and there are some
 things that it is definitely going to miss.  For example, since the
 compiler inlines references to static finals, and importscrubber looks in
 the class file for class references it's going to miss those
 references.  Which is unfortunate.  Also, if a string looks a lot like a
 class name, Importscrubber may think its a class name and try to turn it
 into an import statement.

When writing JNI code which references Java classes, one has to use
special markup on the fully qualified class names.
I.e. Lorg/apache/turbine/Turbine; would be the string literal
corresponding to the class org.apache.turbine.Turbine, and something
like (Ljava/lang/String;Ljava/lang/String;)V to denote a method
which takes two String parameters.  Looking at some bytecode using
`strings`, I notice that this seems to apply to at least part of a
method signature.  Not a lot of help here, but maybe something to
think about.  shrug/

 Dan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Pier Fumagalli]

Jon Stevens at [EMAIL PROTECTED] wrote:

 http://importscrubber.sourceforge.net/ant.html
 
 org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrubberTask
 
 Given that this isn't an official Jakarta project, shouldn't the tool choose
 another namespace?

Indeed...

Pier


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Jon Stevens]

on 10/21/01 8:40 PM, Pier Fumagalli [EMAIL PROTECTED] wrote:

 Jon Stevens at [EMAIL PROTECTED] wrote:
 
 http://importscrubber.sourceforge.net/ant.html
 
 org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrubberTask
 
 Given that this isn't an official Jakarta project, shouldn't the tool choose
 another namespace?
 
 Indeed...
 
   Pier
 

That said, I just tried running importscrubber against Scarab's code and it
totally f*cked it up. I highly recommend not using it or at least being very
careful with it.

Tom, feel free to try yourself...I added the following to Scarab's
build.xml:

!-- ==
--
!-- Tool to create proper import statements
--
!-- ==
--
target name=scrub depends=om-peer,prepare
taskdef name=scrub
  
classname=org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrub
berTask/

property name=tmp.dir value=tmp/

delete dir=${tmp.dir} quiet=true/

copy todir=${tmp.dir}/org
  fileset dir=${build.src.scarab}/org/
/copy

javac srcdir=${tmp.dir}
destdir=${tmp.dir}
excludes=**/package.html,torque/**
debug=true

  classpath refid=classpath/

  classpath
fileset dir=${build.project.webinf.lib}
  include name=**/torque*.jar/
/fileset
  /classpath
/javac

scrub root=${tmp.dir} format=nobreaks recurse=true/

delete
  fileset dir=${tmp.dir} includes=**/*.class/
/delete

copy todir=${src.java.dir.scarab}/org overwrite=true
  fileset dir=${tmp.dir}/org/
/copy

/target

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Peter Donald]

On Mon, 22 Oct 2001 13:20, Jon Stevens wrote:
 http://importscrubber.sourceforge.net/ant.html

 org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrubberTask

 Given that this isn't an official Jakarta project, shouldn't the tool
 choose another namespace?

probably - but that project is not alone. Heaps of external projects use this 
namespace. About the only ones who put it in their own namespace (ie 
org.apache.torque.tasks.*) are at Apache or the occasional other one.

I vaguely remember someone complaining about it a while back but nothing 
really got done. 

-- 
Cheers,

Pete

abandon all hope , ye who enter here - dante, inferno


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]