Java 5 to Java 1.4 'hello world'

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Java 5 to Java 1.4 'hello world'

Jesse Wilson

Hey Team ----

The work has been fairly slow going on our experimental side project,
a utility that can convert Java 5 source to Java 1.4 source. James & I
spent two evenings on it last week, and I had a crack at it this  
evening as
well. We've finally reached a milestone!

Given the following input program:

     import java.util.*;

     public class Generics15 {

         private static List<String> stringList = new  
ArrayList<String>();
         private static Map<String, Long> stringMap = new  
HashMap<String, Long>();

         public static void main(String[] args) {
             String s = stringList.get(0);
             Long l = stringMap.get(s);
         }
     }

... we can programatically generate the following output:

     import java.util.*;


     public class Generics15 {
         private static List stringList = new ArrayList();
         private static Map stringMap = new HashMap();

         public static void main(String[] args)  {
             String s = (String) (stringList.get(0));
             Long l = (Long) (stringMap.get(s));
         }
     }

Now I should be quite explicit and explain why this has been no easy  
feat,
just as our friend Hani has warned:

1 - We chose to use ANTLR instead of Javacc, since it provided a much  
more
complete Java 1.5 grammar. We definitely wanted to avoid writing a  
grammar!

2 - We couldn't find a decent free package that could even write a  
parsed Java 1.4 code out.
We had to grab something called JavaEmitter, which was quite  
incomplete, and complete
it. It took a whole evening just to get this to the point where it  
could read in the Glazed Lists 1.4
tree and then cough it back out in a parsable state.

3 - We need to keep a lot of state! For example, in the previous  
program, we
need to know that stringMap is a Map<String, Long>. We need to know  
that the
Map.get(String) method outputs a <V>, which we know is a Long in this  
instance.

4 - We need to infer types everywhere. For example, when we call  
stringList.get(0),
we need to infer that '0' is an int, so the proper overloaded method  
is used.
This is necessary to get the proper return type. For example,  
List.remove()
returns boolean in one overloaded version and Object in the other.

5 - The tree structure that we're using is kind of tricky. For  
example, instead of
methods like getChild(2), we need to use getFirstChild
().getNextSibling().getnextSibling().
We're considering the idea of creating our own node class to overcome  
this.

6 - We have to consider imports! For the previous class, we know to use
java.util.List rather than java.awt.List using the imports. This is  
necessary
to resolve method return types.

Anyways, we still have a lot of work to do now but since we have
a working version I think the future work will be a lot more pleasant!
We can work iteratively and start to write test cases etc.

And now, I begin propaganda:

Our approach throughout Glazed Lists has always been to avoid saying  
"no"
just because the best solution was difficult. This approach is what  
makes
Glazed Lists relevant & addictive to users:
  - It would have been easy to say 'dynamic sorting' can't be done  
due to
lack of data structure support, but instead we wrote our own data  
structures.
The result was that we have an incredibly fast sorting implementation.
  - Similarly for dynamic filtering, dynamic duplicate removal,  
multithreading,
fine-grained events, etc.

I'm convinced that we can finish the 5.0 to 1.4 converter, and I  
think that
our users will truly enjoy being able to have their pick of Java 5 or  
Java 1.4
without Retroweaver or unsupported compiler flags. The real problem
with these approaches is that they don't guarantee that our code will
work on a 1.4 JVM since they compile against the Java 5 libraries.

With all of that said, once I get this tool done I fear that it might
not be living up to its full potential. There would be sufficient
value to the Java developer community to start a 'SCEL' project:
Source Code Engineering Library, to compliment Jakarta's BCEL Bytecode
Engineering Library, etc. As a Java developer I think it would be  
great if
there was a general tool for transforming source code:
  - for an IDE plug in to export code to prior versions of Java
  - for an obfuscator
  - for arbitrary transformations within an Ant build script, such as  
replacing
log4j with java.util.logging or vice versa. This is especially  
convenient
when your project depends on open source projects that use different
logging frameworks
  - to force assert without "-ea" by replacing assert(condition) with  
if(!condition) throw Error

Look forward to the new Glazed Lists w/ generics and perhaps
a new tool to add to your toolchest!

Cheers,
Jesse


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Java 5 to Java 1.4 'hello world'

adepue
Wow!  This is great news!  Well, to me, anyway. ;)  I look forward to seeing
where this goes in the future.

  - Andy

PS  I'd join you guys if I weren't a father of two.  My evenings are now
indefinitely reserved.  :)

On Tuesday 02 August 2005 11:02 pm, Jesse Wilson wrote:

> Hey Team ----
>
> The work has been fairly slow going on our experimental side project,
> a utility that can convert Java 5 source to Java 1.4 source. James & I
> spent two evenings on it last week, and I had a crack at it this
> evening as
> well. We've finally reached a milestone!
>
> Given the following input program:
>
>      import java.util.*;
>
>      public class Generics15 {
>
>          private static List<String> stringList = new
> ArrayList<String>();
>          private static Map<String, Long> stringMap = new
> HashMap<String, Long>();
>
>          public static void main(String[] args) {
>              String s = stringList.get(0);
>              Long l = stringMap.get(s);
>          }
>      }
>
> ... we can programatically generate the following output:
>
>      import java.util.*;
>
>
>      public class Generics15 {
>          private static List stringList = new ArrayList();
>          private static Map stringMap = new HashMap();
>
>          public static void main(String[] args)  {
>              String s = (String) (stringList.get(0));
>              Long l = (Long) (stringMap.get(s));
>          }
>      }
>
> Now I should be quite explicit and explain why this has been no easy
> feat,
> just as our friend Hani has warned:
>
> 1 - We chose to use ANTLR instead of Javacc, since it provided a much
> more
> complete Java 1.5 grammar. We definitely wanted to avoid writing a
> grammar!
>
> 2 - We couldn't find a decent free package that could even write a
> parsed Java 1.4 code out.
> We had to grab something called JavaEmitter, which was quite
> incomplete, and complete
> it. It took a whole evening just to get this to the point where it
> could read in the Glazed Lists 1.4
> tree and then cough it back out in a parsable state.
>
> 3 - We need to keep a lot of state! For example, in the previous
> program, we
> need to know that stringMap is a Map<String, Long>. We need to know
> that the
> Map.get(String) method outputs a <V>, which we know is a Long in this
> instance.
>
> 4 - We need to infer types everywhere. For example, when we call
> stringList.get(0),
> we need to infer that '0' is an int, so the proper overloaded method
> is used.
> This is necessary to get the proper return type. For example,
> List.remove()
> returns boolean in one overloaded version and Object in the other.
>
> 5 - The tree structure that we're using is kind of tricky. For
> example, instead of
> methods like getChild(2), we need to use getFirstChild
> ().getNextSibling().getnextSibling().
> We're considering the idea of creating our own node class to overcome
> this.
>
> 6 - We have to consider imports! For the previous class, we know to use
> java.util.List rather than java.awt.List using the imports. This is
> necessary
> to resolve method return types.
>
> Anyways, we still have a lot of work to do now but since we have
> a working version I think the future work will be a lot more pleasant!
> We can work iteratively and start to write test cases etc.
>
> And now, I begin propaganda:
>
> Our approach throughout Glazed Lists has always been to avoid saying
> "no"
> just because the best solution was difficult. This approach is what
> makes
> Glazed Lists relevant & addictive to users:
>   - It would have been easy to say 'dynamic sorting' can't be done
> due to
> lack of data structure support, but instead we wrote our own data
> structures.
> The result was that we have an incredibly fast sorting implementation.
>   - Similarly for dynamic filtering, dynamic duplicate removal,
> multithreading,
> fine-grained events, etc.
>
> I'm convinced that we can finish the 5.0 to 1.4 converter, and I
> think that
> our users will truly enjoy being able to have their pick of Java 5 or
> Java 1.4
> without Retroweaver or unsupported compiler flags. The real problem
> with these approaches is that they don't guarantee that our code will
> work on a 1.4 JVM since they compile against the Java 5 libraries.
>
> With all of that said, once I get this tool done I fear that it might
> not be living up to its full potential. There would be sufficient
> value to the Java developer community to start a 'SCEL' project:
> Source Code Engineering Library, to compliment Jakarta's BCEL Bytecode
> Engineering Library, etc. As a Java developer I think it would be
> great if
> there was a general tool for transforming source code:
>   - for an IDE plug in to export code to prior versions of Java
>   - for an obfuscator
>   - for arbitrary transformations within an Ant build script, such as
> replacing
> log4j with java.util.logging or vice versa. This is especially
> convenient
> when your project depends on open source projects that use different
> logging frameworks
>   - to force assert without "-ea" by replacing assert(condition) with
> if(!condition) throw Error
>
> Look forward to the new Glazed Lists w/ generics and perhaps
> a new tool to add to your toolchest!
>
> Cheers,
> Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]