Inside Java2Script: Reusing
There are two advances of Java2Script technologies:
- Reusing existed Java codes
- Reusing existed Java tools
It’s totally about reusing. Reusing is the most important things in the programming world: source codes reusing, binary library reusing, model pattern reusing, framework reusing. Without reusing, it will mean that everyone should have to re-inhevent the wheel and then we will always stay in the stage of round wheels. Thanks to the reusing, we have great world now.
Java2Script Pacemaker is developed to give developers a toolkit of reusing existed codes and tools. And Java2Script Pacemaker is reusing other codes and tools:
- J2S is reusing Eclipse JDT (J2S won’t exist without JDT)
- J2S is reusing Java SDK’s java.* sources
- J2S is reusing SWT sources and models (org.eclipse.swt.*) and Visual Editor
Reusing does not mean that the sources or tools should be reused without modifications. In above reusings, I extend some extension points of JDT to given new functions, and I modify parts of the sources java.* so that the generated JavaScript is simple, and I have to reinvent the SWT Widgets inside Browser beside reusing the Events and Layouts of SWT.
Reusing already saves me a lot of time. Without JDT, I won’t have the abilities to parse the Java sources and building the DOM tree and binding. Without DOM tree and binding, I can’t generated the JavaScript codes. Without reusing java.* sources, I will have to spend times to re-write those complicated Map, Set and List implementations. Without org.eclipse.swt.layout.*, I will dedicate most of my time in tunning the layout! Without all these reusing, J2S and the related JavaScript version of SWT won’t come out in a short time. Thanks to the reusing.
Following is the questions and answers I am thinking these days:
Q: Does the Java2Script Pacemaker focus on reusing source codes only?
A: Always reusing source codes is the first of step of reusing others. But you should have already noticed that J2S is also reusing tools including Visual Editor and the Eclipse Platform.
Q: Is Java2Script Pacemaker have the abilities to reuse existed frameworks?
A: I think we should not make too much expectation on the JavaScript codes. But we can integrate the Java2Script Pacemaker with other existed frameworks, as Java2Script technology is still developing.
Q: Will Java2Script be hot in the future?
A: I don’t know. But I know, for sure, that reusing existed codes will save people’s efforts in the progress of converting desktop applications into web applications. And reusing will always be the spirit of programming.
Enjoy using Java2Script, enjoy reusing and keep thinking in reusing.
Java2Script Pacemaker 
on January 26, 2006 on 10:07 am
Hi,
I tried to compile a larger java project to JavaScript. There are some important issues:
1. Without a loader approach you cannot solve cyclic dependencies like:
public abstract class Token
{
public static final int EOF = CharStream.EOF;
public static final Token EOF_TOKEN = new CommonToken(EOF);
};
public class CommonToken extends Token
…..
2. Your compiler does not work for code like:
class DFA2 extends DFA
{
DFA.State s = new DFA.State()
{
public DFA.State transition(IntStream input) throws RecognitionException {
int LA2_10 = input.LA(1);
if ( LA2_10==ID||(LA2_10>=11 && LA2_10
on January 26, 2006 on 8:34 pm
“Cyclic dependencies” is a problem that I knew. ClassLoader method may require times and efforts. A sugguestion at this time is to refactor the original Java codes so that cyclic dependencies is not a problem for JavaScript. Tips: static members of a class will instantialized instantly after the declaration of the class. You should instntialize the static member by lazy loading method if it’s in cyclic dependencies.
It seems that inner classes compiling is not fully implemented. I tested the compiler on inner class issue by testing on java.util.* (HashSet, HashMap, …). After seeing that java.util.* worked OK (but may not be completely correct), I did not make any further tests (Constructing complicated inner classes with all different usages may require good understanding of Java Specification. The best way to test the compiler is running testcases over Java TCK. But it will never have the chance or need to do so, as Java2Script is not a pure Java compiler indeed). Maybe you can seperate you DFA2 classes out from the project, and send me a copy so I can study more about the inner class implementation of Java2Script compiler.
Actually, there are other defects in Java2Script, which will require more efforts to overcome.
1. Thread in Java will never be implemented in pure JavaScript (Some alternatives should be invented to imitate the Thread activites: waiting, sleeping, blocking, and so on)
2. Primitive types: byte, short, int, long, float, double are all treated as Number Objects in JavaScript
3. Regular Expression is not implemented yet.
4. Array with different multiple dimensions is not distinguished in the metho invocation. Example, “int[][] a” and “int[] a” is all treated as “Array a”.
5. Others…
The original goal of the project Java2Script is to provide a toolkit to translating Java codes into JavaScript with about the ideal 95%+ compatiablities. 🙂
on May 12, 2007 on 12:20 am
[…] following is an article that I posted about a year ago. I just repost it, because I think Reusing Java codes and tools is my fundamental […]
on June 24, 2007 on 8:08 pm
ford fusion
on April 15, 2009 on 1:08 pm
Hey, nice tips. I’ll buy a bottle of beer to that person from that forum who told me to go to your blog 🙂
on December 17, 2009 on 10:45 pm
в конце концов: превосходно…
on May 27, 2012 on 8:38 pm
no no hair removal does it work
We truly appreciate this article. I’ve looking on all over due to this! Give thanks goodness I found the idea in Google. You’ve manufactured my personal day! Thank you again.. no no hair removal in stores