Created
March 28, 2011 02:30
-
-
Save bbatha/889902 to your computer and use it in GitHub Desktop.
Java on Parrot GSOC11 Proposal
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ben Batha | |
Email: bbatha@u.rochester.edu | |
Google ID: applied under: elektronjunge | |
prefered contact: bhbatha | |
Other contact info: bbatha on irc.parrot.org #parrot | |
Your Project's Title: Java on Parrot | |
Abstract | |
The project is based on providing a compiler for Java mostly or entirely written in Java. Previously written | |
compiler projects (OpenJDK javac or GCJ) will likely be used as a starting point for development. Reusing | |
code is a priority for completion of the project, so focus will be on replacing the code generation of a | |
compiler to generate to parrot friendly targets (PIR) by replacing the AST generation with PAST. The | |
result will be integrated with existing Java standard libraries (either OpenJDK, or GNU classpath). | |
Benefits to the Parrot VM and Open Source Community | |
This project would be a boon to both the Parrot and larger open source community. Java is one of the most | |
popular languages currently being used unfortunately it is largely locked the JVM which means that other | |
languages have to target the JVM to properly interact with Java. Bringing Java to Parrot would mean a lot of | |
preexisting code can run on Parrot. Additionally, Parrot can be language neutral way to interact popular | |
scripting languages already supported by Parrot with Java with minimal work by developers. Moreover, Parrot | |
is a more flexible virtual machine allowing for dynamic typing, etc. which would further facilitate | |
interaction between Java and other languages. The result of this project should be a foundation for for | |
future development of this important language. | |
Deliverables | |
This project should result in a compiler from Java to Parrot VM with support for at least basic Java syntax. | |
A portable test suite and build infrastructure for major platforms. Complete documentation with a particular | |
focus on how to extend the project so future improvements can be made. Documentation will be generated using | |
javadoc and distributed as html pages. | |
Project Details | |
The project will be broken into several stages. | |
1. A bootstrapped compiler (stage 1) using javac or a similar compiler based on an earlier Java compiler with | |
the internals replaced for code generation to PIR. This will likely be based on GCJ or javac (finalized after | |
research period). The implementation of Java is likely to remain rather simplistic avoiding newer more | |
complicated features that have come in more recent Java compilers e.g. generics. This implementation of Java | |
will rely on previously written Java standard libraries (GNU classpath or OpenJDK). | |
2. A stage 1 compiler that creates PAST objects. This compiler will be able to use built in Parrot optimization | |
routines. | |
3. A testing framework that tests all aspects of the completed code. The java code will use a the JUnit | |
testing framework, and the PIR code will be tested using Rosella. | |
4. A build system for major platforms. | |
<Problem Resolution> | |
1. Plan ahead to foresee potential problems | |
2. Interface with Parrot and Java compiler communities for assistance | |
3. Try different implementation of problematic code sections | |
4. Revert to backup plan | |
<Backup plan> | |
Time will be spent developing a plan for each portion of the code so a backup plan is unnecessary. In the | |
event of this necessity, there are multiple Java compiler projects that may function better than the chosen | |
compiler base. Additionally, if integrating PAST into an existing compiler becomes impossible it may be | |
easier to just rewrite the code generation from the Java compiler. Finally, if all else fails using parser | |
generators or programming the compiler from hand is an option. | |
Project Schedule | |
March 27 - April 8: | |
Finish proposal study code bases of Java compilers to get familiar with the scope of this project. Discuss | |
with mentors. Get familiar with Parrot. | |
April 8 - May 23: | |
Begin familiarizing myself with Parrot internals. Research the best compiler (OpenJDK, GCJ) to modify versus | |
the development of a new compiler using parser generators (ANTLR) or a handwritten compiler. Develop some | |
basic tests for each. Determine viability of each of the Java standards, e.g. generics. Discuss these with | |
mentor and the Parrot community. Find contacts in the Java community to discuss with as well. | |
May 23 - July 11: Begin work. (All indented dates are dates of completion). | |
June 30: Clean out back end of chosen java compiler. Begin expression and control flow conversion. | |
Milestone: Java to Java conversion. Documentation complete to this milestone. No tests this week. | |
June 6: Finish expression and control flow conversion. Begin method and class conversion. | |
Milestone: Expression and control flow conversion complete. Documentation complete to this milestone. | |
Begin to integrate tests for the milestone. | |
June 13: Potential absence for the work week, I should be around on the weekends to make up for any | |
major set back to the project. The worst case is I will be a week behind. If there is no absence then I can | |
begin work on more advanced Java features sooner, or have more time for debugging, etc. | |
June 20: Method and class conversion. | |
Milestone: Basic cases work. Documentation complete to this point. No test cases this week. | |
June 27: Finish methods and Class calls and definitions. Integrate test suite for this part of the | |
compiler. | |
Milestone: Method and class calls and definitions are complete. Documentation complete up to this point. | |
Basic tests for these features implemented. | |
July 4: Tests for this portion of the compiler. Prepare for interim review. Determine viability of | |
PAST back end. Set firm criteria for PAST evaluation. | |
Milestone: Finish the test suite for the stage 1 compiler. Clean up documentation. | |
July 11: Interim review. Make a decision on PAST, and begin work on PAST back end or alter plan | |
accordingly. Criteria for the decision will be ability to complete the project on time and in a way that is | |
maintainable. The focus should be on maintainability as Java is an important language for the Parrot arsenal | |
and must function properly. | |
Milestone: Java to PIR compiler complete for provided test cases. Compiler should bootstrap. | |
Decision on PAST. | |
July 18: Work on PAST back end or equivalent. | |
Milestone: Expression and control flow back end switched. Documentation to go with it. Test cases modified | |
accordingly. | |
July 25: Finish work on PAST back end. Begin integration with java standard library (likely GNU | |
classpath) | |
Milestone: PAST back end complete. Stage 2 compiler compiles with Parrot optimizations. Documentation | |
updated. Tests reflect any changes made by including PAST. | |
August 1: Integration with standard library (likely candidate is GNU classpath). | |
Milestone: Finish standard library integration. Documentation reflects this, and includes recommendations | |
about how to use a different standard library if modification is necessary. Test suite updated to include | |
tests of the library. | |
August 8: Tests for Stage 2 compiler. Improve the build system. Work on cross language support | |
and other parrot features. | |
Milestone: Build test suite of the entire project. Documentation complete for stage 2 compiler. | |
August 15: FEATURE FREEZE: Finish anything that is not working. Finish the build system. Document any | |
notes about adding more parrot features to the compiler | |
Milestone: Feature freeze. Finish any remaining debugging, clean code and documentation, build test cases, etc. | |
August 22: Final submission | |
Milestone: Finished GSOC project. | |
References and Likely Mentors | |
Peter Lobsinger | |
IRC Discussions: | |
Whiteknight | |
License | |
All Parrot projects should use the Artistic 2.0 license. | |
Bio | |
I am a sophomore computer science student at the University of Rochester. I have taken the following | |
computer science classes: | |
Programming Language Design and Implementation, this covered the design of compiler front ends and basics of | |
optimization. In this class I wrote a compiler for C. | |
Computation and Formal Systems, | |
Data Structures and Algorithms | |
Artificial Intelligence | |
Discrete Math | |
Linear Algebra & Differential Equations | |
Calculus I & II | |
I have experience with Java, C/C++, Python, Ruby, FORTRAN, and a host of small scientific languages, and I | |
am familiar with Linux/Unix. While I do not have familiarity with open source development I do use a variety | |
of pieces of open source soft ware and have participated in private sector software development. In the | |
past, I have been responsible in the past for projects of this size in my previous employment at Los Alamos | |
National Laboratory, where over three summers I completed three projects: | |
1) Rewrote an old hydrodynamic code from FORTRAN77 to FORTRAN95. | |
2) Developed a graphing tool for use with a rad-hydro code | |
3) Developed a graphing tool and scripting interface for use with a different rad-hydro code. | |
Eligibility | |
I am an eligible student who is a U.S. citizen and has the documentation to prove it. | |
Also, can you explain why you would want to be outputting PIR code, and not a higher-level target such as Winxed or NQP? Could you explain that decision a little bit, and maybe discuss some of the trade-offs between target languages?
Outputting PBC directly is very complicated and is not recommended for a project of this size.
- You mention you will be having a test suite (Good!) What tools are you going to use to create it? Are there standard tools from the Java ecosystem which you will use to run tests (JUnit seems to be the popular choice) or are you planning to use tools from the Parrot ecosystem (Test::More or Rosella)?
- Same thing with documentation. Specify a little bit more how your documentation will be written (JavaDoc seems to be the obvious choice). Also, specify what your documentation deliverables will be (HTML pages? Pages on github?)
- Expand your timeline a little bit. Explain each milestone in more detail, including test and documentation goals for each week. Don't leave these things until the end, they are just as important as the code. Without good tests and documentation, even if your software works at the end, the project will be considered a failure. Make sure to budget time for these things up front.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On "Week of June 13" you mention a potential absence. What are the chances that you will be absent, and for about how long? If you are absent, how will your schedule be affected? If you are not absent, will the rest of your schedule move forward?
Don't wait until April 8th to begin getting familiar with Parrot :)
If writing a new code generator for an existing compiler is your primary development goal, do you need to spend so much time researching Java language syntax? At the point of the code generator, syntax should not matter.
Planning ahead is good but limited. Sometimes you need to just start writing the code to see if it works, and be prepared to throw it away if it does not. Breaking your project into small bits, and working on those bits in short cycles is the best way to prevent yourself from getting trapped down the wrong road. Can you give any more details about how you are going to break up the work? Can you break out an ordering for when you will work on code generation for variables, vs code generation for functions, vs code generation for loops/conditionals, etc?
Your first stage compiler should output PIR so you can have Java code compiled down to run on Parrot. Your second stage compiler could be creating PAST (which is a set of parrot objects, so you need to be running on Parrot to use it). Can you give an idea of a cut-off date, when you will decide whether or not to pursue PAST? If the PIR backend is not going well, you should focus on that and make sure it it done correctly instead of moving on to the next stage and doing two things poorly. Add in a deadline for when this decision will have to be made, and what your criteria will be for deciding what to do.