Amongst the -many- great things said in 208, I really liked the wake-
up call given during the discussion about why core libraries tend to
be written in vanilla java. As much as many of us are rooting for
scala and other improvements to a foothold, I now believe it won't
really happen.
I'm now committed to see if my toy plan for java.next can actually
become something. I'll quickly explain it:
There are a number of boiler-platey java snippets which you could
easily translate to a hypothetical cleaner, more readable format. You
can translate from this newer format to vanilla java, and back,
without having to resort to 'magick' comments or finicky patterns
which have to be followed exactly. For example, imagine writing a tool
that looks at java 1.4 style code, and translates array and list
iteration to a foreach loop. It's not hard to image this, and I doubt
you'll run into the problems you have with GUI generators (where any
change to the underlying 'vanilla' java tends to confuse the GUI
generator so much that it can no longer make sense of the java code).
It's just too straightforward.
I can come up with lots of useful java language additions that are
similarly translatable. This isn't exhaustive, but, a few examples:
- CICE. CICE in particular is an exact boilerplate to shorter format
translation. The following:
new Thread(new Runnable() { public void execute() { /* code */});
becomes:
new Thread(Runnable() { /* code */});
which translates forwards and backwards, no problem.
- 'properties' - a way to annotate or otherwise mark private fields
so that vanilla get, set, and optionally, addPropertyListener, is
generated. The only question in translating back and forth is where
the getter and setter methods should show up in the code
(alphabetically sorted, inserted right below the field? grouped?).
It's not quite the full blown properties that Joe wants, but its a
step in the right direction.
- list and map literals.
- default parameter values.
- map foreach (for (K key, V value : someMap) { /* code */ } instead
of using Map.Entry directly ).
- infer type for local final variables (just 'final foo = "hello"; is
valid).
I'd like to make plugins for netbeans and eclipse which let them
transparently support these features. The key factor is that, on disk,
ONLY vanilla java is stored. When you read in the vanilla java, the
code is automatically scanned for patterns and converted (in memory
only) to the newer syntax, and then, when you save the file, it's
converted back to vanilla java again. This means that boilerplatey
code written by anyone, even those not aware of the existence of
java.next / these plugins, gets converted. You get the benefits of the
new language even for your 'old' code - there's NO need to refactor
your code, there's no need to mess with your tool chain, and there's
no need to reach a consensus before turning on this plugin when
working in a bigger team. No one would notice unless you told them.
In order for this to work, I was planning on building the following
parts:
1. a modified javac that understands all the new features and knows
how to generate the right bytecode. This is needed because you at
least need to parse the new format, and if you can't compile it
directly, you get screwed up line numbers for debugging, which is no
good. Probably stored as a branch off of javac trunk.
2. A converter which converts a javac generated AST to the eclipse
AST model. The eclipse parser pretty much sucks, and from my limited
experience, javac is now better at error recovery (making sense, in as
far as possible, of code with syntax errors in it) than eclipse's 1985
Ada parser based thing, so this seems like an easier route than
hacking ecj.
3. Two ast-to-ast converters; one to convert vanilla java to new
format java, and one to convert new format java back to vanilla java.
I'm looking at ripping jackpot back out of netbeans' refactoring
engine and using that (it's an AST to AST converter, after all). This
would involve updating jackpot so it knows about new java's syntax.
4. A plugin, for both eclipse and netbeans, which replaces the parser
and compiler with the modified javac (in eclipse's case, the modified
javac + the javac AST to eclipse AST converter), and where needed adds
quickfixes and other polish. Due to the design of at least eclipse,
this can't be released as a traditional plugin as it has to replace
the java-specific plugins which are pretty deeply entrenched;
therefore,
5. an installer which backs up the existing java plugins, then
patches them with the various additions, or, alternatively, a
repackaged complete IDE that's been patched. The latter is easier but
forces the user into a specific version of eclipse/netbeans.
As you can see, this is complicated. If anyone wants to help out,
email me. If you have a lot of experience hacking netbeans/eclipse in
particular, I'd love to hear from you. I'm not too sure I can do those
bits without spending /a lot/ of time researching.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
