Re: [Jastadd] [bug report] absence of AbstractWildcardType.createQualifiedAccess()

From: Na, Hyunik <>
Date: Thu, 26 Apr 2012 11:02:58 +0900

Hello Jesper,


If you only want to reproduce the “_at_primitive/Unknown” string in the
signature in a class file,

then I’d like to suggest you to compile with JastAddJ

and look into the generated HashMap.class with “javap –verbose” or

For your convenience, I attach the file which I took from


Precisely speaking, I’m not compiling OpenJDK1.6 with JastAddJ.

I took .java files from two directories of OpenJDK 1.6 which seem to
comprise “java class library”

and compiled them with JastAddJ one by one.

My purpose is to get JastAddJ-generated “java class library” and later
JastAddThisJava-generated one.

( JastAddThisJava is the name of the compiler which I’m working on. I’ve
finished Frontend work and started Backend this week. )

But, I’m not completely sure about what is the “java class library”. Exactly
what classes should it be made up of?

I should be more precise on this later.


Anyway, the following is how I compile .java files from OpenJDK 1.6.


1. Download and build OpenJDK1.6

           - I used openjdk-6-src-b23-05_jul_2011.tar.gz.

2. Collect .java files from the following two directories while retaining
directory structures.

           - $OpenJDK16/build/linux-i586/gensrc

           - $OpenJDK16/jdk/src/share/classes

3. Run the following bash script in the directory where the collected com/,
java/, javax/, org/, sun/, and sunw/ directories are located.



rm -rf ./build/*

for i in $(find . -name *.java)


  echo "### compiling $i"

  java -cp $HOME/install/JastAddJ/Java1.5Backend JavaCompiler -verbose
-bootclasspath .:./build:$Openjdk16/build/linux-i586/classes -extdirs .
-classpath . -d build $i

  echo "### result = $?, compiled $i"




That’s it!


Besides my purpose, I found that this is a good way to find hidden bugs of
JastAddJ with many, many java sources.

Currently, over 20 different error messages appear as the result of doing
this compilation.

Some of them seem to be related to subtyping, definite assignment checks,

I will check them all for my purpose and to make a small contribution to
this excellent tool JastAdd(J) which I owe much.

(My current work would be impossible or harder without JastAddJ).


Thank you.


- Hyunik




From: [] On Behalf
Of Jesper Oqvist
Sent: Wednesday, April 25, 2012 9:04 PM
Subject: Re: [Jastadd] [bug report] absence of


Hello again,

Could you please provide more information about how you are compiling
OpenJDK 1.6?


On 04/25/2012 07:23 AM, Na, Hyunik wrote:

Hello JastAddJ developers,


Compiling java/util/ in OpenJDK 1.6 with JastAddJ (rev. 9238)
produces the following entry in the constant pool.


           const #358 = Asciz


And the illegal string “_at_primitive/Unknown” in the HashMap.class make it
impossible to compile other 1138 java files in the library

which load HashMap.class during their compilation.


_at_primitive/Unknown appears also for three other java files:

           . sun/management/,

           . sun/swing/,

           . sun/util/

, and it also prohibits compilation of 725 other java files which loads
three corresponding .class files during their compilation.


I spent some time to find the cause of this problem, and got the impression
that absence of AbstractWildcardType.createQualifiedAccess() is probably the

That is, AbstractWildcardType should override TypeDecl’s


Because it does not in current JastAddJ, invocation of
createQualifiedAccess() on a WildcardExtendsType object (for example) is
dispatched to TypeDecl’s createQualifiedAccess(),

and produces a TypeAccess object whose package is “wildcards”, and id is “?
extends …”.

And, querying type() on this TypeAccess object seems to produce Unknown


So, I added the following line into Java1.5Frontend


           public Access AbstractWildcardType.createQualifiedAccess() {
return createBoundAccess(); }


and it seems that the _at_primitive/Unknown disappears from the class files
with this addition.


This problem of “_at_primitive/Unknown” in the signatures happens very rarely
(in only four out of 7638 java files in the OpenJDK 1.6 libaray).

It seems to happen during some “transformation” which I don’t understand.

( In case of HashMap, it happens in a synthesized method whose parameter
type is Map<? extends K, ? extends V> where K and V is the type variables of
HashMap. )


Is that addition appropriate? Does it cause any other problems in the


- Hyunik

JastAdd mailing list

Received on Thu Apr 26 2012 - 04:03:08 CEST

This archive was generated by hypermail 2.3.0 : Wed Apr 16 2014 - 17:19:06 CEST