Re: [abc-users] Problems weaving JDK classes

From: Pavel Avgustinov <>
Date: Wed, 7 May 2008 17:48:55 +0100

On Wednesday 07 May 2008 17:39:27 Alex Villazon wrote:

> This works almost without problem ( I had to remove from myjar java/
> util/Formatter*, java/util/ResourceBundle* and java/util/regex/
> Pattern* because of the following errors reported by abc
> The exception java.lang.Throwable must be either
> caught
> or declared to be thrown
> The exception java.lang.Throwable must be
> either
> caught or declared to be thrown
> The exception java.lang.Throwable must be either
> caught or
> declared to be thrown
> )

This is a known bug in Polyglot concerning exceptional control flow. As a
workaround, you can specify "-debug dontCheckExceptions", which will disable
all exception checking -- a bad idea, in principle, but probably OK for your

Alternatively, could I suggest you try using abc's JastAdd-based frontend by
specifying "-ext abc.ja"? This has in the past proven to be more reliable
than the polyglot frontend in such matters.

> After removing these files, abc was able to weave the aspect to
> myrt.jar
> Then, I added to my Dummy aspect the following declaration (that
> uses java.util classes which I'm weaving...)
> static private Set _refs = new HashSet();
> This time, abc failed to compile even the aspect itself...
> abc -verbose -injars myrt.jar -sourceroots simpleabc/ -outjar
> abcrt.jar
> abc started on Wed May 07 16:46:06 GMT+01:00 2008
> /home/villazon/simpleabc/
> The type of the variable initializer "java.util.HashSet" does not
> match
> that of the declaration "java.util.Set".
> static private Set _refs = new HashSet();
> ^-----------^
> 1 error.

Looks like for some reason Set is not considered a supertype of HashSet(). I'm
not sure why this could be, but it always worries me to have several jars on
the classpath containing the same classes, as in my experience that often
leads to odd interactions.

> My questions are question:
> - Is there some restriction on abc to compile JDK classes?

There is no "built-in" restriction or distinction between JDK and non-JDK
classes. Having said that, obviously abc itself uses JDK classes, which means
they'll be on the classpath somewhere. Still, if you specify an rt.jar in
the -inpath, there's no immediate reason why things should go wrong.

> - Could it be that the compiler has some conflicts because the classes
> java.util.Set and java.util.HashSet used to compile the aspect are not
> those from the original rt.jar but those that will be woven from
> myrt.jar ?

It sounds to me like you want the original rt.jar on the classpath and
myrt.jar on -inpath when you invoke abc; there shouldn't be any confusion

> Curiously, when I removed java.util.Set from myrt.jar, then the
> aspect was woven correctly. (nornally Set is an interface and should
> not be woven..)
> I also tried to tell polyglot to use the original rt.jar with
> +polyglot -bootclasspath $JAVA_HOME/jre/lib/rt.jar -polyglot but it
> does not work.

Again, I'd suggest trying it out with the new frontend; this has in the past
proven significantly easier for us to debug than the polyglot-based one.

Let us know how you get on,
- P
Received on Wed May 07 2008 - 17:49:01 BST

This archive was generated by hypermail 2.2.0 : Thu May 08 2008 - 11:50:11 BST