[Jastadd] Two new errors in the Java7Backend compiler

From: Na, Hyunik <hina_at_kaist.ac.kr>
Date: Sun, 27 Nov 2011 17:42:49 +0900

Hello Jesper,



> -----Original Message-----
> From: Na, Hyunik [mailto:hina_at_kaist.ac.kr]
> Sent: Friday, November 25, 2011 8:23 AM
> To: hina_at_kaist.ac.kr
> Subject: RE: [Jastadd] Testing JastAddJ
>
>
>
> From: jastadd-bounces_at_cs.lth.se [mailto:jastadd-bounces_at_cs.lth.se] On
> Behalf Of Jesper Oqvist
> Sent: Thursday, November 24, 2011 8:32 PM
> To: jastadd_at_cs.lth.se
> Subject: Re: [Jastadd] Testing JastAddJ
>
>
> Hello Hyunik,
> I could not see which version of JastAddJ this is. Could you please
> provide either the svn revision number or the name the release?
>
> Regarding the error messages I think the that first one might have been
> fixed in a later (possibly unreleased) version of JastAddJ. I have
> compiled JDK7 with JastAddJ, and I do not get this error message.
>
> I have seen the second error message. I solved that by removing all
> *.class files and compiling all *.java files at once using the _at_<file>
> option to provide the list of *.java files. I do not know if there is an
> error in the bytecode generation, or only the bytecode parsing of JastAddJ.
> I added a ticket for this error when I noticed it and continued without
> more investigation.
>


Though you suggested to use _at_<file> and I did it,
I also tried to compile the Java files in the “one-by-one fashion”, that is, as follows:

-=-=-=-=
for i in $(find . -name *.java)
do
  echo "### compiling $i"
  java -cp /home/hina/install/JastAddJ/Java7Backend JavaCompiler -bootclasspath .:./build:$OPENJDK_HOME/build/linux-i586/classes -extdirs . -classpath . -d build $i
  echo "### result = $?, compiling $i"
done
-=-=-=-=

with the JastAddJ Java7Backend compiler of revision 9178.

Then, I observed two new kinds of errors which were not found with the Java1.5Backend compiler.

-=-=-=-=

...
...

### compiling ./java/util/regex/ASCII.java
Errors:
./java/util/regex/ASCII.java:227,34:
  Syntactic Error: unexpected token "h"
### result = 1, compiling ./java/util/regex/ASCII.java

...
...

### compiling ./com/sun/crypto/provider/ai.java
Errors:
./com/sun/crypto/provider/ai.java:62:
  Semantic Error: can not instantiate Unknown no matching constructor found in Unknown
./com/sun/crypto/provider/ai.java:62,20:
  Semantic Error: no visible type named SealedObjectForKeyProtector
### result = 1, compiling ./com/sun/crypto/provider/ai.java

...
...

-=-=-=-=

The cause of the first one seems evident seeing the source code ASCII.java.
There seems to be a lexer (or parser) problem in handling "0x...E-..." form of expressions.
For example, you will have an error message (...unexpected token "h"...),
if you compile the following simple program with the Java7Backend compiler
(but, you won't with the Java1.5Backend compiler).

-=-=-=-=

public class Test {
  public static void main( String [] args ) {
    test(7);
  }

  static void test( int ch ) {
    System.out.println( 0x7E-ch ); // This line causes the problem.
  }
}

-=-=-=-=

But, the following is well compiled with the Java7Backend compiler.


-=-=-=-=

public class Test {
  public static void main( String [] args ) {
    test(7);
  }

  static void test( int ch ) {
    System.out.println( 0x7E -ch ); // Note the blank before '-'
  }
}

-=-=-=-=


And, I verified that the following error observed in Java1.5Backend compiler
still remains in Java7Backend compiler.

> The first type of error occurred only when I compiled
> $LOCAL/org/jcp/xml/dsig/internal/MacOutputStream.java
> The message says
>
> -=-=-=-=
>
> … (many warnings about deprecated features.)
> Errors:
> java/security/KeyStore.java:1668:
> Semantic Error: new Builder() {
> private volatile boolean getCalled;
> private IOException oldException;
> private final PrivilegedExceptionAction<KeyStore> action = new
> PrivilegedExceptionAction<KeyStore>() {
> public KeyStore run() throws Exception {
> KeyStore ks;
> if(provider == null) {
> ks = KeyStore.getInstance(type);
> }
> else {
> ks = KeyStore.getInstance(type, provider);
> }
> LoadStoreParameter param = new
> SimpleLoadStoreParameter(protection);
> if(protection instanceof CallbackHandlerProtection == false) {
> ks.load(param);
> }
> else {
> int tries = 0;
> while(true){
> tries++;
> try {
> ks.load(param);
> break ;
> }
> catch (IOException e) {
> if(e.getCause() instanceof UnrecoverableKeyException) {
> if(tries < MAX_CALLBACK_TRIES) {
> continue ;
> }
> else {
> oldException = e;
> }
> }
> throw e;
> }
> }
> }
> getCalled = true;
> return ks;
> }
> };
> public synchronized KeyStore getKeyStore() throws
> KeyStoreException {
> if(oldException != null) {
> throw new KeyStoreException("Previous KeyStore instantiation
> failed", oldException);
> }
> try {
> return AccessController.doPrivileged(action);
> }
> catch (PrivilegedActionException e) {
> Throwable cause = e.getCause();
> throw new KeyStoreException("KeyStore instantiation failed",
> cause);
> }
> }
> public ProtectionParameter getProtectionParameter(String alias) {
> if(alias == null) {
> throw new NullPointerException();
> }
> if(getCalled == false) {
> throw new IllegalStateException("getKeyStore() must be called
> first");
> }
> return protection;
> }
> } may throw uncaught exception java.io.IOException; it must be caught
> or declared as being thrown
> …
>

-- Hyunik
Received on Sun Nov 27 2011 - 09:42:38 CET

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