What do you think went unsaid at JavaOne?

[hayden.p...@gmail.com]

1) No news about the Java store.

2) No news about ASF and the JCK. By the way, what's wrong with them
just saying, "No, you're not going to get it because we earn revenue
from this."

3) Interesting JavaFX script is being dropped. But not even a straw
man proposal of what the java syntax to the library would look like.

[Steven Herod]

On Sep 24, 11:56 am, "hayden.paul.jo...@gmail.com"

<hayden.paul.jo...@gmail.com> wrote:
> 1) No news about the Java store.

I think we'll chalk it up as 'embarrassing failure' with a small press
release remarking its death.

> 2) No news about ASF and the JCK.  By the way, what's wrong with them
> just saying, "No, you're not going to get it because we earn revenue
> from this."

Because more bad can come from a definitive no than an ambivalent
probably not?

> 3) Interesting JavaFX script is being dropped.  But not even a straw
> man proposal of what the java syntax to the library would look like.

I think this was covered wasn't it? JavaBean style... so

Rectangle {
width: 10
height: 10
background:
}

is going to be

Rectangle r = new Rectangle();
r.setWidth(10);
r.setHeight(10);
r.setbackground();
..
..
..

*sob*

[B Smith-Mannschott]

So, what's wrong with that? I thought the myriad Scala threads on this list had conclusively established that nobody needs syntactic sugar in the first place and besides, Java isn't really full of boilerplatey verbosity, that's just the haters talking. 

(ducks) ;-)

// Ben

[Jonathan Giles]

I did a talk at JavaOne that covered some of the Java syntax, as well
as brief examples in Scala, Clojure, JRuby and Groovy.

Check it out my website:
http://jonathangiles.net/blog/?p=916

-- Jonathan Giles

On Sep 23, 6:56 pm, "hayden.paul.jo...@gmail.com"

[Kevin Wright]

No need to despair, this soon coming to a JVM language near you:

val r = Rectangle {
  width = 10
  height = 10
  background = ...
}

--
Kevin Wright

mail / gtalk / msn : kev.lee...@gmail.com

pulse / skype: kev.lee.wright
twitter: @thecoda

[hayden.p...@gmail.com]

Thanks Jon, I have read your slides once or twice. What was not clear
to me was on the best way to create/populate the Stage objects (and
their event handlers).

Would we be able to use an fx file with just the GUI elements or
should we build it using java code? Do you think it would be similar
to JSF?

I look forward to seeing what your team comes up with.

[Fabrizio Giudici]

F1) Nothing on the corporate strategy about Google has been said.
F2) The JME revamping program was, how can I say, a little vague. I
mean, it looks like as Android II, but - unless I've missed something,
and I could - I've not heard about precise milestones. Note that, unlike
any other technology that, once delivered, you just download and start
using, mobile techs have a much longer pipeline: once the reference is
ready, you need manufacturers endorsements and then you have to wait
until the consumers have bought a relevant number of appliances. Even
assuming that Oracle is serious (I have other thoughts, but I won't
disclose now... going to have some birdwatching along the coast!!) I'd
like to hear by which year they presume that the JME.new thing would
have a decent spread (it's obvious I'm quite skeptical about that).

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

[Kevin Wright]

In all the fuss about lambda, nobody seems to have asked what happened to the fixnum proposal, or to tail recursion.

Trail recursion is obviously of more benefit to languages that have a functional bias, but fixnum... think about it, everybody's going to benefit from cheap boxing/unboxing!

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Reinier Zwitserloot]

Cheap boxing/unboxing is indeed a big mystery, though there was one
thing said on J1 that's relevant here: The integration of "some"
JRockit optimizations into OpenJDK. One notable JRockit optimization
that the JVM doesn't have is hotspotting away paired box/unbox
operations. If back-to-back box/unbox are eliminated, you can for
example add primitives to generics (List<int>) fairly simply, by
treating it as basically List<Integer> with some sugar sprinkled in.

tail recursion is still on the backboiler, it's been discussed many
times over the last few years and while its nice, it's not deemed all
that important. For java its useless, as representative stack traces
are deemed more important than the extremely modest performance gain
of tail recursion, and for other JVM languages, well, the authors of
those languages usually don't find tail recursion all that important,
other than a purely ideological sense that it ought to work. They,
too, like representative stack traces. So, basically: Yeah, sure, why
not, if we have some spare time. The spare time isn't there.

See for example Devoxx '09, where it was mentioned.

On Sep 24, 6:23 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> In all the fuss about lambda, nobody seems to have asked what happened to
> the fixnum proposal, or to tail recursion.
>
> Trail recursion is obviously of more benefit to languages that have a
> functional bias, but fixnum... think about it, everybody's going to benefit
> from cheap boxing/unboxing!
>
> On 24 September 2010 16:52, Fabrizio Giudici

> <fabrizio.giud...@tidalwave.it>wrote:

>
>
>
>
>
> >  F1) Nothing on the corporate strategy about Google has been said.
> > F2) The JME revamping program was, how can I say, a little vague. I mean,
> > it looks like as Android II, but - unless I've missed something, and I could
> > - I've not heard about precise milestones. Note that, unlike any other
> > technology that, once delivered, you just download and start using, mobile
> > techs have a much longer pipeline: once the reference is ready, you need
> > manufacturers endorsements and then you have to wait until the consumers
> > have bought a relevant number of appliances. Even assuming that Oracle is
> > serious (I have other thoughts, but I won't disclose now... going to have
> > some birdwatching along the coast!!) I'd like to hear by which year they
> > presume that the JME.new thing would have a decent spread (it's obvious I'm
> > quite skeptical about that).
>
> > --
> > Fabrizio Giudici - Java Architect, Project Manager
> > Tidalwave s.a.s. - "We make Java work. Everywhere."
> > java.net/blog/fabriziogiudici -www.tidalwave.it/people

> > Fabrizio.Giud...@tidalwave.it

>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to java...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
>
> --
> Kevin Wright
>

> mail / gtalk / msn : kev.lee.wri...@gmail.com

[Ricky Clarkson]

tail recursion is still on the backboiler, it's been discussed many
times over the last few years and while its nice, it's not deemed all
that important. For java its useless, as representative stack traces
are deemed more important than the extremely modest performance gain
of tail recursion

Tail recursion is not about performance.  Recursive algorithms crash (StackOverflowError) given enough calls, and that won't happen if they are tail recursive in a language or VM that supports tail recursion.

Does the JVM definitely never remove stack frames due to inlining or any other optimisations?

[Reinier Zwitserloot]

It won't. I'll explain a little more: A plan has been made to add tail
recursion but in a way that, with each recursion, a dummy stack frame
is recorded so that a generated exception still looks as if tail
recursion didn't happen. Such a mechanism could in theory be made to
work endlessly as well, basically by adding a pointer and using an
increment, but tail recursion doesn't have to call itself, and a loop
doesn't have to follow the same path every time through, so getting
that right is rather complicated. If such a loop/count mechanism isn't
added, then you're still going to run into the problem that given
enough recursions, you get memory problems.

The first part of the plan would be to implement TR but to keep the
concept of the growing stack trace. Purely for the modest performance
gain.