Lambda puzzler

[Dennis Sosnoski]

I've run into an interesting issue in the code for an upcoming article.
This works:

public class Name {
public final String firstName;
public final String lastName;

public Name(String first, String last) {
firstName = first;
lastName = last;
}
...
}

Comparator<Name> comp = Comparator.comparing(name ->
name.lastName);
comp = comp.thenComparing(name -> name.firstName);

But this gives compile errors (and errors on the "name" symbol), even if
I use a cast on the second lambda:

Comparator<Name> comp = Comparator.comparing(name1 ->
name1.lastName)
.thenComparing(name2 -> name2.firstName);

I'm wondering if it's a compiler bug, or just somehow a consequence of
the lambda target typing rules:
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing
Any thoughts?

- Dennis



------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Joe Bowbeer]

If you add accessor methods to Name then you can express it as:

Comparator<Name> c =
Comparator.comparing(Name::lastName).thenComparing(Name::firstName);


public class Name {

private final String firstName;
private final String lastName;

public Name(String first, String last) {
firstName = first;
lastName = last;
}
public String firstName() { return firstName; }
public String lastName() { return lastName; }
}

Post by Dennis Sosnoski
I've run into an interesting issue in the code for an upcoming article.
public class Name {
public final String firstName;
public final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
...
}
Comparator<Name> comp = Comparator.comparing(name ->
name.lastName);
comp = comp.thenComparing(name -> name.firstName);
But this gives compile errors (and errors on the "name" symbol), even if
Comparator<Name> comp = Comparator.comparing(name1 ->
name1.lastName)
.thenComparing(name2 -> name2.firstName);
I'm wondering if it's a compiler bug, or just somehow a consequence of
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing
Any thoughts?
- Dennis
------------------------------------
Yahoo Groups Links

[Jim McBeath]

Dennis,

I suspect the problem is that the compiler's type inference is not quite
up to figuring out that you want a Comparator<Name> when you chain them.
And if Java type inference error messages are anything like Scala's,
they will typically be pretty opaque.

--
Jim

Date: Thu, 3 Apr 2014 07:50:49 -0700
Subject: Re: [seajug] Lambda puzzler
Comparator<Name> c =
Comparator.comparing(Name::lastName).thenComparing(Name::firstName);
public class Name {
private final String firstName;
private final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
public String firstName() { return firstName; }
public String lastName() { return lastName; }
}

Post by Dennis Sosnoski
I've run into an interesting issue in the code for an upcoming article.
public class Name {
public final String firstName;
public final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
...
}
Comparator<Name> comp = Comparator.comparing(name ->
name.lastName);
comp = comp.thenComparing(name -> name.firstName);
But this gives compile errors (and errors on the "name" symbol), even if
Comparator<Name> comp = Comparator.comparing(name1 ->
name1.lastName)
.thenComparing(name2 -> name2.firstName);
I'm wondering if it's a compiler bug, or just somehow a consequence of
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing
Any thoughts?
- Dennis
------------------------------------
Yahoo Groups Links

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Dennis Sosnoski]

That does seem most likely, but if that's the case I'd hope that adding
casts would take care of the issue. I'll let you know what I find out.

Thanks,

- Dennis

Post by Jim McBeath
Dennis,
I suspect the problem is that the compiler's type inference is not quite
up to figuring out that you want a Comparator<Name> when you chain them.
And if Java type inference error messages are anything like Scala's,
they will typically be pretty opaque.
--
Jim

Date: Thu, 3 Apr 2014 07:50:49 -0700
Subject: Re: [seajug] Lambda puzzler
Comparator<Name> c =
Comparator.comparing(Name::lastName).thenComparing(Name::firstName);
public class Name {
private final String firstName;
private final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
public String firstName() { return firstName; }
public String lastName() { return lastName; }
}

Post by Dennis Sosnoski
I've run into an interesting issue in the code for an upcoming article.
public class Name {
public final String firstName;
public final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
...
}
Comparator<Name> comp = Comparator.comparing(name ->
name.lastName);
comp = comp.thenComparing(name -> name.firstName);
But this gives compile errors (and errors on the "name" symbol), even if
Comparator<Name> comp = Comparator.comparing(name1 ->
name1.lastName)
.thenComparing(name2 -> name2.firstName);
I'm wondering if it's a compiler bug, or just somehow a consequence of
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing
Any thoughts?
- Dennis
------------------------------------
Yahoo Groups Links

------------------------------------
Yahoo Groups Links

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Dennis Sosnoski]

Yes, I'm able to express it in different ways without a problem. The
puzzler is why that one particular way doesn't work. :-)

- Dennis

Post by Joe Bowbeer
Comparator<Name> c =
Comparator.comparing(Name::lastName).thenComparing(Name::firstName);
public class Name {
private final String firstName;
private final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
public String firstName() { return firstName; }
public String lastName() { return lastName; }
}
I've run into an interesting issue in the code for an upcoming article.
public class Name {
public final String firstName;
public final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
...
}
Comparator<Name> comp = Comparator.comparing(name ->
name.lastName);
comp = comp.thenComparing(name -> name.firstName);
But this gives compile errors (and errors on the "name" symbol), even if
Comparator<Name> comp = Comparator.comparing(name1 ->
name1.lastName)
.thenComparing(name2 -> name2.firstName);
I'm wondering if it's a compiler bug, or just somehow a consequence of
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing
Any thoughts?
- Dennis
------------------------------------
Yahoo Groups Links

[Ross Bleakney]

I like that a lot. That is the best example of using Lambdas I've seen. It is not only more terse, but more easily understood. Most of the examples I've seen are a lot like Steve's rant (they remind me of really confusing C code). Fewer lines does not always mean better code. There is a balance to be made, and finding the appropriate balance often means "dumbing down" the code. Just because you can write it a certain way doesn't mean you should. But like I said, this is a great example of why they added this feature. The code is obvious, easy to modify, and doesn't take up much space. If things get hairy you can always go back to doing things the old way (much as old fashioned "for" loops haven't gone away even though we have "foreach" loops).

I'll admit I haven't followed the new Java features because I doubt we will use them (I figure I'll learn about them sooner or later). So, I'm probably way behind (we compile with 1.6 and could probably compile with 1.5). Keep that in mind while I ask the following:

Is there any syntactic sugar to make beans easier to write? It seems to me if you have a simple bean, with a default constructor, you should be able (in this new, more intuitive, less typing Java universe) to just specify the fields (as private) and be done with it. Maybe something similar to Lombok (but built into the language so you don't have to jump through hoops to get it to work)?

Thanks,
Ross
To: seajug-***@public.gmane.org
From: joe.bowbeer-***@public.gmane.org
Date: Thu, 3 Apr 2014 07:50:49 -0700
Subject: Re: [seajug] Lambda puzzler


























If you add accessor methods to Name then you can express it as:
Comparator<Name> c = Comparator.comparing(Name::lastName).thenComparing(Name::firstName);


public class Name {
private final String firstName; private final String lastName;
public Name(String first, String last) {

firstName = first; lastName = last; } public String firstName() { return firstName; } public String lastName() { return lastName; }
}


On Wed, Apr 2, 2014 at 9:52 PM, Dennis Sosnoski <dms-WAiJhE/vqclWk0Htik3J/***@public.gmane.org> wrote:

I've run into an interesting issue in the code for an upcoming article.

This works:



public class Name {

public final String firstName;

public final String lastName;



public Name(String first, String last) {

firstName = first;

lastName = last;

}

...

}



Comparator<Name> comp = Comparator.comparing(name ->

name.lastName);

comp = comp.thenComparing(name -> name.firstName);



But this gives compile errors (and errors on the "name" symbol), even if

I use a cast on the second lambda:



Comparator<Name> comp = Comparator.comparing(name1 ->

name1.lastName)

.thenComparing(name2 -> name2.firstName);



I'm wondering if it's a compiler bug, or just somehow a consequence of

the lambda target typing rules:

http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing

Any thoughts?



- Dennis







------------------------------------



Yahoo Groups Links



http://groups.yahoo.com/group/seajug/



Individual Email | Traditional



http://groups.yahoo.com/group/seajug/join

(Yahoo! ID required)



seajug-digest-***@public.gmane.org

seajug-fullfeatured-***@public.gmane.org



seajug-unsubscribe-***@public.gmane.org



https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Jason Osgood]

Hi Ross.

Post by Ross Bleakney
Is there any syntactic sugar to make beans easier to write?

Properties, a la C#.

There are a handful of apparently unsexy low hanging fruit features which would significantly improve programmer productivity across the board.

Multi-line strings. String literals. Built-in regex expressions. Lightweight objects. Stuff each and every one of us would use every single day.

These would remove a lot of boilerplate and grunt code.

Post by Ross Bleakney
I haven't followed the new Java features because I doubt we will use the

I know I won’t willingly use them (lambdas).

Meta programming is taboo in a corporate, enterprise environment. Like giving a kid in need of Ritalin a flame thrower and box of grenades.


I may, someday, reconnect with my bad-ass functional programming self. But right now I’m on a code generation kick. It seems to be working fine.


Cheers, Jason

[P.Hill]

Interesting project I only saw used this year:
Lombok
http://projectlombok.org/
Then

@Data
public class Person {
private String firstName;
private String lastName;
}

And tada, you have your bean.

Maybe not perfect on all the trick annotations the author invented, but
certainly the properties are done well.
For example, if you provide your own setter/getter, hashcode or
toString, it will NOT complain. It just adds what is missing.

You can also make individual setters/getters if you don't want them for
everything.
http://projectlombok.org/features/index.html

-Paul

p.s. If you think about it, the fact that an annotation adds code to the
class is very interesting. There is no extra processing step.

Post by Jason Osgood
Hi Ross.

Post by Ross Bleakney
Is there any syntactic sugar to make beans easier to write?

Properties, a la C#.

[George Smith]

Paul,

In the presentation I saw, one of the questions / complaints I heard was
that since the IDE (in this case Eclipse) did not know about Lombok, it
could not see the methods, which killed auto-complete and filled eclipse
with errors if you manually referenced them...

George

Post by Ross Bleakney
Lombok
http://projectlombok.org/
Then
@Data
public class Person {
private String firstName;
private String lastName;
}
And tada, you have your bean.
Maybe not perfect on all the trick annotations the author invented, but
certainly the properties are done well.
For example, if you provide your own setter/getter, hashcode or toString,
it will NOT complain. It just adds what is missing.
You can also make individual setters/getters if you don't want them for
everything.
http://projectlombok.org/features/index.html
-Paul
p.s. If you think about it, the fact that an annotation adds code to the
class is very interesting. There is no extra processing step.
Hi Ross.
Is there any syntactic sugar to make beans easier to write?
Properties, a la C#.

[Dennis Sosnoski]

That's the problem I see with doing this outside the compiler. It really
needs to be part of the Java language definition, and should have been
since 1.5 - it's probably the strongest use case for an annotation I've
ever seen.

- Dennis

Post by George Smith
Paul,
In the presentation I saw, one of the questions / complaints I heard
was that since the IDE (in this case Eclipse) did not know about
Lombok, it could not see the methods, which killed auto-complete and
filled eclipse with errors if you manually referenced them...
George
Lombok
http://projectlombok.org/
Then
@Data
public class Person {
private String firstName;
private String lastName;
}
And tada, you have your bean.
Maybe not perfect on all the trick annotations the author
invented, but certainly the properties are done well.
For example, if you provide your own setter/getter, hashcode or
toString, it will NOT complain. It just adds what is missing.
You can also make individual setters/getters if you don't want
them for everything.
http://projectlombok.org/features/index.html
-Paul
p.s. If you think about it, the fact that an annotation adds code
to the class is very interesting. There is no extra processing step.

Post by Jason Osgood
Hi Ross.

Post by Ross Bleakney
Is there any syntactic sugar to make beans easier to write?

Properties, a la C#.

--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown

[Ross Bleakney]

Post by Ross Bleakney
Maybe something similar to Lombok (but built into the language so you don't have to jump through hoops to get it to work)?

and later ...

Post by Ross Bleakney
This is why I'm surprised that the Java folks didn't add something like

Lombok. I know I could just use it, but it hardly like using a Jakarta
library. It messes with the compilation. Not all IDEs support it. I have
enough trouble getting Eclipse working with ...

Ross

To: seajug-***@public.gmane.org
From: dms-WAiJhE/vqclWk0Htik3J/***@public.gmane.org
Date: Tue, 8 Apr 2014 15:26:07 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler


























That's the problem I see with doing
this outside the compiler. It really needs to be part of the Java
language definition, and should have been since 1.5 - it's
probably the strongest use case for an annotation I've ever seen.



- Dennis



On 04/08/2014 02:29 PM, George Smith wrote:





Paul,



In the presentation I saw, one of the questions /
complaints I heard was that since the IDE (in this case
Eclipse) did not know about Lombok, it could not see the
methods, which killed auto-complete and filled eclipse with
errors if you manually referenced them...



George





On Mon, Apr 7, 2014 at 5:05 PM, P.Hill
<parehill1-***@public.gmane.org>
wrote:









Interesting project I only saw used this year:

Lombok

http://projectlombok.org/

Then



@Data

public class Person {

private String firstName;

private String lastName;

}



And tada, you have your bean.



Maybe not perfect on all the trick annotations the
author invented, but certainly the properties are
done well.

For example, if you provide your own
setter/getter, hashcode or toString, it will NOT
complain. It just adds what is missing.



You can also make individual setters/getters if
you don't want them for everything.

http://projectlombok.org/features/index.html



-Paul



p.s. If you think about it, the fact that an
annotation adds code to the class is very
interesting. There is no extra processing step.



On 4/3/2014 4:20 PM, Jason Osgood wrote:




Hi Ross.





Is
there any syntactic sugar to make beans
easier to write?



Properties, a la C#.






















--

"And the users exclaimed with a laugh and a taunt: It's
just what we asked for but not what we want." -- Unknown

[Dennis Sosnoski]

Sorry, Ross - I, at least, didn't know the specifics of what Lombok was
doing until Paul gave the example.

- Dennis

Maybe my original and followup message got chopped off. I mentioned

Post by Ross Bleakney
Maybe something similar to Lombok (but built into the language so

you don't have to jump through hoops to get it to work)?
and later ...

Post by Ross Bleakney
This is why I'm surprised that the Java folks didn't add something

like Lombok. I know I could just use it, but it hardly like using a
Jakarta library. It messes with the compilation. Not all IDEs support
it. I have enough trouble getting Eclipse working with ...
Ross
------------------------------------------------------------------------
Date: Tue, 8 Apr 2014 15:26:07 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
That's the problem I see with doing this outside the compiler. It
really needs to be part of the Java language definition, and should
have been since 1.5 - it's probably the strongest use case for an
annotation I've ever seen.
- Dennis
Paul,
In the presentation I saw, one of the questions / complaints I
heard was that since the IDE (in this case Eclipse) did not know
about Lombok, it could not see the methods, which killed
auto-complete and filled eclipse with errors if you manually
referenced them...
George
Lombok
http://projectlombok.org/
Then
@Data
public class Person {
private String firstName;
private String lastName;
}
And tada, you have your bean.
Maybe not perfect on all the trick annotations the author
invented, but certainly the properties are done well.
For example, if you provide your own setter/getter, hashcode
or toString, it will NOT complain. It just adds what is missing.
You can also make individual setters/getters if you don't want
them for everything.
http://projectlombok.org/features/index.html
-Paul
p.s. If you think about it, the fact that an annotation adds
code to the class is very interesting. There is no extra
processing step.
Hi Ross.
Is there any syntactic sugar to make beans easier to write?
Properties, a la C#.
--
"And the users exclaimed with a laugh and a taunt: It's just what
we asked for but not what we want." -- Unknown

[Ross Bleakney]

No apology necessary. I just wanted to make sure you realized I agreed. I should have linked to Lombok. I'm not sure I would follow their pattern exactly, but the general idea is great. I think something like this would be fairly simple and make for much more readable code. Unlike a lot of new additions, I don't think you would have to jump through hoops to get things to work. It would be like enums -- not that big of a deal, nothing too fancy, but no harm, either. And if you write a lot of beans, it would make your code a lot easier to read.

Thanks,
Ross

To: seajug-***@public.gmane.org
From: dms-WAiJhE/vqclWk0Htik3J/***@public.gmane.org
Date: Tue, 8 Apr 2014 18:23:09 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler


























Sorry, Ross - I, at least, didn't know
the specifics of what Lombok was doing until Paul gave the
example.



- Dennis



On 04/08/2014 05:04 PM, Ross Bleakney wrote:






Maybe my original and followup message got chopped

Post by Ross Bleakney
Maybe something similar to Lombok (but built into the

language so you don't have to jump through hoops to get it to
work)?



and later ...

Post by Ross Bleakney
This is why I'm surprised that the Java folks didn't

add something like Lombok. I know I could just use it, but it
hardly like using a Jakarta library. It messes with the
compilation. Not all IDEs support it. I have enough trouble
getting Eclipse working with ...



Ross




To: seajug-***@public.gmane.org

From: dms-WAiJhE/vqclWk0Htik3J/***@public.gmane.org

Date: Tue, 8 Apr 2014 15:26:07 +1200

Subject: Re: [seajug] Shorter property etc. definitions Was:
Lambda puzzler







That's the problem I see with
doing this outside the compiler. It really needs to be part
of the Java language definition, and should have been since
1.5 - it's probably the strongest use case for an annotation
I've ever seen.



- Dennis



On 04/08/2014 02:29 PM, George Smith wrote:





Paul,



In the presentation I saw, one of the questions /
complaints I heard was that since the IDE (in this case
Eclipse) did not know about Lombok, it could not see the
methods, which killed auto-complete and filled eclipse
with errors if you manually referenced them...



George





On Mon, Apr 7, 2014 at 5:05
PM, P.Hill <parehill1-***@public.gmane.org>
wrote:







Interesting project I only saw used this
year:

Lombok

http://projectlombok.org/

Then



@Data

public class Person {

private String firstName;

private String lastName;

}



And tada, you have your bean.



Maybe not perfect on all the trick
annotations the author invented, but
certainly the properties are done well.

For example, if you provide your own
setter/getter, hashcode or toString, it will
NOT complain. It just adds what is missing.



You can also make individual setters/getters
if you don't want them for everything.

http://projectlombok.org/features/index.html



-Paul



p.s. If you think about it, the fact that an
annotation adds code to the class is very
interesting. There is no extra processing
step.



On 4/3/2014 4:20 PM, Jason Osgood wrote:



Hi Ross.





Is

there any syntactic sugar to make
beans easier to write?



Properties, a la C#.






















--

"And the users exclaimed with a laugh and a taunt:
It's just what we asked for but not what we want." --
Unknown

[Stewart Buskirk]

Just to mention that Groovy also offers Lombok-like functionality for generating JavaBean boilerplate automatically from simple field declarations:

http://groovy.codehaus.org/Groovy+Beans

...I use a lot of mixed Groovy/Java projects and Groovy-built jars in Java projects, and have never had a problem with the IDE support (IntelliJ).

-Stewart

Post by Ross Bleakney
No apology necessary. I just wanted to make sure you realized I agreed. I should have linked to Lombok. I'm not sure I would follow their pattern exactly, but the general idea is great. I think something like this would be fairly simple and make for much more readable code. Unlike a lot of new additions, I don't think you would have to jump through hoops to get things to work. It would be like enums -- not that big of a deal, nothing too fancy, but no harm, either. And if you write a lot of beans, it would make your code a lot easier to read.
Thanks,
Ross
Date: Tue, 8 Apr 2014 18:23:09 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
Sorry, Ross - I, at least, didn't know the specifics of what Lombok was doing until Paul gave the example.
- Dennis

Post by Ross Bleakney
Maybe something similar to Lombok (but built into the language so you don't have to jump through hoops to get it to work)?

and later ...

Post by Ross Bleakney
This is why I'm surprised that the Java folks didn't add something like Lombok. I know I could just use it, but it hardly like using a Jakarta library. It messes with the compilation. Not all IDEs support it. I have enough trouble getting Eclipse working with ...

Ross
Date: Tue, 8 Apr 2014 15:26:07 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
That's the problem I see with doing this outside the compiler. It really needs to be part of the Java language definition, and should have been since 1.5 - it's probably the strongest use case for an annotation I've ever seen.
- Dennis
Paul,
In the presentation I saw, one of the questions / complaints I heard was that since the IDE (in this case Eclipse) did not know about Lombok, it could not see the methods, which killed auto-complete and filled eclipse with errors if you manually referenced them...
George
Lombok
http://projectlombok.org/
Then
@Data
public class Person {
private String firstName;
private String lastName;
}
And tada, you have your bean.
Maybe not perfect on all the trick annotations the author invented, but certainly the properties are done well.
For example, if you provide your own setter/getter, hashcode or toString, it will NOT complain. It just adds what is missing.
You can also make individual setters/getters if you don't want them for everything.
http://projectlombok.org/features/index.html
-Paul
p.s. If you think about it, the fact that an annotation adds code to the class is very interesting. There is no extra processing step.
Hi Ross.
Is there any syntactic sugar to make beans easier to write?
Properties, a la C#.
--
"And the users exclaimed with a laugh and a taunt: It's just what we asked for but not what we want." -- Unknown

[Konstantin Ignatyev]

So far I observe that pretty much everything folks are asking to be added
to Java has been part of Scala for many years. And IDEs understand Scala
syntax pretty well these days. Scala bean definition

case class Car( makeName:String, modelName:String, color:Color = Red)

or to make it Java bean too we need extra annotation

class Car( @BeanProperty makeName:String, @BeanProperty
modelName:String, @BeanProperty color:Color = Red)

I have started using Scala as Java+++ and was very very happy for long
while just by writing my code in Scala and utilizing all the usual Java
libraries, then I started using some of functional aspects. Problem with
Scala community is that most loud voices are from 'academics' who create
impression that it is necessary to do everything "the Scala way". Not
really necessary.

I think that migration to Scala and discipline to use it as Java+++ much
better alternative to Java extension.

JVM is the biggest asset and it is time to leave Java language behind for
more advanced projects.

I mentioned that before, if there is interest I can give talk about Scala
as Java+++ and show how I use it for my pet project with stack like this:

UI: AngularJS + Wicket
BL: Scala + Spring
DE: MongoDB

Post by Ross Bleakney
No apology necessary. I just wanted to make sure you realized I agreed. I
should have linked to Lombok. I'm not sure I would follow their pattern
exactly, but the general idea is great. I think something like this would
be fairly simple and make for much more readable code. Unlike a lot of new
additions, I don't think you would have to jump through hoops to get things
to work. It would be like enums -- not that big of a deal, nothing too
fancy, but no harm, either. And if you write a lot of beans, it would make
your code a lot easier to read.
Thanks,
Ross
------------------------------
Date: Tue, 8 Apr 2014 18:23:09 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
Sorry, Ross - I, at least, didn't know the specifics of what Lombok was
doing until Paul gave the example.
- Dennis
Maybe my original and followup message got chopped off. I mentioned Lombok

Post by Ross Bleakney
Maybe something similar to Lombok (but built into the language so you

don't have to jump through hoops to get it to work)?
and later ...

Post by Ross Bleakney
This is why I'm surprised that the Java folks didn't add something like

Lombok. I know I could just use it, but it hardly like using a Jakarta
library. It messes with the compilation. Not all IDEs support it. I have
enough trouble getting Eclipse working with ...
Ross
------------------------------
Date: Tue, 8 Apr 2014 15:26:07 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
That's the problem I see with doing this outside the compiler. It really
needs to be part of the Java language definition, and should have been
since 1.5 - it's probably the strongest use case for an annotation I've
ever seen.
- Dennis
Paul,
In the presentation I saw, one of the questions / complaints I heard was
that since the IDE (in this case Eclipse) did not know about Lombok, it
could not see the methods, which killed auto-complete and filled eclipse
with errors if you manually referenced them...
George
Lombok
http://projectlombok.org/
Then
@Data
public class Person {
private String firstName;
private String lastName;
}
And tada, you have your bean.
Maybe not perfect on all the trick annotations the author invented, but
certainly the properties are done well.
For example, if you provide your own setter/getter, hashcode or toString,
it will NOT complain. It just adds what is missing.
You can also make individual setters/getters if you don't want them for
everything.
http://projectlombok.org/features/index.html
-Paul
p.s. If you think about it, the fact that an annotation adds code to the
class is very interesting. There is no extra processing step.
Hi Ross.
Is there any syntactic sugar to make beans easier to write?
Properties, a la C#.
--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Joe Bowbeer]

Some of the Scala folks influenced the design of the JDK8 features. Scala
itself will also benefit from some of the new enhancements.

Post by Konstantin Ignatyev
So far I observe that pretty much everything folks are asking to be added
to Java has been part of Scala for many years. And IDEs understand Scala
syntax pretty well these days. Scala bean definition
case class Car( makeName:String, modelName:String, color:Color = Red)
or to make it Java bean too we need extra annotation
I have started using Scala as Java+++ and was very very happy for long
while just by writing my code in Scala and utilizing all the usual Java
libraries, then I started using some of functional aspects. Problem with
Scala community is that most loud voices are from 'academics' who create
impression that it is necessary to do everything "the Scala way". Not
really necessary.
I think that migration to Scala and discipline to use it as Java+++ much
better alternative to Java extension.
JVM is the biggest asset and it is time to leave Java language behind for
more advanced projects.
I mentioned that before, if there is interest I can give talk about Scala
UI: AngularJS + Wicket
BL: Scala + Spring
DE: MongoDB
No apology necessary. I just wanted to make sure you realized I agreed. I
should have linked to Lombok. I'm not sure I would follow their pattern
exactly, but the general idea is great. I think something like this would
be fairly simple and make for much more readable code. Unlike a lot of new
additions, I don't think you would have to jump through hoops to get things
to work. It would be like enums -- not that big of a deal, nothing too
fancy, but no harm, either. And if you write a lot of beans, it would make
your code a lot easier to read.
Thanks,
Ross
------------------------------
Date: Tue, 8 Apr 2014 18:23:09 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
Sorry, Ross - I, at least, didn't know the specifics of what Lombok was
doing until Paul gave the example.
- Dennis
Maybe my original and followup message got chopped off. I mentioned Lombok

Post by Ross Bleakney
Maybe something similar to Lombok (but built into the language so you

don't have to jump through hoops to get it to work)?
and later ...

Post by Ross Bleakney
This is why I'm surprised that the Java folks didn't add something like

Lombok. I know I could just use it, but it hardly like using a Jakarta
library. It messes with the compilation. Not all IDEs support it. I have
enough trouble getting Eclipse working with ...
Ross
------------------------------
Date: Tue, 8 Apr 2014 15:26:07 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
That's the problem I see with doing this outside the compiler. It really
needs to be part of the Java language definition, and should have been
since 1.5 - it's probably the strongest use case for an annotation I've
ever seen.
- Dennis
Paul,
In the presentation I saw, one of the questions / complaints I heard was
that since the IDE (in this case Eclipse) did not know about Lombok, it
could not see the methods, which killed auto-complete and filled eclipse
with errors if you manually referenced them...
George
Lombok
http://projectlombok.org/
Then
@Data
public class Person {
private String firstName;
private String lastName;
}
--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Dennis Sosnoski]

You don't need the @BeanProperty annotations to make Scala case classes
Java beans, it happens automatically. For example, in the code from my
first JVM Concurrency article (https://github.com/dsosnoski/concur1) I
define this Scala class:

case class DistancePair(val distance: Int, val word: Option[String]) {
def this(distance: Int) = this(distance, None)
def this(distance: Int, word: String) = this(distance, Some(word))
}

and then use it as a Java Bean throughout the Java code (which is in
turn driven by the Scala code - it's easy to mix Java and Scala in the
same project). I wouldn't need the curly braces and content at all,
except that I wanted to define constructors so the Java code wouldn't
need to use Option. And not only do you get the bean access methods, you
also get automatic equals(), hashcode(), and toString().

(Hmmm. I don't think the "val" qualifiers on the class parameters
actually do anything, so I should probably drop those)

But +1 on moving to Scala and using it as Java++! :-)

- Dennis

Post by Konstantin Ignatyev
So far I observe that pretty much everything folks are asking to be
added to Java has been part of Scala for many years. And IDEs
understand Scala syntax pretty well these days. Scala bean definition
case class Car( makeName:String, modelName:String, color:Color = Red)
or to make it Java bean too we need extra annotation
I have started using Scala as Java+++ and was very very happy for long
while just by writing my code in Scala and utilizing all the usual
Java libraries, then I started using some of functional aspects.
Problem with Scala community is that most loud voices are from
'academics' who create impression that it is necessary to do
everything "the Scala way". Not really necessary.
I think that migration to Scala and discipline to use it as Java+++
much better alternative to Java extension.
JVM is the biggest asset and it is time to leave Java language behind
for more advanced projects.
I mentioned that before, if there is interest I can give talk about
Scala as Java+++ and show how I use it for my pet project with stack
UI: AngularJS + Wicket
BL: Scala + Spring
DE: MongoDB
On Tue, Apr 8, 2014 at 7:50 AM, Ross Bleakney
No apology necessary. I just wanted to make sure you realized I
agreed. I should have linked to Lombok. I'm not sure I would
follow their pattern exactly, but the general idea is great. I
think something like this would be fairly simple and make for much
more readable code. Unlike a lot of new additions, I don't think
you would have to jump through hoops to get things to work. It
would be like enums -- not that big of a deal, nothing too fancy,
but no harm, either. And if you write a lot of beans, it would
make your code a lot easier to read.
Thanks,
Ross
------------------------------------------------------------------------
Date: Tue, 8 Apr 2014 18:23:09 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
Sorry, Ross - I, at least, didn't know the specifics of what
Lombok was doing until Paul gave the example.
- Dennis
Maybe my original and followup message got chopped off. I

Post by Ross Bleakney
Maybe something similar to Lombok (but built into the

language so you don't have to jump through hoops to get it to
work)?
and later ...

Post by Ross Bleakney
This is why I'm surprised that the Java folks didn't add

something like Lombok. I know I could just use it, but it
hardly like using a Jakarta library. It messes with the
compilation. Not all IDEs support it. I have enough trouble
getting Eclipse working with ...
Ross
------------------------------------------------------------------------
Date: Tue, 8 Apr 2014 15:26:07 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
That's the problem I see with doing this outside the compiler.
It really needs to be part of the Java language definition,
and should have been since 1.5 - it's probably the strongest
use case for an annotation I've ever seen.
- Dennis
Paul,
In the presentation I saw, one of the questions /
complaints I heard was that since the IDE (in this case
Eclipse) did not know about Lombok, it could not see the
methods, which killed auto-complete and filled eclipse
with errors if you manually referenced them...
George
On Mon, Apr 7, 2014 at 5:05 PM, P.Hill
Lombok
http://projectlombok.org/
Then
@Data
public class Person {
private String firstName;
private String lastName;
}
And tada, you have your bean.
Maybe not perfect on all the trick annotations the
author invented, but certainly the properties are done
well.
For example, if you provide your own setter/getter,
hashcode or toString, it will NOT complain. It just
adds what is missing.
You can also make individual setters/getters if you
don't want them for everything.
http://projectlombok.org/features/index.html
-Paul
p.s. If you think about it, the fact that an
annotation adds code to the class is very
interesting. There is no extra processing step.
Hi Ross.
Is there any syntactic sugar to make beans
easier to write?
Properties, a la C#.
--
"And the users exclaimed with a laugh and a taunt: It's
just what we asked for but not what we want." -- Unknown
--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate
between forty to one hundred species, erode seventy-one million tons
of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase
their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement
Needs a Strategy for Reforming Universities and Public Schools. New
York: State University of New York Press, 1997: (4) (5) (p.206)

[Dennis Sosnoski]

Whoops, typed without thinking. Or checking. :-[

First off, the form I used was for the equivalent of an immutable value
object, not a mutable Java Bean. Secondly, the access method Scala
generates by default are of the form dp.distance() and dp.word(), not
the getDistance() and getWord() Java expects. If you use "var" where the
original case class had "val" in the parameter definitions the members
will be mutable, but the set method names will be of the form
dp.distance_$eq(value).

So you do need to use the @BeanProperty annotation on the parameters if
you want something that's recognizable as a Java Bean. But you also need
to use "var" if you want the properties to be mutable.

- Dennis

classes Java beans, it happens automatically. For example, in the code
from my first JVM Concurrency article
case class DistancePair(val distance: Int, val word: Option[String]) {
def this(distance: Int) = this(distance, None)
def this < / span>(distance: Int, word: String) = this(distance,
Some(word))
}
and then use it as a Java Bean throughout the Java code (which is in
turn driven by the Scala code - it's easy to mix Java and Scala in the
same project). I wouldn't need the curly braces and content at all,
except that I wanted to define constructors so the Java code wouldn't
need to use Option. And not only do you get the bean access methods,
you also get automatic equals(), hashcode(), and toString().
(Hmmm. I don't think the "val" qualifiers on the class parameters
actually do anything, so I should probably drop those)
But +1 on moving to Scala and using it as Java++! :-)
- Dennis

Post by Konstantin Ignatyev
So far I observe that pretty much everything folks are asking to be
added to Java has been part of Scala for many years. And IDEs
understand Scala syntax pretty well these days. Scala bean definition
case class Car( makeName:String, modelName:String, color:Color = Red)
or to make it Java bean too we need extra annotation
I have started using Scala as Java+++ and was very very happy for
long while just by writing my code in Scala and utilizing all the
usual Java libraries, then I started using some of functional
aspects. Problem with Scala community is that most loud voices are
from 'academics' who create impression that it is necessary to do
everything "the Scala way". Not really necessary.
I think that migration to Scala and discipline to use it as Java+++
much better alternative to Java extension.
JVM is the biggest asset and it is time to leave Java language behind
for more advanced projects.
I mentioned that before, if there is interest I can give talk about
Scala as Java+++ and show how I use it for my pet project with stack
UI: AngularJS + Wicket
BL: Scala + Spring
DE: MongoDB
On Tue, Apr 8, 2014 at 7:50 AM, Ross Bleakney
No apology necessary. I just wanted to make sure you realized I
agreed. I should have linked to Lombok. I'm not sure I would
follow their pattern exactly, but the general idea is great. I
think something like this would be fairly simple and make for
much more readable code. Unlike a lot of new additions, I don't
think you would have to jump through hoops to get things to work.
It would be like enums -- not that big of a deal, nothing too
fancy, but no harm, either. And if you write a lot of beans, it
would make your code a lot easier to read.
Thanks,
Ross
------------------------------------------------------------------------
Date: Tue, 8 Apr 2014 18:23:09 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
Sorry, Ross - I, at least, didn't know the specifics of what
Lombok was doing until Paul gave the example.
- Dennis
Maybe my original and followup message got chopped off. I

Post by Ross Bleakney
Maybe something similar to Lombok (but built into the

language so you don't have to jump through hoops to get it to
work)?
and later ...

Post by Ross Bleakney
This is why I'm surprised that the Java folks didn't add

something like Lombok. I know I could just use it, but it
hardly like using a Jakarta library. It messes with the
compilation. Not all IDEs support it. I have enough trouble
getting Eclipse working with ...
Ross
------------------------------------------------------------------------
Date: Tue, 8 Apr 2014 15:26:07 +1200
Lambda puzzler
That's the problem I see with doing this outside the
compiler. It really needs to be part of the Java language
definition, and should have been since 1.5 - it's probably
the strongest use case for an annotation I've ever seen.
- Dennis
Paul,
In the presentation I saw, one of the questions /
complaints I heard was that since the IDE (in this case
Eclipse) did not know about Lombok, it could not see the
methods, which killed auto-complete and filled eclipse
with errors if you manually referenced them...
George
On Mon, Apr 7, 2014 at 5:05 PM, P.Hill
Lombok
http://projectlombok.org/
Then
@Data
public class Person {
private String firstName;
private String lastName;
}
And tada, you have your bean.
Maybe not perfect on all the trick annotations the
author invented, but certainly the properties are
done well.
For example, if you provide your own setter/getter,
hashcode or toString, it will NOT complain. It just
adds what is missing.
You can also make individual setters/getters if you
don't want them for everything.
http://projectlombok.org/features/index.html
-Paul
p.s. If you think about it, the fact that an
annotation adds code to the class is very
interesting. There is no extra processing step.
Hi Ross.
Is there any syntactic sugar to make beans
easier to write?
Properties, a la C#.
--
"And the users exclaimed with a laugh and a taunt: It's
just what we asked for but not what we want." -- Unknown
--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate
between forty to one hundred species, erode seventy-one million tons
of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase
their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement
Needs a Strategy for Reforming Universities and Public Schools. New
York: State University of New York Press, 1997: (4) (5) (p.206)

[Konstantin Ignatyev]

But you also need to use "var" if you want the properties to be mutable.

Yes, forgot about that, so used to help from Intellij ;)

Whoops, typed without thinking. Or checking. :-[
First off, the form I used was for the equivalent of an immutable value
object, not a mutable Java Bean. Secondly, the access method Scala
generates by default are of the form dp.distance() and dp.word(), not the
getDistance() and getWord() Java expects. If you use "var" where the
original case class had "val" in the parameter definitions the members will
be mutable, but the set method names will be of the form
dp.distance_$eq(value).
you want something that's recognizable as a Java Bean. But you also need to
use "var" if you want the properties to be mutable.
- Dennis
Java beans, it happens automatically. For example, in the code from my
first JVM Concurrency article (https://github.com/dsosnoski/concur1) I
case class DistancePair(val distance: Int, val word: Option[String]) {
def this(distance: Int) = this(distance, None)
def thi
s
<
/
span>(distance: Int, word: String) = this(distance, Some(word))
}
and then use it as a Java Bean throughout the Java code (which is in turn
driven by the Scala code - it's easy to mix Java and Scala in the same
project). I wouldn't need the curly braces and content at all, except that
I wanted to define constructors so the Java code wouldn't need to use
Option. And not only do you get the bean access methods, you also get
automatic equals(), hashcode(), and toString().
(Hmmm. I don't think the "val" qualifiers on the class parameters actually
do anything, so I should probably drop those)
But +1 on moving to Scala and using it as Java++! :-)
- Dennis
So far I observe that pretty much everything folks are asking to be added
to Java has been part of Scala for many years. And IDEs understand Scala
syntax pretty well these days. Scala bean definition
case class Car( makeName:String, modelName:String, color:Color = Red)
or to make it Java bean too we need extra annotation
I have started using Scala as Java+++ and was very very happy for long
while just by writing my code in Scala and utilizing all the usual Java
libraries, then I started using some of functional aspects. Problem with
Scala community is that most loud voices are from 'academics' who create
impression that it is necessary to do everything "the Scala way". Not
really necessary.
I think that migration to Scala and discipline to use it as Java+++ much
better alternative to Java extension.
JVM is the biggest asset and it is time to leave Java language behind
for more advanced projects.
I mentioned that before, if there is interest I can give talk about
Scala as Java+++ and show how I use it for my pet project with stack like
UI: AngularJS + Wicket
BL: Scala + Spring
DE: MongoDB

No apology necessary. I just wanted to make sure you realized I agreed.
I should have linked to Lombok. I'm not sure I would follow their pattern
exactly, but the general idea is great. I think something like this would
be fairly simple and make for much more readable code. Unlike a lot of new
additions, I don't think you would have to jump through hoops to get things
to work. It would be like enums -- not that big of a deal, nothing too
fancy, but no harm, either. And if you write a lot of beans, it would make
your code a lot easier to read.
Thanks,
Ross
------------------------------
Date: Tue, 8 Apr 2014 18:23:09 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
Sorry, Ross - I, at least, didn't know the specifics of what Lombok was
doing until Paul gave the example.
- Dennis
Maybe my original and followup message got chopped off. I mentioned

Post by Ross Bleakney
Maybe something similar to Lombok (but built into the language so you

don't have to jump through hoops to get it to work)?
and later ...

Post by Ross Bleakney
This is why I'm surprised that the Java folks didn't add something

like Lombok. I know I could just use it, but it hardly like using a Jakarta
library. It messes with the compilation. Not all IDEs support it. I have
enough trouble getting Eclipse working with ...
Ross
------------------------------
Date: Tue, 8 Apr 2014 15:26:07 +1200
Subject: Re: [seajug] Shorter property etc. definitions Was: Lambda puzzler
That's the problem I see with doing this outside the compiler. It really
needs to be part of the Java language definition, and should have been
since 1.5 - it's probably the strongest use case for an annotation I've
ever seen.
- Dennis
Paul,
In the presentation I saw, one of the questions / complaints I heard
was that since the IDE (in this case Eclipse) did not know about Lombok, it
could not see the methods, which killed auto-complete and filled eclipse
with errors if you manually referenced them...
George
Lombok
http://projectlombok.org/
Then
@Data
public class Person {
private String firstName;
private String lastName;
}
And tada, you have your bean.
Maybe not perfect on all the trick annotations the author invented, but
certainly the properties are done well.
For example, if you provide your own setter/getter, hashcode or toString,
it will NOT complain. It just adds what is missing.
You can also make individual setters/getters if you don't want them for
everything.
http://projectlombok.org/features/index.html
-Paul
p.s. If you think about it, the fact that an annotation adds code to the
class is very interesting. There is no extra processing step.
Hi Ross.
Is there any syntactic sugar to make beans easier to write?
Properties, a la C#.
--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown

--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[P.Hill]

Here is an article on IBM Developer Works discussing how it works and
showing all the generated methods available in the (Eclipse) IDE.
When I was introduced to Lombok the biggest fan of Lombok was an
IntelliJ user, so it works there too (apparently simplier).
I thought it worked like this.
The extra code is generated when the annotation is traversed _during
compilation_. Code completion is based on the class files. Thus no IDE
"support" is required other than to have the jars in the class path.
But I see mention of a little use of Eclipse. The IBM article explains
this as a difference in the annotation processing API and a different
Abstract Syntax Tree in the compiler in Eclipse.

You can probably stop reading the IBM article where the author starts
extending Lombok.

see also
http://stackoverflow.com/questions/6107197/how-does-lombok-work

-Paul

Post by George Smith
Paul,
In the presentation I saw, one of the questions / complaints I heard
was that since the IDE (in this case Eclipse) did not know about
Lombok, it could not see the methods, which killed auto-complete and
filled eclipse with errors if you manually referenced them...
George

[Dennis Sosnoski]

Post by Ross Bleakney
...
I'll admit I haven't followed the new Java features because I doubt we
will use them (I figure I'll learn about them sooner or later). So,
I'm probably way behind (we compile with 1.6 and could probably
Is there any syntactic sugar to make beans easier to write? It seems
to me if you have a simple bean, with a default constructor, you
should be able (in this new, more intuitive, less typing Java
universe) to just specify the fields (as private) and be done with it.
Maybe something similar to Lombok (but built into the language so you
don't have to jump through hoops to get it to work)?

Not as far as I know. I thought from the time of Java 5 that that would
be a great use of an annotation for the compiler - just add @Bean on the
class definition and the compiler would automatically add get/set methods.

But if you're willing to consider moving to Scala, that would take care
of the problem! :-) Here's the Name class in Scala:

class Name(val firstName: String, val lastName: String)

- Dennis

Post by Ross Bleakney
Thanks,
Ross
------------------------------------------------------------------------
Date: Thu, 3 Apr 2014 07:50:49 -0700
Subject: Re: [seajug] Lambda puzzler
Comparator<Name> c =
Comparator.comparing(Name::lastName).thenComparing(Name::firstName);
public class Name {
private final String firstName;
private final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
public String firstName() { return firstName; }
public String lastName() { return lastName; }
}
I've run into an interesting issue in the code for an upcoming article.
public class Name {
public final String firstName;
public final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
...
}
Comparator<Name> comp = Comparator.comparing(name ->
name.lastName);
comp = comp.thenComparing(name -> name.firstName);
But this gives compile errors (and errors on the "name" symbol), even if
Comparator<Name> comp = Comparator.comparing(name1 ->
name1.lastName)
.thenComparing(name2 -> name2.firstName);
I'm wondering if it's a compiler bug, or just somehow a consequence of
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing
Any thoughts?
- Dennis
------------------------------------
Yahoo Groups Links

[Ross Bleakney]

That's what I thought. Thanks for the info.

It is a shame, really. Like I said, I really like the code shown below (repeated here, for convenience):

Comparator<Name> c =
Comparator.comparing(Name::lastName).thenComparing(Name::firstName);

Rather obvious, really. There are examples of that sort of thing with generics, too. Instead of

public List getNames()

you have

public List<String> getNames()

A lot of value added there. But as we all know (many of us the hard way) we sometimes paid a price for generics. There have been plenty of unusual cases that make generics a pain in the butt sometimes. It's a double edged sword, not unlike Lambda. Except Lambda (in my opinion) puts a little too much pressure on the developer. It reminds me of templates in C++. I was as guilty as anyone back in the day, writing code that was oh so elegant using pointy brackets till the cows came home. I got carried away and it wasn't good. Likewise with Lambda, the developer has to sometime back off and say "OK, that is pretty nifty, but someone else won't be able to understand it". Sometimes, if it is in isolation, then it is just fine (especially if it is supported with really good unit test code). But in the middle of a complex block? Please don't.

Meanwhile, my favorite addition for 1.5 was enums. They aren't used that often, but when they are, they are clearly better than the alternative. The big advantage is that they never make things worse (unlike generics).

This is why I'm surprised that the Java folks didn't add something like Lombok. I know I could just use it, but it hardly like using a Jakarta library. It messes with the compilation. Not all IDEs support it. I have enough trouble getting Eclipse working with Maven and Jenkins and all the other utilities that are supposed to make my life really easy -- I don't want to add another wildcard to the mix. This is why I don't understand why they didn't make something like Lombok a standard. If you read the intro, it is obvious why it is much easier to read. If I look at a big bean, the first thing I wonder is whether the whole thing is just a bean. In other words, does every field have a public getter and setter? Quite often the answer is yes. One annotation at the top should do it. If a field does not have a public getter or setter, then that field can override that behavior by stating so (with its own annotation). Pretty simple. Like enums.

Furthermore, it isn't like beans are some obscure part of Java. It is the standard way of working with the standard markup language (JSP) for the World Wide Web. That's kind of a big deal. You would think they would work really hard to make that easy. I know the IDEs do a lot of the work for you, and I know that there are plenty of other languages out there, but if they are mucking with Java, why not add something simple like this that is so obviously a net gain?

Rant over.

Thanks,
Ross

To: seajug-***@public.gmane.org
From: dms-WAiJhE/vqclWk0Htik3J/***@public.gmane.org
Date: Fri, 4 Apr 2014 12:17:10 +1300
Subject: Re: [seajug] Lambda puzzler


























On 04/04/2014 12:02 PM, Ross Bleakney
wrote:









...



I'll admit I haven't followed the new Java features because
I doubt we will use them (I figure I'll learn about them
sooner or later). So, I'm probably way behind (we compile
with 1.6 and could probably compile with 1.5). Keep that in
mind while I ask the following:



Is there any syntactic sugar to make beans easier to write?
It seems to me if you have a simple bean, with a default
constructor, you should be able (in this new, more
intuitive, less typing Java universe) to just specify the
fields (as private) and be done with it. Maybe something
similar to Lombok (but built into the language so you don't
have to jump through hoops to get it to work)?







Not as far as I know. I thought from the time of Java 5 that that
would be a great use of an annotation for the compiler - just add
@Bean on the class definition and the compiler would automatically
add get/set methods.



But if you're willing to consider moving to Scala, that would take
care of the problem! :-)
Here's the Name class in Scala:



class Name(val firstName: String, val lastName: String)



- Dennis








Thanks,

Ross


To: seajug-***@public.gmane.org

From: joe.bowbeer-***@public.gmane.org

Date: Thu, 3 Apr 2014 07:50:49 -0700

Subject: Re: [seajug] Lambda puzzler










If you add accessor methods to Name then you can
express it as:



Comparator<Name> c =
Comparator.comparing(Name::lastName).thenComparing(Name::firstName);







public class Name {



private final String firstName;
private final String lastName;



public Name(String first, String last) {


firstName = first;
lastName = last;
}
public String firstName() { return
firstName; }
public String lastName() { return
lastName; }
}









On Wed, Apr 2, 2014 at 9:52
PM, Dennis Sosnoski <dms-WAiJhE/vqclWk0Htik3J/***@public.gmane.org>
wrote:

I've
run into an interesting issue in the code for an
upcoming article.

This works:



public class Name {

public final String firstName;

public final String lastName;



public Name(String first, String last) {

firstName = first;

lastName = last;

}

...

}



Comparator<Name> comp =
Comparator.comparing(name ->

name.lastName);

comp = comp.thenComparing(name ->
name.firstName);



But this gives compile errors (and errors on the
"name" symbol), even if

I use a cast on the second lambda:



Comparator<Name> comp =
Comparator.comparing(name1 ->

name1.lastName)

.thenComparing(name2 ->
name2.firstName);



I'm wondering if it's a compiler bug, or just
somehow a consequence of

the lambda target typing rules:

http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing

Any thoughts?



- Dennis







------------------------------------



Yahoo Groups Links



http://groups.yahoo.com/group/seajug/



Individual Email | Traditional



http://groups.yahoo.com/group/seajug/join

(Yahoo! ID required)



seajug-digest-***@public.gmane.org

seajug-fullfeatured-***@public.gmane.org



seajug-unsubscribe-***@public.gmane.org



https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Stuart Maclean]

"Fewer lines does not always mean better code..."

Never a truer word said. Why are people so obsessed with token/line
counts? It's how well the code works in the long run, at runtime, and
how well the current composition of it is amenable to future
requirements that matter, not how cool is it is that I can write
Fibonacci in half a line. Looking back through my body of professional
code written in say 15 years I can't locate Fibonacci anywhere (it must
be hiding with factorial and queens).

For me, Java's sweet spot was/is 1.5. Generics are a real improvement,
code is safer and more robust. Things since have been fluff. When I
saw auto-close in 1.7, I thought it was an April fool ;)

Stuart



------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Eric Jain]

On Fri, Apr 4, 2014 at 9:47 AM, Stuart Maclean

Post by Stuart Maclean
Never a truer word said. Why are people so obsessed with token/line
counts?

Look-mom-no-hands syndrome.
--
Eric Jain
Got data? Get answers at zenobase.com.


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Joe Bowbeer]

Effective utilization of multiprocessors is one of the requirements that
the designers of the JDK8 features were trying to achieve. This leads to a
functional (side effect free) style of programming, which lends itself to
clever one-line solutions.

For me, the sweet-spot of syntax vs. expressiveness was 1.2. But I'm glad
that the Java designers have been taking their position of leadership
seriously, and trying to evolve the language as best they can - without the
benefit of hindsight that they had initially.

Post by Stuart Maclean
"Fewer lines does not always mean better code..."
Never a truer word said. Why are people so obsessed with token/line
counts? It's how well the code works in the long run, at runtime, and
how well the current composition of it is amenable to future
requirements that matter, not how cool is it is that I can write
Fibonacci in half a line. Looking back through my body of professional
code written in say 15 years I can't locate Fibonacci anywhere (it must
be hiding with factorial and queens).
For me, Java's sweet spot was/is 1.5. Generics are a real improvement,
code is safer and more robust. Things since have been fluff. When I
saw auto-close in 1.7, I thought it was an April fool ;)
Stuart
------------------------------------
Yahoo Groups Links

[Dennis Sosnoski]

Agree with you completely (including on 1.2). I think there has been
some flaky decision making lately, such as with the change from
String.substring() using the same backing array as the original String
to making a copy in a minor point release with not even an announcement
(all due to design flaws in the web server no one uses, Glassfish), but
considering it's now owned by Oracle things are working out better than
my (very, very, low) expectations.

Wish they'd put more attention on making the VM more usable by other
languages, though.

The Java 8 parallel stream implementation really does deliver very good
performance. I'll link when my article is published that covers this.

- Dennis

Post by Joe Bowbeer
Effective utilization of multiprocessors is one of the requirements
that the designers of the JDK8 features were trying to achieve. This
leads to a functional (side effect free) style of programming, which
lends itself to clever one-line solutions.
For me, the sweet-spot of syntax vs. expressiveness was 1.2. But I'm
glad that the Java designers have been taking their position of
leadership seriously, and trying to evolve the language as best they
can - without the benefit of hindsight that they had initially.
"Fewer lines does not always mean better code..."
Never a truer word said. Why are people so obsessed with token/line
counts? It's how well the code works in the long run, at runtime, and
how well the current composition of it is amenable to future
requirements that matter, not how cool is it is that I can write
Fibonacci in half a line. Looking back through my body of
professional
code written in say 15 years I can't locate Fibonacci anywhere (it must
be hiding with factorial and queens).
For me, Java's sweet spot was/is 1.5. Generics are a real
improvement,
code is safer and more robust. Things since have been fluff. When I
saw auto-close in 1.7, I thought it was an April fool ;)
Stuart
------------------------------------
Yahoo Groups Links

[Konstantin Ignatyev]

I am obsessed with readability and maintainability of code and fewer lines
improve those characteristics of code (up to a point of course).

That is why I use Scala. Java has too much ceremony that obscures intent of
code and makes it harder to do 'right' thing.

I am not sure though that Java as a language can be bent into a more modern
language without bringing a lot of confusion and compromises.

Post by Stuart Maclean
"Fewer lines does not always mean better code..."
Never a truer word said. Why are people so obsessed with token/line
counts? It's how well the code works in the long run, at runtime, and
how well the current composition of it is amenable to future
requirements that matter, not how cool is it is that I can write
Fibonacci in half a line. Looking back through my body of professional
code written in say 15 years I can't locate Fibonacci anywhere (it must
be hiding with factorial and queens).
For me, Java's sweet spot was/is 1.5. Generics are a real improvement,
code is safer and more robust. Things since have been fluff. When I
saw auto-close in 1.7, I thought it was an April fool ;)
Stuart

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Jason Osgood]

Hi Konstantin.

I am not sure though that Java as a language can be bent into a more modern language without bringing a lot of confusion and compromises.

I am deeply influenced by Scott McCloud’s The Big Triangle, where he tries to scope the space of graphic styles.

http://scottmccloud.com/4-inventions/triangle/index.html

(I’ve mentioned this before.)

There are similar dynamic constraints in many other domains. e.g. Project Management: Time, Resources, Scope - pick two.

The axes (triangles, ranges) I think about for programming language design:

Style: Imperative vs Functional vs Declarative

Type System: Dynamic vs Static

Organization: Prototype vs Class

Production: Cut & Paste (Boiler Plate) vs Metaprogramming vs Code generation


Adding functional (lambdas) and declarative (annotations, LINQ) elements to an imperative language like Java is not progress. It’s just moving the needle to a new target in the Style triangle.

I like Java as an imperative language. It’s pretty good.

If I wanted functional, I’d likely choose Clojure.

I have no interest in a mutant hybrid language. I would not choose Kotlin, Groovy, Ruby, Python, Xtend, Scala, or whatever effort to synthesize a best of breed programming language.



Oak/Java’s original contributions were class loader, threads, GC, awesome standard library (for the time), JVM, etc.

If the Oak/Java project were to get a reboot today, with the same principles, we’d add null safety, lightweight objects, the other things I mentioned upthread, maybe some other stuff. And remove all the silly non-imperative stuff. To better reduce the cost of producing and maintaining mainstream software.


Cheers, Jason

[Joe Bowbeer]

If Java were rebooted today then Frank Yellin would not attend the opera
and would spend the extra few hours optimizing the java .class file format
instead.

Post by Jason Osgood
Hi Konstantin.
I am not sure though that Java as a language can be bent into a more
modern language without bringing a lot of confusion and compromises.
I am deeply influenced by Scott McCloud's The Big Triangle, where he tries
to scope the space of graphic styles.
http://scottmccloud.com/4-inventions/triangle/index.html
(I've mentioned this before.)
There are similar dynamic constraints in many other domains. e.g. Project
Management: Time, Resources, Scope - pick two.
Style: Imperative vs Functional vs Declarative
Type System: Dynamic vs Static
Organization: Prototype vs Class
Production: Cut & Paste (Boiler Plate) vs Metaprogramming vs Code generation
Adding functional (lambdas) and declarative (annotations, LINQ) elements
to an imperative language like Java is not progress. It's just moving the
needle to a new target in the Style triangle.
I like Java as an imperative language. It's pretty good.
If I wanted functional, I'd likely choose Clojure.
I have no interest in a mutant hybrid language. I would not choose Kotlin,
Groovy, Ruby, Python, Xtend, Scala, or whatever effort to synthesize a best
of breed programming language.
Oak/Java's original contributions were class loader, threads, GC, awesome
standard library (for the time), JVM, etc.
If the Oak/Java project were to get a reboot today, with the same
principles, we'd add null safety, lightweight objects, the other things I
mentioned upthread, maybe some other stuff. And remove all the silly
non-imperative stuff. To better reduce the cost of producing and
maintaining mainstream software.
Cheers, Jason

[Joe Bowbeer]

According to Brian Goetz:

"This is a known limitation of type inference. The problem is that the
receiver -- in this case 'Comparator.comparing(...)'-- is a generic method
that needs to get its type information from target type, but receviers are
not poly expressions.

The solution is to give it more type information, but you don't need as big
a hammer as casting -- just make the first lambda explicit:

(Name name1) -> name1.lastName()

Now it has enough type info to infer T in the first expression, and that's
enough to pass it down the rest of the chain.

Method refs are preferred here because you're referring to a method that
already exists by name, rather than constructing a lambda that just calls
an existing method."

Post by Dennis Sosnoski
I've run into an interesting issue in the code for an upcoming article.
public class Name {
public final String firstName;
public final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
...
}
Comparator<Name> comp = Comparator.comparing(name ->
name.lastName);
comp = comp.thenComparing(name -> name.firstName);
But this gives compile errors (and errors on the "name" symbol), even if
Comparator<Name> comp = Comparator.comparing(name1 ->
name1.lastName)
.thenComparing(name2 -> name2.firstName);
I'm wondering if it's a compiler bug, or just somehow a consequence of
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing
Any thoughts?
- Dennis
------------------------------------
Yahoo Groups Links

[Dennis Sosnoski]

To me, the strangest part of this is that the compiler won't accept a
cast. That may be an overly large hammer for the problem, but why won't
it work?

That said, I gather what is actually going on is that the left side of
the assignment is used to determine the type for the right side:

Comparator<Name> comp = Comparator.comparing(name -> name.lastName);

That seems backward to me, but I guess it matches how Java's "type
inference" works with generics.

Thanks for following up on this, Joe.

- Dennis

Post by Joe Bowbeer
"This is a known limitation of type inference. The problem is that
the receiver -- in this case 'Comparator.comparing(...)'-- is a
generic method that needs to get its type information from target
type, but receviers are not poly expressions.
The solution is to give it more type information, but you don't need
(Name name1) -> name1.lastName()
Now it has enough type info to infer T in the first expression, and
that's enough to pass it down the rest of the chain.
Method refs are preferred here because you're referring to a method
that already exists by name, rather than constructing a lambda that
just calls an existing method."
I've run into an interesting issue in the code for an upcoming article.
public class Name {
public final String firstName;
public final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
...
}
Comparator<Name> comp = Comparator.comparing(name ->
name.lastName);
comp = comp.thenComparing(name -> name.firstName);
But this gives compile errors (and errors on the "name" symbol), even if
Comparator<Name> comp = Comparator.comparing(name1 ->
name1.lastName)
.thenComparing(name2 -> name2.firstName);
I'm wondering if it's a compiler bug, or just somehow a consequence of
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing
Any thoughts?
- Dennis
------------------------------------
Yahoo Groups Links

[Dennis Sosnoski]

Paul Sandoz showed yet another way of making this work, using a type
signature on the static method:

Comparator<Name> com2 = Comparator.<Name,String>comparing(name1
-> name1.lastName)
.thenComparing(name2 -> name2.firstName);

Looks strange (at least to me), but again works!

- Dennis

Post by Dennis Sosnoski
To me, the strangest part of this is that the compiler won't accept a
cast. That may be an overly large hammer for the problem, but why
won't it work?
That said, I gather what is actually going on is that the left side of
Comparator<Name> comp = Comparator.comparing(name -> name.lastName);
That seems backward to me, but I guess it matches how Java's "type
inference" works with generics.
Thanks for following up on this, Joe.
- Dennis

Post by Joe Bowbeer
"This is a known limitation of type inference. The problem is that
the receiver -- in this case 'Comparator.comparing(...)'-- is a
generic method that needs to get its type information from target
type, but receviers are not poly expressions.
The solution is to give it more type information, but you don't need
(Name name1) -> name1.lastName()
Now it has enough type info to infer T in the first expression, and
that's enough to pass it down the rest of the chain.
Method refs are preferred here because you're referring to a method
that already exists by name, rather than constructing a lambda that
just calls an existing method."
I've run into an interesting issue in the code for an upcoming article.
public class Name {
public final String firstName;
public final String lastName;
public Name(String first, String last) {
firstName = first;
lastName = last;
}
...
}
Comparator<Name> comp = Comparator.comparing(name -> name.lastName);
comp = comp.thenComparing(name -> name.firstName);
But this gives compile errors (and errors on the "name" symbol), even if
Comparator<Name> comp = Comparator.comparing(name1 ->
name1.lastName)
.thenComparing(name2 -> name2.firstName);
I'm wondering if it's a compiler bug, or just somehow a
consequence of
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#target-typing
Any thoughts?
- Dennis
------------------------------------
Yahoo Groups Links