If I were the king of Java...
jonatha...@gmail.com
wanted to stop throwing NullPointerExceptions (!), there are two
things that I think Java really needs. I don't follow the JCP arena
at all but these *must* come up a lot and I wonder what the
counter-arguments are.
1) A primitive fixed decimal type, numeric, like in SQL. BigDecimal
is a nightmare to try to do math with, and in business programming
fixed decimal calculations occur much more frequently than floating
point.
2) An implementation of java.util.Stack that derives from ArrayList
instead of Vector, and (especially) which supports generics. It
hardly takes long to write but it's really a pretty basic thing to
have in the standard library.
I don't believe, however, that Java should get language support for
continuations or function parameters or all the other 1,000,001
language features that are out there. If every language crammed in
every feature, every language would just be C++. (Or Common Lisp if
it was done well, heh). Java as it is supports a clean programming
style that is suitable for large projects and discourages spaghetti,
it should stay in that niche, especially with more languages coming
onto the JVM which can be used by those who want/need some esoteric
feature.
Andy Gherna
> 2) An implementation of java.util.Stack that derives from ArrayList
> instead of Vector, and (especially) which supports generics. It
> hardly takes long to write but it's really a pretty basic thing to
> have in the standard library.
I think it's a flaw that Stack is a subclass of Vector to begin with.
It would be okay for a Stack to use a Vector to manage adding and
removing elements, but Stack should be a class that extends
java.lang.Object, not java.util.Vector.
>
> I don't believe, however, that Java should get language support for
> continuations or function parameters or all the other 1,000,001
> language features that are out there.
Kind of agree here. I don't understand continuations or function
parameters but adding support of features that are in other languages
or are already kind of in the JDK doesn't really add much value for me
(at least that I can see but I'm not a visionary :-) )
For example, I'm on the fence about closures. Doesn't the JDK already
have anonymous inner classes that IMO were object-oriented type
closures? What does adding closures explicitly do for the language
besides make reflection even more complex? It seems like syntactic
sugar to me.
OTOH, in the case of adding a feature to the language like XML literals
or even regexp literals would add value for me. Syntactic sugar you
say? Yes, but it's sugar that's sweeter to me than closures :-)
> If every language crammed in
> every feature, every language would just be C++. (Or Common Lisp if
> it was done well, heh).
You're right. But Java will continue to grow and it won't always be in
a direction that everyone will like. I trust the langauge architects
and the JCP to make the right decisions most of the time (that is, 95%
of the time) though. So far, they've done things the right way ;-)
> Java as it is supports a clean programming
> style that is suitable for large projects and discourages spaghetti,
> it should stay in that niche, especially with more languages coming
> onto the JVM which can be used by those who want/need some esoteric
> feature.
Agree with you here. Supporting more languages on the JVM would
definitely be a way to curb the amount of language features added to
the langauge. Simplice, JRuby and Groovy are excellent examples of how
to build functionality into the Java platform without changing the Java
language.
Curt Cox
different views of the source using different editors for different
types of code. Mathematical formulas could be edited by formula
editors, beans could be edited by beans editors, etc...
Under this model, any language that is isomorphic to Java could be
used in place of Java. Consider this "language":
bean Foo {
String bar;
int baz;
}
If bean is just a shorthand for "a class with all of the standard
property change support built in" so that there is a unique and
unambiguous translation between beans and classes, then you can extend
the language without extending the language. The Java language
becomes the standard source file format. If you don't know "bean",
but know Java that's OK because you can look at the source as Java.
Autoboxing, varargs, enhanced for loops, and at least one of the
closure proposals would all seem to fall into this category.
"Concise Instance Creation Expressions: Closures without Complexity"
http://www.writely.com/Doc.aspx?id=k73_1ggr36h
Did I misunderstand Jackpot?
jonatha...@gmail.com
> It would be okay for a Stack to use a Vector to manage adding and
> removing elements, but Stack should be a class that extends
> java.lang.Object, not java.util.Vector.
Well, it does have to implement Collection, and it's nice that it
implements List as well. I would say Stack should be an interface like
List, Set and Map, with differing implementations based on different
algorithms, (like ArrayList and LinkedList). This would fit into the
'spirit' of the Collections framework, whereas right now it's really an
odd one out.
Andy Gherna
>
> Well, it does have to implement Collection, and it's nice that it
> implements List as well.
Why does it have to implement Collection? It's a Stack.
> I would say Stack should be an interface like
> List, Set and Map, with differing implementations based on different
> algorithms, (like ArrayList and LinkedList). This would fit into the
> 'spirit' of the Collections framework, whereas right now it's really an
> odd one out.
How many different algorithms do you need for a Stack? I didn't really
ever think of Stack being a member of the collections framework. It's
a great utility class for sure, but because of it's ancestry (i.e.
Vector), it's easy for some programmers to cheat and use it's parent
methods when the going gets tough...
Andy Gherna
Curt Cox wrote:
> I thought one of the ultimate goals of Jackpot was to provide
> different views of the source using different editors for different
> types of code. Mathematical formulas could be edited by formula
> editors, beans could be edited by beans editors, etc...
I'm aware of Jackpot, but I haven't delved into what it can do. So you
may have my argument in a full nelson at this point. :-)
>
> Under this model, any language that is isomorphic to Java could be
> used in place of Java. Consider this "language":
<snip>
I'm assuming that Jackpot defines this isomorphism, right?
> If bean is just a shorthand for "a class with all of the standard
> property change support built in" so that there is a unique and
> unambiguous translation between beans and classes, then you can extend
> the language without extending the language. The Java language
> becomes the standard source file format. If you don't know "bean",
> but know Java that's OK because you can look at the source as Java.
OK, this makes sense. But if the language were to be extended by
adding new syntactic and functional constructs, could new bytecodes be
added to support them?
> Autoboxing, varargs, enhanced for loops, and at least one of the
> closure proposals would all seem to fall into this category.
>
> "Concise Instance Creation Expressions: Closures without Complexity"
> http://www.writely.com/Doc.aspx?id=k73_1ggr36h
>
> Did I misunderstand Jackpot?
Maybe, but I don't know much about Jackpot myself :-) I will need to
read the document you linked to.
Curt Cox
could be used to do so.
"But if the language were to be extended by adding new syntactic and
functional constructs, could new bytecodes be added to support them?"
New bytecodes shouldn't enter into the picture. Java can be expressed
using existing bytecodes. Any language that requires new bytecodes is
not isomorphic with Java. An enormous number of very useful languages
are isomorphic with Java, however.
jonatha...@gmail.com
> Why does it have to implement Collection? It's a Stack.
Hm, interesting point; I had always just assumed that Stack would be
part of the Collections framework. I would justify this because a
Collection, in Java parlance, is a data structure that is a group of
stuff. So a stack is a case of this, and the basic properties of
Collection (iterator, size, isEmpty, etc.) are properties of a stack.
At any rate though, I maintain that Stack should be an interface,
because the entire definition of a Stack is something that you can
peek(), push(), and pop() on--and that's an interface's definition if
ever there was one.
Tor Norbye
(1) Regarding Stack: Use java.util.Deque (and java.util.ArrayDeque)
instead. The javadoc will tell you the rest.
(2) "Why do you want a stack to be a Collection?" Because logically a
stack is a collection - you may want to iterate over it, you may want
to add this collection to another collection, etc.
(3) Jackpot - no, that's not really what Jackpot is intended for. It's
intended to operate on legal Java source code, and transform it into
something else. The original Jackpot Sun Labs work did however have
visualizers like you're describing (formulas displayed inline etc.)
-- Tor
reinierz
just as bunch of methods that happen to exist in e.g. LinkedList, which
makes for as fine a stack as any, really. push() would simply tack onto
the BEGINNING, so that any attempts to iterate would do approximately
what you expect (go through as if you pop()ed em all).
Curt Cox
So this vision exists no more? Pity. The number of Java programmers
is already too large to be adequately served by one language.
Building IDEs that supported languages isomorphic to Java, while using
Java as a common persistence format, would be a way to tailor the
language to smaller communities without splintering it.
It's easy to come up with lots of really useful Java "skins":
1) defaults of "final" and "private"
2) simple closures
3) explicit boxing
4) array notation for maps and lists
5) operator overloading
6) property support
7) mathematical notation
8) scientific notation (units)
9) financial notation (currency)
10) keywords in other languages
11) EVIL instead of tab
"You can, for example, turn the square root function into the obvious
mathematical notation. You can turn the identifier theta into the
Greek letter theta. You can turn division into the horizontal bar with
numbers stacked. And we've done experiments with wackier things, such
as trying to generate real time flow charts. That's kind of goofy, but
entertaining. Other things like hiding block contents, doing
interesting typography, doing typography on comments, all actually
work out reasonably well."
- James Gosling
Jonathan Craven
Tor Norbye skribis:
> (1) Regarding Stack: Use java.util.Deque (and java.util.ArrayDeque)
> instead. The javadoc will tell you the rest.
Awesome, Deque is exactly what I was wishing for! Somehow it
completely escaped my notice before now. You learn something every
day...
Tor Norbye
> "You can, for example, turn the square root function into the obvious
> mathematical notation. You can turn the identifier theta into the
> Greek letter theta. You can turn division into the horizontal bar with
> numbers stacked. And we've done experiments with wackier things, such
> as trying to generate real time flow charts. That's kind of goofy, but
> entertaining. Other things like hiding block contents, doing
> interesting typography, doing typography on comments, all actually
> work out reasonably well."
> - James Gosling
>
> http://www.artima.com/intv/jackpot2.html
I believe this quote only talks about -visualizing- existing Java code
in an editor, not transforming other languages into valid VM code.
-- Tor
Curt Cox
code in an editor, not transforming other languages into valid VM
code."
Of course, you're right. I couldn't find some of the Jackpot related
articles that I've read before. Perhaps my vision of what Jackpot
could become was only ever mine. If you want to have a custom editor
for some language that is isomorphic to Java, visualization gets you
reasonably close. For custom editors you need:
1) a way to translate from Java to X
2) an editor for X
3) a way to translate from X to Java
For custom visualization, you need:
1) a way to translate from Java to X
2) a viewer for X
Other than being less work, I'm not sure why you would stop at code
viewers instead of supporting code editors.
Tom Ball
Tor is right, that prototype was focused on alternative visualizations
of Java code, not translations between languages.
I think the main confusion here is that the definition of Jackpot has
changed over the years. When the project was first formed at Sun Labs,
its charter was to research small experiments to improve Java developer
productivity. Rather than publish papers, our "publication vehicle"
was NetBeans; an example is the metrics module at
http://metrics.netbeans.org, which is an experiment in moving select
metric feedback into the edit/build loop. The visualization editor is
another experiment, but it never got to the stage of being a NetBeans
module. The interview you referenced was done around that time.
Shortly after that interview, we were ordered to focus on the single
most promising experiment, which was the Java "morphing" engine which
James prototyped, and drop all other experiments including the enhanced
editor. When we moved to the Java Developer Products (tools) group,
James became its CTO while I took over the engine which by that time
was named Jackpot. During the past couple of years, we've applied
aspects of Jackpot to other tools, including the NetBeans 4.0 model,
Java Creator, and javac in Java 5 and 6. Now a productized version of
that technology is available as an early release
(http://jackpot.netbeans.org) and will be integrated into NetBeans 6.0.
My guess is that the term "Jackpot" will then disappear.
Unfortunately some of its ideas, such as enhanced editing, will
disappear as well.
Tom
Curt Cox
Even when the news is bad, the transparency is always appreciated.
Given the rise of supported alternate languages on the JVM and APIs
related to Java compilation, I'm not so sure how dead the idea is.
Thanks,
Curt
Tom Ball
that such a project is a lot easier now that the Compiler API is
available, as you can walk a program's AST and output whatever your
heart desires (of course, the further from Java you go, the more work
it is). I wrote about how to hack javac here:
http://weblogs.java.net/blog/tball/archive/2006/09/hacking_javac.html
Have fun experimenting!
Tom
Werner Schuster (murphee)
> The idea isn't dead, we're just not working on it. The good news is
> that such a project is a lot easier now that the Compiler API is
> available, as you can walk a program's AST and output whatever your
>
Even easier and available for the past few years: the Eclipse JDT, which
allows you to use the AST of source files and high level Rewrite APIs
that make it easy to change source code ("high level" because you don't
have to mess with editing the char streams, but instead work on/with the
AST).
Links:
Eg.
http://www.tutorials.de/forum/java/253891-eclipse-jdt-refactoring-programmatisch-verwenden.html
http://www-128.ibm.com/developerworks/opensource/library/os-ast/?ca=dgr-lnxw16ASTParser
I can particularly recommend an article about writing a refactoring
using the JDT http://www.eclipsemag.net/ , which also illustrates the
powerful Refactoring tools available (eg. bulk changes, diff preview,
etc, more about this here
http://www.eclipse.org/articles/Article-LTK/ltk.html). These tools
remind me of what's available with the Smalltalk Refactoring Browser
http://st-www.cs.uiuc.edu/users/brant/Refactory/ .
And for the quick starter: Fire up EclipseShell,
http://eclipse-shell.sourceforge.net/ which allows you to use JDT (and
APIs from all other Plugins) interactively from JRuby, Beanshell or
Rhino. The website contains screencasts with me messing with the Ruby
RDT, but the JDT is just as easily accessible. (Sorry for the plug, but
EclipseShell is the quickest way to play around with Plugins).
I'm usually quite amazed that folks seem intrigued at breathless blog
posts about the "new AST access in Java 6", despite the fact that with
the Eclipse JDT this has been available for years (not to mention that
Tomcat uses it for JSPs and GWT uses it as its Java parser).
murphee
--
Blog @ http://jroller.com/page/murphee
Maintainer of EclipseShell @ http://eclipse-shell.sourceforge.net/
Tor Norbye
> I'm usually quite amazed that folks seem intrigued at breathless blog
> posts about the "new AST access in Java 6", despite the fact that with
> the Eclipse JDT this has been available for years (not to mention that
> Tomcat uses it for JSPs and GWT uses it as its Java parser).
I think what people are excited about is that they can now access and
use the standard compiler, such that they can always use the latest and
greatest compiler features as they are added to the RI, without having
to wait for downstream adoption of the standards, such as the JDK 5
language features.
-- Tor