Printing the letters from A to Z using a Java stream
I have this code, but it gives me an error:
Type mismatch: cannot convert from int to Character
Stream.iterate('a', i -> i + 1).limit(26).forEach(System.out::println);
Although it is fine to write int i = 'a';
I know I can write it like this, but that seems like too much code for a simple task.
Stream.iterate('a', i -> (char)(i + 1)).limit(26).forEach(System.out::println);
Why is the Java type inference failing?
java java-8 char java-stream
edited 2 days ago
Peter Mortensen
13.5k1983111
asked Dec 27 at 21:41
fastcodejava
23.9k19109162
add a comment |
I have this code, but it gives me an error:
Type mismatch: cannot convert from int to Character
Stream.iterate('a', i -> i + 1).limit(26).forEach(System.out::println);
Although it is fine to write int i = 'a';
I know I can write it like this, but that seems like too much code for a simple task.
Stream.iterate('a', i -> (char)(i + 1)).limit(26).forEach(System.out::println);
Why is the Java type inference failing?
java java-8 char java-stream
edited 2 days ago
Peter Mortensen
13.5k1983111
asked Dec 27 at 21:41
fastcodejava
23.9k19109162
5
Related stackoverflow.com/a/32424763/1746118
– nullpointer
2 days ago
add a comment |
I have this code, but it gives me an error:
Type mismatch: cannot convert from int to Character
Stream.iterate('a', i -> i + 1).limit(26).forEach(System.out::println);
Although it is fine to write int i = 'a';
I know I can write it like this, but that seems like too much code for a simple task.
Stream.iterate('a', i -> (char)(i + 1)).limit(26).forEach(System.out::println);
Why is the Java type inference failing?
java java-8 char java-stream
edited 2 days ago
Peter Mortensen
13.5k1983111
asked Dec 27 at 21:41
fastcodejava
23.9k19109162
I have this code, but it gives me an error:
Type mismatch: cannot convert from int to Character
Stream.iterate('a', i -> i + 1).limit(26).forEach(System.out::println);
Although it is fine to write int i = 'a';
I know I can write it like this, but that seems like too much code for a simple task.
Stream.iterate('a', i -> (char)(i + 1)).limit(26).forEach(System.out::println);
Why is the Java type inference failing?
java java-8 char java-stream
java java-8 char java-stream
edited 2 days ago
Peter Mortensen
13.5k1983111
asked Dec 27 at 21:41
fastcodejava
23.9k19109162
edited 2 days ago
Peter Mortensen
13.5k1983111
asked Dec 27 at 21:41
fastcodejava
23.9k19109162
edited 2 days ago
Peter Mortensen
13.5k1983111
edited 2 days ago
Peter Mortensen
13.5k1983111
edited 2 days ago
Peter Mortensen
13.5k1983111
13.5k1983111
asked Dec 27 at 21:41
fastcodejava
23.9k19109162
asked Dec 27 at 21:41
fastcodejava
23.9k19109162
asked Dec 27 at 21:41
fastcodejava
23.9k19109162
23.9k19109162
5
Related stackoverflow.com/a/32424763/1746118
– nullpointer
2 days ago
add a comment |
5
Related stackoverflow.com/a/32424763/1746118
– nullpointer
2 days ago
5
5
Related stackoverflow.com/a/32424763/1746118
– nullpointer
2 days ago
Related stackoverflow.com/a/32424763/1746118
– nullpointer
2 days ago
add a comment |
2 Answers
2
active
oldest
votes
The reason why i -> i + 1 does not compile is because you're attempting to implicitly convert an int to a Character which the compiler cannot do itself alone.
In other words, you can think of Stream.iterate('a', i -> i + 1) as:
Stream.iterate('a', (Character i) -> {
int i1 = i + 1;
return i1; // not possible
});
As you have noted, explicitly casting to char solves it:
Stream.iterate('a', i -> (char)(i + 1))...
Btw this is better done as:
IntStream.rangeClosed('a', 'z').forEach(c -> System.out.println((char)c));
This is better because:
- No boxing overhead thus more efficient
- if you were to stop at say letter
hwith the use ofiterateyou'd have to do more brain processing than just enteringhas the upper bound withrangeClosedbecause you'd need to find the number to truncate the infinite stream upon. - Along with the boxing
iterategenerates an infinite stream which in this specific case has more overhead than the finite one withrangeClosed. Further, it's far easier to runIntStream.rangeClosedin parallel, not that you want to in this specific case but it's something to keep in mind. here is some discussion on Generators as sources by Brian Goetz.
etc...
answered Dec 27 at 21:42
Aomine
39.4k73669
"iterate generates an infinite stream which again has more overhead than a finite one." why's that?
– Alexander
2 days ago
@Alexander Firstly, I will improve my wording as it may not be the best to remove ambiguity. Thanks. I have also included a reference to a blog which might be of interest.
– Aomine
2 days ago
2
"an infinite stream which in this specific case has more overhead than the finite one with" that's better :) Good callout on the split performance of this.
– Alexander
yesterday
add a comment |
How about just:
Stream.iterate('a', i -> ++i).limit(26).forEach(System.out::println);
i -> i + 1 does not work because i is a Character and i + 1 causes an implicit narrowing conversion (JLS 5.1.3), which is not allowed. You can explicitly cast it as was shown. However ++i works because (From JLS 15.15.1):
Before the addition, binary numeric promotion (§5.6.2) is performed on the value 1 and the value of the variable. If necessary, the sum is narrowed by a narrowing primitive conversion (§5.1.3) and/or subjected to boxing conversion (§5.1.7) to the type of the variable before it is stored.
The ++ operator takes care of the narrowing conversion without us having to explicitly cast it
answered Dec 27 at 21:47
GBlodgett
9,21641633
1
Good answer, would have been even better if you explain why++iworks andi + idoesn't.
– fastcodejava
2 days ago
1
and much better if you could also answer Why is the Java type inference is failing part specifically :)
– nullpointer
2 days ago
1
@fastcodejava I have edited my answer to try to explain.
– GBlodgett
2 days ago
3
1 👏🏻 for awesome explanation @GBlodgett
– Deadpool
2 days ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53951142%2fprinting-the-letters-from-a-to-z-using-a-java-stream%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The reason why i -> i + 1 does not compile is because you're attempting to implicitly convert an int to a Character which the compiler cannot do itself alone.
In other words, you can think of Stream.iterate('a', i -> i + 1) as:
Stream.iterate('a', (Character i) -> {
int i1 = i + 1;
return i1; // not possible
});
As you have noted, explicitly casting to char solves it:
Stream.iterate('a', i -> (char)(i + 1))...
Btw this is better done as:
IntStream.rangeClosed('a', 'z').forEach(c -> System.out.println((char)c));
This is better because:
- No boxing overhead thus more efficient
- if you were to stop at say letter
hwith the use ofiterateyou'd have to do more brain processing than just enteringhas the upper bound withrangeClosedbecause you'd need to find the number to truncate the infinite stream upon. - Along with the boxing
iterategenerates an infinite stream which in this specific case has more overhead than the finite one withrangeClosed. Further, it's far easier to runIntStream.rangeClosedin parallel, not that you want to in this specific case but it's something to keep in mind. here is some discussion on Generators as sources by Brian Goetz.
etc...
answered Dec 27 at 21:42
Aomine
39.4k73669
"iterate generates an infinite stream which again has more overhead than a finite one." why's that?
– Alexander
2 days ago
@Alexander Firstly, I will improve my wording as it may not be the best to remove ambiguity. Thanks. I have also included a reference to a blog which might be of interest.
– Aomine
2 days ago
2
"an infinite stream which in this specific case has more overhead than the finite one with" that's better :) Good callout on the split performance of this.
– Alexander
yesterday
add a comment |
The reason why i -> i + 1 does not compile is because you're attempting to implicitly convert an int to a Character which the compiler cannot do itself alone.
In other words, you can think of Stream.iterate('a', i -> i + 1) as:
Stream.iterate('a', (Character i) -> {
int i1 = i + 1;
return i1; // not possible
});
As you have noted, explicitly casting to char solves it:
Stream.iterate('a', i -> (char)(i + 1))...
Btw this is better done as:
IntStream.rangeClosed('a', 'z').forEach(c -> System.out.println((char)c));
This is better because:
- No boxing overhead thus more efficient
- if you were to stop at say letter
hwith the use ofiterateyou'd have to do more brain processing than just enteringhas the upper bound withrangeClosedbecause you'd need to find the number to truncate the infinite stream upon. - Along with the boxing
iterategenerates an infinite stream which in this specific case has more overhead than the finite one withrangeClosed. Further, it's far easier to runIntStream.rangeClosedin parallel, not that you want to in this specific case but it's something to keep in mind. here is some discussion on Generators as sources by Brian Goetz.
etc...
answered Dec 27 at 21:42
Aomine
39.4k73669
"iterate generates an infinite stream which again has more overhead than a finite one." why's that?
– Alexander
2 days ago
@Alexander Firstly, I will improve my wording as it may not be the best to remove ambiguity. Thanks. I have also included a reference to a blog which might be of interest.
– Aomine
2 days ago
2
"an infinite stream which in this specific case has more overhead than the finite one with" that's better :) Good callout on the split performance of this.
– Alexander
yesterday
add a comment |
The reason why i -> i + 1 does not compile is because you're attempting to implicitly convert an int to a Character which the compiler cannot do itself alone.
In other words, you can think of Stream.iterate('a', i -> i + 1) as:
Stream.iterate('a', (Character i) -> {
int i1 = i + 1;
return i1; // not possible
});
As you have noted, explicitly casting to char solves it:
Stream.iterate('a', i -> (char)(i + 1))...
Btw this is better done as:
IntStream.rangeClosed('a', 'z').forEach(c -> System.out.println((char)c));
This is better because:
- No boxing overhead thus more efficient
- if you were to stop at say letter
hwith the use ofiterateyou'd have to do more brain processing than just enteringhas the upper bound withrangeClosedbecause you'd need to find the number to truncate the infinite stream upon. - Along with the boxing
iterategenerates an infinite stream which in this specific case has more overhead than the finite one withrangeClosed. Further, it's far easier to runIntStream.rangeClosedin parallel, not that you want to in this specific case but it's something to keep in mind. here is some discussion on Generators as sources by Brian Goetz.
etc...
answered Dec 27 at 21:42
Aomine
39.4k73669
The reason why i -> i + 1 does not compile is because you're attempting to implicitly convert an int to a Character which the compiler cannot do itself alone.
In other words, you can think of Stream.iterate('a', i -> i + 1) as:
Stream.iterate('a', (Character i) -> {
int i1 = i + 1;
return i1; // not possible
});
As you have noted, explicitly casting to char solves it:
Stream.iterate('a', i -> (char)(i + 1))...
Btw this is better done as:
IntStream.rangeClosed('a', 'z').forEach(c -> System.out.println((char)c));
This is better because:
- No boxing overhead thus more efficient
- if you were to stop at say letter
hwith the use ofiterateyou'd have to do more brain processing than just enteringhas the upper bound withrangeClosedbecause you'd need to find the number to truncate the infinite stream upon. - Along with the boxing
iterategenerates an infinite stream which in this specific case has more overhead than the finite one withrangeClosed. Further, it's far easier to runIntStream.rangeClosedin parallel, not that you want to in this specific case but it's something to keep in mind. here is some discussion on Generators as sources by Brian Goetz.
etc...
answered Dec 27 at 21:42
Aomine
39.4k73669
edited 2 days ago
answered Dec 27 at 21:42
Aomine
39.4k73669
answered Dec 27 at 21:42
Aomine
39.4k73669
answered Dec 27 at 21:42
Aomine
39.4k73669
39.4k73669
"iterate generates an infinite stream which again has more overhead than a finite one." why's that?
– Alexander
2 days ago
@Alexander Firstly, I will improve my wording as it may not be the best to remove ambiguity. Thanks. I have also included a reference to a blog which might be of interest.
– Aomine
2 days ago
2
"an infinite stream which in this specific case has more overhead than the finite one with" that's better :) Good callout on the split performance of this.
– Alexander
yesterday
add a comment |
"iterate generates an infinite stream which again has more overhead than a finite one." why's that?
– Alexander
2 days ago
@Alexander Firstly, I will improve my wording as it may not be the best to remove ambiguity. Thanks. I have also included a reference to a blog which might be of interest.
– Aomine
2 days ago
2
"an infinite stream which in this specific case has more overhead than the finite one with" that's better :) Good callout on the split performance of this.
– Alexander
yesterday
"iterate generates an infinite stream which again has more overhead than a finite one." why's that?
– Alexander
2 days ago
"iterate generates an infinite stream which again has more overhead than a finite one." why's that?
– Alexander
2 days ago
@Alexander Firstly, I will improve my wording as it may not be the best to remove ambiguity. Thanks. I have also included a reference to a blog which might be of interest.
– Aomine
2 days ago
@Alexander Firstly, I will improve my wording as it may not be the best to remove ambiguity. Thanks. I have also included a reference to a blog which might be of interest.
– Aomine
2 days ago
2
2
"an infinite stream which in this specific case has more overhead than the finite one with" that's better :) Good callout on the split performance of this.
– Alexander
yesterday
"an infinite stream which in this specific case has more overhead than the finite one with" that's better :) Good callout on the split performance of this.
– Alexander
yesterday
add a comment |
How about just:
Stream.iterate('a', i -> ++i).limit(26).forEach(System.out::println);
i -> i + 1 does not work because i is a Character and i + 1 causes an implicit narrowing conversion (JLS 5.1.3), which is not allowed. You can explicitly cast it as was shown. However ++i works because (From JLS 15.15.1):
Before the addition, binary numeric promotion (§5.6.2) is performed on the value 1 and the value of the variable. If necessary, the sum is narrowed by a narrowing primitive conversion (§5.1.3) and/or subjected to boxing conversion (§5.1.7) to the type of the variable before it is stored.
The ++ operator takes care of the narrowing conversion without us having to explicitly cast it
answered Dec 27 at 21:47
GBlodgett
9,21641633
1
Good answer, would have been even better if you explain why++iworks andi + idoesn't.
– fastcodejava
2 days ago
1
and much better if you could also answer Why is the Java type inference is failing part specifically :)
– nullpointer
2 days ago
1
@fastcodejava I have edited my answer to try to explain.
– GBlodgett
2 days ago
3
1 👏🏻 for awesome explanation @GBlodgett
– Deadpool
2 days ago
add a comment |
How about just:
Stream.iterate('a', i -> ++i).limit(26).forEach(System.out::println);
i -> i + 1 does not work because i is a Character and i + 1 causes an implicit narrowing conversion (JLS 5.1.3), which is not allowed. You can explicitly cast it as was shown. However ++i works because (From JLS 15.15.1):
Before the addition, binary numeric promotion (§5.6.2) is performed on the value 1 and the value of the variable. If necessary, the sum is narrowed by a narrowing primitive conversion (§5.1.3) and/or subjected to boxing conversion (§5.1.7) to the type of the variable before it is stored.
The ++ operator takes care of the narrowing conversion without us having to explicitly cast it
answered Dec 27 at 21:47
GBlodgett
9,21641633
1
Good answer, would have been even better if you explain why++iworks andi + idoesn't.
– fastcodejava
2 days ago
1
and much better if you could also answer Why is the Java type inference is failing part specifically :)
– nullpointer
2 days ago
1
@fastcodejava I have edited my answer to try to explain.
– GBlodgett
2 days ago
3
1 👏🏻 for awesome explanation @GBlodgett
– Deadpool
2 days ago
add a comment |
How about just:
Stream.iterate('a', i -> ++i).limit(26).forEach(System.out::println);
i -> i + 1 does not work because i is a Character and i + 1 causes an implicit narrowing conversion (JLS 5.1.3), which is not allowed. You can explicitly cast it as was shown. However ++i works because (From JLS 15.15.1):
Before the addition, binary numeric promotion (§5.6.2) is performed on the value 1 and the value of the variable. If necessary, the sum is narrowed by a narrowing primitive conversion (§5.1.3) and/or subjected to boxing conversion (§5.1.7) to the type of the variable before it is stored.
The ++ operator takes care of the narrowing conversion without us having to explicitly cast it
answered Dec 27 at 21:47
GBlodgett
9,21641633
How about just:
Stream.iterate('a', i -> ++i).limit(26).forEach(System.out::println);
i -> i + 1 does not work because i is a Character and i + 1 causes an implicit narrowing conversion (JLS 5.1.3), which is not allowed. You can explicitly cast it as was shown. However ++i works because (From JLS 15.15.1):
Before the addition, binary numeric promotion (§5.6.2) is performed on the value 1 and the value of the variable. If necessary, the sum is narrowed by a narrowing primitive conversion (§5.1.3) and/or subjected to boxing conversion (§5.1.7) to the type of the variable before it is stored.
The ++ operator takes care of the narrowing conversion without us having to explicitly cast it
answered Dec 27 at 21:47
GBlodgett
9,21641633
edited 2 days ago
answered Dec 27 at 21:47
GBlodgett
9,21641633
answered Dec 27 at 21:47
GBlodgett
9,21641633
answered Dec 27 at 21:47
GBlodgett
9,21641633
9,21641633
1
Good answer, would have been even better if you explain why++iworks andi + idoesn't.
– fastcodejava
2 days ago
1
and much better if you could also answer Why is the Java type inference is failing part specifically :)
– nullpointer
2 days ago
1
@fastcodejava I have edited my answer to try to explain.
– GBlodgett
2 days ago
3
1 👏🏻 for awesome explanation @GBlodgett
– Deadpool
2 days ago
add a comment |
1
Good answer, would have been even better if you explain why++iworks andi + idoesn't.
– fastcodejava
2 days ago
1
and much better if you could also answer Why is the Java type inference is failing part specifically :)
– nullpointer
2 days ago
1
@fastcodejava I have edited my answer to try to explain.
– GBlodgett
2 days ago
3
1 👏🏻 for awesome explanation @GBlodgett
– Deadpool
2 days ago
1
1
Good answer, would have been even better if you explain why
++i works and i + i doesn't.– fastcodejava
2 days ago
Good answer, would have been even better if you explain why
++i works and i + i doesn't.– fastcodejava
2 days ago
1
1
and much better if you could also answer Why is the Java type inference is failing part specifically :)
– nullpointer
2 days ago
and much better if you could also answer Why is the Java type inference is failing part specifically :)
– nullpointer
2 days ago
1
1
@fastcodejava I have edited my answer to try to explain.
– GBlodgett
2 days ago
@fastcodejava I have edited my answer to try to explain.
– GBlodgett
2 days ago
3
3
1 👏🏻 for awesome explanation @GBlodgett
– Deadpool
2 days ago
1 👏🏻 for awesome explanation @GBlodgett
– Deadpool
2 days ago
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53951142%2fprinting-the-letters-from-a-to-z-using-a-java-stream%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
5
Related stackoverflow.com/a/32424763/1746118
– nullpointer
2 days ago