Hello Renier,
On Fri, Oct 10, 2008 at 3:07 AM, Reinier Zwitserloot <[EMAIL PROTECTED]>wrote:
>
> 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 */});
Why not:
Thread({/*Code*/}) ?
The need for the "new" keyword is gone.
The compiler knows the constructor args and can infer the type (in this case
Runnable)
The compiler knows that Runnable is a one-method interface, so it allows the
closure block.
>
>
> 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.
getters and setters รก la Java are simply 100% boilerplate.
compare:
case class Person(var firstname, var surname)
to
public class Person
{
private String firstName;
private String surName;
public final void setFirstName(final String firstName)
{
this.firstName = firstName;
}
public final String getFirstName()
{
return this.firstName;
}
public final void setSurName(final String surName)
{
this.surName = surName;
}
public final String getSurName()
{
return this.surName;
}
//Also, I didn't bother to write equals, hashCode and toString, but add
another 20 lines of code below here for that
}
>
>
> - list and map literals.
...and remove arrays from the language... (they are a primitive optimization
construct, the language should only expose ArrayList, and then the VM can
use arrays under the hood)
>
>
> - default parameter values.
>
Praise the Lord!
>
> - map foreach (for (K key, V value : someMap) { /* code */ } instead
> of using Map.Entry directly ).
or like: map.foreach( (K key, V value) { /*Code*/} )
>
>
> - infer type for local final variables (just 'final foo = "hello"; is
> valid).
Or simply make "final" the default.
>
>
>
> 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.
> >
>
--
Viktor Klang
Senior Systems Analyst
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
